~~NOTOC~~ ======Workshop edu-ID April 2020====== (zurück zur [[de:aai:eduid:start|Übersicht]]) ===== Vorbereitung ===== **Erneute Betrachtung der Use-Cases Hinsichtlich der Fragen:** * 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 UseCases evaluieren, ob DQ (LoA _und_ Alter) eine erneute Überprüfung / Validierung obsolet machen [[de:aai:eduid:useCases|Zur Übersicht der gesammelten Use Cases]]. **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** \\ **UC3.2 Forschungsdatenmanagement - Verknüpfung von Identitäten und Publikationen** \\ **UC3.3 Verbindung zu anderen Identifikatoren / IDs** \\ **UC3.4 Kollaborative Dokumenterstellung** \\ **UC3.5 Researcher Mobility** \\ **UC3.6 Zugriff auf Nationallizenzen** \\ **UC3.7 Services von nationalen Bibliotheken / Informationseinrichtungen** \\ **UC3.8 Zugriff auf zentrale Ressourcen** \\ **UC3.9 Management virtueller Organisationen** \\ **UC3.10 Homeless Nutzer*Innen** \\ **UC4 Verwaltung (Kümmerer: Thorsten, Petra)** \\ **UC4.1 Mitgliedschaften in universitären Gremien** \\ **UC4.2 Personalgewinnung** \\ **UC4.3 Bewerbungen auf Studiengänge** \\ **UC4.4 Unterstützung der Dublettenerkennung** \\ **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.)