~~NOTOC~~ ====== edu-ID Meeting 23.6.2020 ====== (zurück zur [[de:aai:eduid:start|Übersicht]]) \\ Videokonferenz, 13:00-15:00 {{INLINETOC 2}} ===== 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 [[de:aai:eduid:ws_feb_2010#notizen|letzten Workshop]] in Kaiserslautern. \\ **Pad für Notizen: https://pad.gwdg.de/sQO40PU7Tmuc3dr7G5a6mg#** ====Erneute Betrachtung der Use Cases hinsichtlich der folgenden Fragen==== [[de:aai:eduid:usecases|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 [[de:aai:eduid:vc_2020-06-23#erneute_betrachtung_der_use_cases_hinsichtlich_der_folgenden_fragen|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? * Hausaufgaben * Dokumentenablage, Projektmanagement, Richtung GitLab oder Vergleichbar -> Wolfgang * Erstellen von Wiki-Seiten unter [[de:aai:eduid:stuff#identifier-systeme|Materialien]] zu den jeweiligen anderen Identifiern in Kleingruppen, zudem kleine Einschätzung abgibt (Relevanz, Möglichkeiten und UseCases für Account Linking) * MyAcademicID / StudentCard ID * Petra, Thorsten, Wolfgang, Ramon * OZG * Detlef * [[de:aai:eduid:orcid|ORCID - Open Researcher and Contributor ID]] * Gerrit * eID / eIDAS * Detlef * Jürgen nach dem 21.7. * Aufarbeitung der [[de:aai:eduid:vc_2020-07-21#erneute_betrachtung_der_use_cases_hinsichtlich_der_folgenden_fragen|verblebenen Use Cases]] (s.o., war ja eigentlich zu heute geplant)