edu-ID Meeting 23.6.2020

(zurück zur Übersicht)
Videokonferenz, 13:00-15:00

• Gemeinsame Durchsicht der Hausaufgaben (siehe unter „Vorbereitung“)
• Bewertung/Durchsicht der übrig gebliebenen Use Cases
• Sonstiges und weiteres Vorgehen

Siehe auch die Notizen aus dem letzten Workshop in Kaiserslautern.

Pad für Notizen: https://pad.gwdg.de/sQO40PU7Tmuc3dr7G5a6mg#

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.

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

(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?
• Hausaufgaben
  • Dokumentenablage, Projektmanagement, Richtung GitLab oder Vergleichbar → Wolfgang
  • Erstellen von Wiki-Seiten unter 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
    • ORCID - Open Researcher and Contributor ID
      • Gerrit
    • eID / eIDAS
      • Detlef
      • Jürgen nach dem 21.7.
  • Aufarbeitung der verblebenen Use Cases (s.o., war ja eigentlich zu heute geplant)