edu-ID Meeting 21.7.2020

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

• Hausaufgaben aus dem letzten Meeting
• Bewertung/Durchsicht der verbliebenen Use Cases (s.u.) - siehe hierzu auch die Notizen aus dem Workshop in Kaiserslautern.
• Sonstiges und weiteres Vorgehen

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

Notizen aus dem vorherigen Meeting am 23.6.2020

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, z.B. 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

• Brainstorming beim letzten Treffen:
  • eIDAS Verordnung definiert ein komplettes Framework für elektronische Identifizierungsmittel
  • In der eIDAS Durchführungsverordnung lassen sich die Einzelbestandteile und die unterschiedlichen abstrakten Anforderungen erkennen: https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32015R1502&from=DE
  • Notwendig ist Einschränkung und Definition der angewendeten Teile (bspw. wie in REFEDS RAF schon durchgeführt, siehe in Kap. 2.2 die Definition von PREFIX/IAP/high https://wiki.refeds.org/display/ASS/REFEDS+Assurance+Framework+ver+1.0)
  • Vom BSI gibt es eine TR-03107-1 „Elektronische Identitäten und Vertrauensdienste im E-Government“. Dort ist ebenfalls das Zusammenspiel von Identifizierung im Enrolment, dem Authentisierungsmittel und weiteren Prozessschritten durchdekliniert. Hier sieht man, welche Aspekte betrachtet werden könnten, wenn man an der Stelle weiter in die Tiefe taucht. Sehr umfangreich. https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03107/index_htm.html
  • Falls Daten nicht über Ausweisdokument verifizierbar, muss über andere Kanäle verifiziert werden
  • Antwort der Bundesdruckerei steht aus
  • Staatsangehörigkeiten entscheiden über Zuweisung in Platzkontingent

UC1.2 Immatrikulation

• Weitere Attribute im Vergleich zu Bewerbung: weitere Staatsangehörigkeit
• Aktualität der Daten ist notwendig, vor Immatrikulation sollten Daten verifiziert werden
  • Wer hat die Datenhoheit? Einrichtung oder edu-ID System?
  • Notwendigkeit hauptsächlich auf Seiten der Hochschule
• Was triggert die Aktualisierung?
• Attribute Push von Einrichtung in edu-ID System in Einrichtungsdatenkontext, anschließend per Nutzerinteraktion mglw Übernahme der Daten in Userkontext
• Falls noch keine edu-ID existiert, wird erst die Immatrikulation vorgenommen und anschließend mit der nachträglich erzeugten edu-ID verknüpft
  • Zunächst nur Vorhandensein des lokalen Kontos, spätere „Aufwertung“ zu / Verknüpfung mit einem edu-ID Konto (nicht nur Immatrikulation, Onboarding allgemein)

UC1.3 Abschlussarbeit / Staatsexamen

• Kontexte hier wahrscheinlich bereits größtenteils etabliert
  • Gibt es hier andere Anforderungen als an die Immatrikulation?
• Notwendigkeit aktueller Daten
  • Von Hochschulseite
  • _und_ von Studierendenseite
• Name, Vorname, Geb-Datum, Geschlecht, ESI??

UC1.4 Referendariat

• Interoperabilität
• LoA
• Attribute

UC1.5 (Bewerbung) Promotion

• Interoperabilität
• LoA
• Attribute

UC1.6 Hochschul-Externe

• Interoperabilität
• LoA
• Attribute

UC2 Lehre (Kümmerer: DT Steffen + Wolfgang)
UC2.1 Lernmanagementsystemen

• Interoperabilität
• LoA
• Attribute

UC2.2 Temporäre Konten

• Interoperabilität
• LoA
• Attribute

UC2.3 Nutzung von eduroam für weitere Dienste

• Interoperabilität
• LoA
• Attribute

UC2.4 Weiterbildungsveranstaltungen

• Interoperabilität
• LoA
• Attribute

UC2.5 Lehrerbildung

• Interoperabilität
• LoA
• Attribute

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.

Siehe Pad: https://pad.gwdg.de/PmwFkwo3Q6qYQus9NLds9w?both