Zeige QuelltextÄltere VersionenLinks hierherNach oben Letzte ÄnderungenPer E-Mail sendenDruckenPermalink × ← Produktivbetrieb Attributes in a Nutshell → Dies ist eine alte Version des Dokuments! ← Produktivbetrieb Überblick: Tutorial zur IdP-Inbetriebnahme Attributes in a Nutshell → edu-ID Meeting 23.6.2020 (zurück zur Übersicht) Videokonferenz, 13:00-15:00 Inhaltsverzeichnis Agenda Vorbereitung Erneute Betrachtung der Use Cases hinsichtlich der folgenden Fragen Offene Fragen zur Diskussion TODOs Notizen Agenda Gemeinsame Durchsicht der Hausaufgaben (siehe unter „Vorbereitung“) Bewertung/Durchsicht der übrig gebliebenen Use Cases Sonstiges und weiteres Vorgehen Vorbereitung Siehe auch die Notizen aus dem letzten Workshop in Kaiserslautern. Pad für Notizen: https://pad.gwdg.de/sQO40PU7Tmuc3dr7G5a6mg# Erneute Betrachtung der Use Cases hinsichtlich der folgenden Fragen Zur Übersicht der gesammelten Use Cases (DQ = Datenqualität, LoA = Level of Assurance) Interoperabilität der (edu-)IDs / Länderübergreifende Mobilität Betrachten hinsichtlich Notwendig? Denkbar? Falls ja, wie? Notwendigkeit von verschiedenen Levels of Assurance (nicht nur DQ sondern auch Alter / Aktualität des Datums) Unter der Annahme eines Benutzer- und eines Affiliationskontexts: Gibt es eine Notwendigkeit, einen Anwendungsfall, … für eine niedrigere Verlässlichkeit? Mögliche Alternative: Kerndatensatzkontext (sauber verifiziert über eIDAS / nPA / eID), Affiliationkontext, Benutzerkontext Mandatory / Optional Attributes Ergeben sich aus den Attributanforderungen der jeweiligen Use-Cases Für Use Cases evaluieren, ob DQ (LoA und Alter) eine erneute Überprüfung / Validierung obsolet machen UC1 Student-Life-Cycle (Kümmerer: Michael B., Thomas) UC1.1 Studienplatzbewerbung Denkbar, zB bei länderübergreifenden Studiengängen (bei Bewerbung? oder erst bei Immatrikulation?) Verpflichtend verlässliche Datenqualität (DQ) - falls keine hohe DQ erreichbar, muss Onboarding über nicht-edu-ID Verfahren durchgeführt werden - Mindestanforderung an Validierung ist Klasse Substantiell aus [EU-VO 910/2014](https://eur-lex.europa.eu/legal-content/DE/ALL/?uri=CELEX:32014R0910) Titel?, Namensvor- und -zusätze, Name, Vorname, Geb-Datum, Geb-Ort, Geb-Land?, Geb-Name?, Geschlecht?, Nationalitäten, Postanschrift, Meldeanschrift, private E-Mail-Adresse, private Tel-Nummer, bevorzugte Sprache? (de/en) –> Nachfragen bei Bundesdruckerei: Weitere Staatsangehörigkeiten; Geb-Land UC1.2 Immatrikulation Weitere Attribute im Vergleich zu Bewerbung: weitere Staatsangehörigkeit –> Wie aktuell müssen die Daten sein? Muss nochmal über den edu-ID verifiziert werden? UC1.3 Abschlussarbeit / Staatsexamen UC1.4 Referendariat UC1.5 (Bewerbung) Promotion UC1.6 Hochschul-Externe UC2 Lehre (Kümmerer: DT Steffen + Wolfgang) UC2.1 Lernmanagementsystemen UC2.2 Temporäre Konten UC2.3 Nutzung von eduroam für weitere Dienste UC2.4 Weiterbildungsveranstaltungen UC2.5 Lehrerbildung UC3 Forschung (Kümmerer: Gerrit, Ramon) UC3.1 Zugang zu Publikationsservern Interoperabilität: National wichtig, um die Mobilität von Forschenden zu unterstützen International wünschenswert, erreichbar durch Verknüpfung / interoperabilität nationaler eduIDs Level of Assurance: Publizierenden müssen eindeutig identifizierbar sein. Über welches Attribut dies geschieht, ist relativ gleich, dieses benötigt aber einen hohen LoA Zur Erhöhung der Akzeptanz ist die Übernahme weiterer Attribute wie Name etc. (nach Consent) wünschenswert - diese benötigen jedoch nur einen niedrigen LoA Übernahme weiterer IDs wie ORCID ider GND-ID optional, niedriger LoA Daten sind beständig - eine erneute Verifizierung ist nicht notwendig Mandatory Attribute Name, Titel, Affiliation/Institution Optionale Attribute ORCID, GND-ID, Kontaktdaten (eMail etc.) UC3.2 Forschungsdatenmanagement - Verknüpfung von Identitäten und Publikationen (Anforderungen identisch UC3.1) UC3.3 Verbindung zu anderen Identifikatoren / IDs Interoperabilität grundsätzlich wichtig, erreichbar durch die Nutzung von APIs der jeweiligen ID-Provider Level of Assurance: Gegenseitiges LoA der IDs muss hoch sein, um die Übernahme fremder Identitäten zu verhindern Beständigkeit der Daten hängt vom verknüpften Identifikator ab - manche sind permanent (ORCID), andere ggf. nur temporär. Jedoch fraglich, ob eine Verifikation sinnvoll und auch möglich ist Mandatory Attribute: die zu verknüpfende ID, die eduID UC3.4 Kollaborative Dokumenterstellung Interoperabilität grundsätzlich wichtig, um einrichtungsübergreifende Zusammenarbeit (auch international) zu ermöglichen. Erreichbar durch Implementierung der eduID(s) auf Clientseite (also z.B. dem Online-Texteditor) Level of Assurance: bzgl. der eduID hoch, alle anderen Attribute gering Wiederholte Verifikation nicht notwendig Mandatory Attribute eduID Optionale Attribute Name, Title, Affiliation/Institution, ORCID, Kontakdaten (eMail) UC3.5 Researcher Mobility Interoperabilität grundsätzlich wichtig, um hohe Mobilität zwischen Einrichungen / Systemen zu erreichen. Möglichkeiten der Implementierung grundsätzlich abhängig von den verwendeten Systemen. Nutzung von SAML vorsehen. Level of Assurance: Hoch, wenn hier einem Gastwissenschaftler über die eduID Zugriff auf Dienste einer Einrichtung gewährt werden soll Die gastgebende Einrichtung hat Interesse an aktuellen Daten. Daher ist das Alter der Attribute wichtig. Mandatory / Optionale Attribute: abhängig vom Umfang des Zugriffs auf die Systeme der gastgebenden Einrichtung. Sicher Name, Kontaktdaten (inkl. Anschrift), Title, ggf. Geb-Datum, Affiliation UC3.6 Zugriff auf Nationallizenzen Interoperabilität nur national, kaum international Level of Assurance: wichtig alleine der Wohnsitz in Deutschland, dieser jedoch mit hoher LoA Wiederholte Verifikation des Wohnsitz notwendig (jährlich) Mandatory Attribute: Wohnsitz bzw. Information darüber, dass ein Wohnsitz in Deutschland vorhanden ist. UC3.7 Services von nationalen Bibliotheken / Informationseinrichtungen Interoperabilität: national wichtig, international wünschenswert. Erreichbar durch Implementierung von SAML in den jeweiligen AAIs Level of Assurance: Hoch bzgl. der Zugehörigkeit zu einer Einrichtung Ist die Zugehörigkeit zu einer Einrichtung Autorisierungsattribut jährliche Wiederholung der Verifikation notwendig Mandatory Attribute: Affiliation eduID Optionale Attribute: Name Kontakdaten (eMail) UC3.8 Zugriff auf zentrale Ressourcen Interoperabilität: national wichtig, international (v.a. europäisch) sehr wünschenswert. Erreichbar durch Implementierung von SAML Level of Assurance abhängig von der zentralen Ressource. Hoch, wenn z.B. Dienste abgerechnet werden müssen Aktuelle Attribute erforderliche, keine wiederholte Verifikation Mandatory / Optionale Attribute abhängig von der zentralen Ressource. Notwendig sicher Affiliation/Einrichtung, ggf. Name, Kontaktdaten UC3.9 Management virtueller Organisationen Interoperabilität national und international wichtig, um bestmögliche Kooperationen zu ermöglichen Level of Assurance hoch, um nur berechtigten Personen Zutritt zur VO zu gewähren Wiederholte Verifikation wahrscheinlich nicht notwendig UC3.10 Homeless Nutzer*innen Interoperabilität nicht notwendig Level of Assurance niedrig Wiederholte Verifikation notwendig, um Aktualität der Daten zu erhalten und Karteileichen zu verhindern Mandatory Attribut wahrscheinlich nur entitlement (?) UC4 Verwaltung (Kümmerer: Thorsten, Petra) UC4.1 Mitgliedschaften in universitären Gremien Interoperabilität (international): eher unwichtig Levels of Assurance: Person aus eigener Einrichtung: LoA sicher gestellt durch die Einrichtung selbst Personen einer Fremdeinrichtung Föderation: LoA sicher gestellt durch die Heimateinrichtung Personen ohne Heimateinrichtung (z.B. Abgeordnete): LoA muss hoch sein und sicher gestellt werden im eduID System (nPA, eID, eIDAS, …) Mandatory / Optional Attributes: Namen- und Kontakt-Attribute (eMail, Post, Telefon, …); Personen haben Eigeninteresse an Aktualität der Daten ⇒ nicht kritisch UC4.2 Personalgewinnung Interoperabilität (international): Denkbar bei Personen, die aus dem Ausland kommen. Dann wäre Zugriff auf die ausländischen Edu-IDs und dort gespeicherten Attribute nötig. Gilt umgekehrt auch für Personen mit deutscher Edu-ID, die ins Ausland gehen. Sinnvoll / hilfreich wäre dann auch, Änderungen an den Stammdaten, die hier durchgeführt werden, an das ausländische System weitergeben zu können. Levels of Assurance: Da es um Onboarding an der Einrichtung geht, muß das LoA hoch sein. ⇒ Keine Notwendigkeit für ein niedriges LoA. Mandatory / Optional Attributes: andere IDs wie ORCID u.ä. UC4.3 Bewerbungen auf Studiengänge analog zur Personalgewinnung. Weitere IDs könnten z.B. die europäische Studierenden-ID sein. UC4.4 Unterstützung der Dublettenerkennung bedeutet, daß eine Person nur eine Edu-ID haben darf. Interoperabilität (international): ist in diesem Use-Case nicht anwendbar. LoA / Optionale Attribute: N.A. Offene Fragen zur Diskussion Welche Daten werden im edu-Id-IdM gespeichert? müssen User-Daten im Gegensatz zum SWITCH-Modell in Echtzeit beim Heimat-IdP/IdM abgerufen werden? Falls ja, via Atribute Query oder über andere, zuverlässigere Mechanismen? Wie läuft die Datendeprovisionierung ab? Generieren wir einen eigenen Benutzernamen für die edu-Id? (Vgl. Christoph Grafs Bermerkung, wie schön es wäre, wenn es für die edu-Id einen eigenen Identifier @eduid.ch gäbe.) TODOs Postionierung des Projekts über DFN-Vorstand abklären (Wolfgang) Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen) Bundesdruckerei/D-Trust (Steffen) AK Campus-Management Mitstreiter (Thorsten, Frank) Notizen (siehe Pad: https://pad.gwdg.de/sQO40PU7Tmuc3dr7G5a6mg#) * Erneute Betrachtung der Use Cases hinsichtlich der o.g. Fragen * Probleme Was passiert, falls das eduID System nicht den dahinterliegenden Workflow bedienen kann? Workflow triggert bspw. neue Identifizierung im Falle von zu alten Daten Oder Meldung vom System „geht nicht“ und WF muss den Fall abfangen können, dass eduID System nicht ausreichende Daten liefert Notwendigkeit einer Spezfikation, wie abhängige Systeme im (Fehler)Fall arbeiten sollen Welche Daten werden in eduID gespeichert Eigener Benutzername? Datendeprovisionierung? Alles Punkte für ein Betriebskonzept * Andere Identifier Selbe Kategorie wie OrcID im Sinne von „Externer Identifier, den wir aufnehmen können“ OZG (Online-Zugangs-Gesetz) Nutzerkonto Eines beim Bund, 11 oder 12 bei den Ländern, Überblick kommt beim nächsten Mal Weiterentwicklung sehr schwer vorhersehbar Künftig Parallelstruktur speziell für den Bildungsbereich (kommt aus Digitalpakt Schule) Länder und Bund betreiben je ein Nutzerkonto und die dazugehörigen IdPs, im Zweifel outgesourced an die jeweiligen IT-Servicedienstleister MyAcademicID, European Student Identifier? European Student Card Projekt läuft aus und wird weitergeführt als „European Student Card Initiative“ eID / eIDAS: Interessant mindestens beim Identity-Matching targeted → für jeden Dienst ein eigener Identifier Ändert sich bei Änderung des Ausweises (ergo nicht lebenslang) weitere? Zuletzt geändert: vor 4 Jahren Anmelden