edu-ID Meeting 13.10.2020

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

Inhaltsverzeichnis

Agenda

  • Hausaufgaben und offene Aktionen (siehe unten)
  • Weiteres Vorgehen
  • Nächster Termin
  • Sonstiges

Pad für Notizen: https://pad.gwdg.de/mXLxVJrNQmSHyKdBliTxXg?both

Vorbereitung

Hausaufgaben und offene Aktionen

VC am 23.6.2020

  • Dokumentenablage, Projektmanagement, Richtung GitLab oder Vergleichbar → Wolfgang
    • Eigene Nextcloud-Instanz: betreffender Kollege aktuell im Urlaub, leider noch nicht ganz klar, wann die Installation kommt
    • Ansonsten gerne den Wiki-Upload benutzen
    • Notfalls per Mail an AAI-Kolleg*innen, die kümmern sich um den Upload
  • 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.
    • Seiten für OZG und eID/eIDAS können zusammengelegt werden

VC am 18.8.2020

  • UC 2.3 Nutzung von eduroam für weitere Dienste → Nachfrage außerhalb der VC-Treffen (Wolfgang)
    • Im Wiki ausgearbeitet
    • Etwas unsicher, was genau mit diesem UC gemeint ist - wie spielt eduroam hinein? Als Delegation eduID - eduroam - Heimateinrichtung?
    • Wenn man als Externer Nutzer von Einrichtung A an Einrichtung B kommt, kann man sich zwar per eduRoam anmelden, aber kommt dann in einen Netzbereicht der Einrichtung A, kann damit also die Dienste im Netzbereich von Einrichtung B nicht nutzen (zB Druckdienste). Über eine Anmeldung per eduID könnte man eine IP-Adresse aus dem Netzbereich von Einrichtung B erhalten und damit die dort verfügbaren Dienste nutzen
    • Notwendig dafür natürlich ein entsprechendes Attribut aus Einrichtung A, das mich zur Nutzung von Diensten der Einrichtung B berechtigt
    • Nachfrage bei Kollegen von SWITCH, wie der UC dort abgebildet ist / wird. Ggf. anschließend UC 2.3 neu bewerten (Wichtig / Später / Fallen lassen).
  • Kreuzmatrix zu den Anforderungen (Ramon)
  • Kreuzmatrix genutzte Attribute vs. Use Case (Ramon)
  • Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.)
  • Haben sich durch die Nachbetrachtung der Use Cases und die weiteren Diskussionen weitere Anforderungen ergeben? (alle)
  • Bei Gelegenheit™ Use Cases niedrigerer Priorität (UCLP) mit den MUST-UCs konsolidieren, d.h. prüfen, ob die Anforderungen, die sich aus dem jeweiligen UCLP ergeben, bereits über einen der MUST-UC abgedeckt sind (alle)
  • Abgleich Mindestdatensatz eIDAS vs. Attribute-Kreuzmatrix
  • Beschreibung, wie aus technischer Sicht SP-/dienstseitig eine LoA-Evaluierung erfolgen kann (Wolfgang)
    Verfahren kann sich an diesem Beispiel aus dem eduGAIN-Wiki orientieren

Diskussion

  • Zu den Kreuzmatrizen:
    • T1, T6-T8 technische Anforderungen, die sich nicht direkt aus den Use Cases ergeben, sondern den Betrieb betreffen
    • In vielen Use Cases Rückverweis auf UC1.1, eventuell in übrigen UCs prüfen, ob tatsächlich das gesamte Set aus UC1.1 benötigt wird oder ob weitere Attribute benötigt werden.
    • Name, Vorname: Statt aufzuteilen in einzelne Felder ist die Hauptsache, dass man den gesamten Namen erhält
      • Da die Werte jederzeit(?) aus eIDAS kommen, können wir die Werte 1:1 von dort übernehmen; auf welche eduID-internen Attribute wird das anschließend gemapped
      • Nur Vor- und Nachname (evtl wie in eIDAS definiert) und genau so an die Zielsysteme ausgeben; diese müssen sich dann damit auseinander setzen, wie sie die Daten auseinander nehmen
    • Exkurs: Was ist bspw. mit einem französischen Studierenden, der nach Deutschland kommt und Nationallizenzen nutzen will. Der deutsche Wohnsitz ist im eIDAS-Kontext nicht verfügbar. In dem Fall muss der Nutzer die Adresse in seinem User-Context (→ niedrige LoA) angeben und der Dienst muss entsprechend seine Verifizierungsprozesse anschieben.
      • Genauso, wenn gar keine Adresse übermittelt wird (weil im eIDAS Kontext nicht verfügbar)
    • „Im Rahmen des Notifizierungsverfahrens legt ein Land den Umfang des 'eigenen' Mindestdatensatzes fest“ (Quelle)
    • eidas SAML Attribute Profil
  • Kurzer Ausflug zum Datenschutz: Einwilligung des Nutzers für die self-sovereign (?) Datennutzung
  • Übersicht zur eID: https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Cooperation+Network+Resources
  • Bei Nachbetrachtung der Use Cases: Keine weiteren Anforderungen gefunden.
  • UseCases mit niedriger Priorität:
    • Proxy-Szenarien (Stichwort: Lizenzmanagement): Als technische Brücke oder Hilfe für Firmen, die nicht in eine AAI-Föderation können oder wollen. Zentrales Lizenzmanagement wird sich i.a. eher schwierig darstellen, da das Sache der einzelnen Hochschulen ist. Dazu muss edu-ID in der Lage sein, Entitlements flexibel zu speichern (siehe Skizze von Switch mit Affiliations): technisch einfachst in eduPersonEntitlement, anspruchsvoller in eigenen Attributen („local attributes“).
  • LoA-Info als Attribut: SWITCH-Lösung: https://www.switch.ch/edu-id/services/attributes/quality-levels/

Weiteres Vorgehen

  • Immer wieder kleinere Diskussionen, die das große Ganze (the greater Good(TM)) aus den Augen verlieren
    • Deshalb Einsetzen von kleineren Arbeitsgruppen?
    • Vorher Treffen in einem „Plenum“, um den Rest des Treffens zu planen, anschließend breakout sessions, anschließend wieder zusammensetzen und Ergebnisse besprechen

Nächster Termin

Fragen an SWITCH

  • Wie ist (unser) UC 2.3 umgesetzt?
  • Wie ist der Stand von SLSP (Swiss Library Service Platform) und Anbindung an eduID?
  • Umgang mit „local attributes“ / Entitlements für spezielle Dienste, z.B. im Proxy-Szenario. Wie technisch / organisatorisch gelöst?

Themen für die weitere Arbeit

Liste aus der vorherigen VC:

  • Levels of Assurance spezifizieren (kontrolliertes Vokabular, Profile?)
  • Übersicht über mögliche zu verknüpfende Identifier-Systeme
  • Deprovisionierung (siehe AAI+)
  • Vermeiden von Mehrfachanmeldungen
  • Rechtliche Fragen, Datenschutz
  • Architektur edu-ID System (Affiliation-Daten in Echtzeit?)
  • Registrierung eines zweiten Faktors (evtl. auch Verwaltung?)
    • Sicheres Verknüpfen eines zweiten Faktors mit einen Account
    • Sicherheit des Ausrollen des zweiten Faktors. Bei Selbstregistrierung besteht die Gefahr, dass der Account bereits kompromittiert ist…
  • Betriebskonzept? Arbeitsgruppe(n)?
  • Zuletzt geändert: vor 4 Jahren