Dies ist eine alte Version des Dokuments!


edu-ID Meeting 23.6.2020

Siehe auch die Notizen aus dem letzten Workshop in Kaiserslautern.

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
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

  • 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.
  • 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.)
  • 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)
  • Zuletzt geändert: vor 4 Jahren