edu-ID Meeting 23.6.2020

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

  • 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
        • Gerrit
      • eID / eIDAS
        • Detlef
        • Jürgen nach dem 21.7.
    • Aufarbeitung der verblebenen Use Cases (s.o., war ja eigentlich zu heute geplant)
  • Zuletzt geändert: vor 6 Wochen