edu-ID Meeting 18.8.2020
(zurück zur Übersicht)
Videokonferenz, 13:00-17:00
Agenda
- Überarbeitete Wiki-Struktur (Einstiegsseite u.a.m.)
- Offene Aktionen (s.u.)
-
- Was ist unklar, was fehlt?
- Ergeben sich neue Anforderungen?
- Welche Anforderungen lassen sich aus den Use Cases für Kernattribute und Datenmodell ableiten?
- Sonstiges und weiteres Vorgehen
- Nächster Termin
Pad für Notizen: https://pad.gwdg.de/mXLxVJrNQmSHyKdBliTxXg?both
Vorbereitung
- Durchsicht Use Cases
Offene Aktionen
Workshop Kaiserslautern Februar 2020
- Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen)
- Bundesdruckerei/D-Trust (Steffen), Fragen:
- Ausweis
- Geburtsland?
- zweite Nationialität?
- 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)
-
- Petra, Thorsten, Wolfgang, Ramon
- OZG
- Detlef
-
- Gerrit
- eID / eIDAS
- Detlef
- Jürgen nach dem 21.7.
-
Diskussion
(Rohdaten: Pad)
Offene Fragen (s.o.)
- Weitere Staatsbürgerschaften in nPA?
- → Nein, siehe Informationen aus dem Personalausweisportal. Auch per Ausweisapp nicht auslesbar.
Kernattribute und Datenmodell
(→ Wiki-Seite)
Orientierung an Datenmodell der SWITCH edu-ID (Standard vs. Extended Data Model)?
Definition Datenmodell:
- Ganz grundsätzliche Datenstruktur?
- Generell Architektur des Systems?
Prinzipiell ist Unterteilung in verschiedene Kontexte, wie von der SWITCH vorgemacht, eine gute Grundlage für unsere Architektur.
Brainstorming Kerndatensatz: Zentrale Frage: Was ist mit „Kerndatensatz“ gemeint?
→ Die Menge der Pflichtfelder
Welches sind die Pflichtfelder? Im Grunde die Attribute aus UC 1:
- Name
- Geb-Name
- Vorname
- Geb-Datum
- Geb-Ort
- Geschlecht
- Staatsangehörigkeit(en)
- Postanschrift
- Meldeanschrift
- private E-Mail-Adresse
- private Tel-Nummer
Welche Daten sind über eIDAS-kompatible Systeme verfügbar?
- A uniqueness identifier
- Address
- Current address
- Current family name
- Current first name(s)
- Date of birth
- Gender
- Name and family name at Birth
- Place of birth
Beschluss Workshop Kaiserslautern:
- „edu-ID startet mit eIDAS-kompatiblen eIDs (nPA, elektronischer Aufenthaltstitel)“
Offene Punkte:
- Ist der Kerndatensatz äquivalent zum eIDAS Mindestdatensatz? Nein, es ist der Konrad® (Kern- Oder Nennenswert Richtige, Andere Daten).
- Wollen wir an frühestmöglicher Stelle einen Abgleich der Daten mit einem eID System herstellen? (Ja)
- Woher kommen die Daten?
- Verknüpfung mit anderen Identifiern
Verlässlichkeit von Attributwerten
(→ Wiki-Seite)
Die Anwendung weiß selbst, welches Mindest-LoA sie hat und weist ggf. den Nutzer an, seine Daten zu verifizieren.
Möglicher Workflow:
Anwendung sagt „Gib mir die Attribute mit deren LoA“
- IdP hat die Attribute nicht in der LoA, also wird nichts übermittelt.
- SP weiß nicht, ob IdP im Fehlerzustand ist oder ob die Daten nicht vorhanden sind oder ob LoA nicht passt
- IdP liefert die Attribute aus, zusammen mit der jeweiligen LoA-Auszeichnung
- SP muss selbst entscheiden, ob das mitgelieferte LoA ausreicht und ggf. den Benutzer auffordern, nachzubessern (→ Validierung)
Mechanismus zur Datenhaltung und zur -synchronisation
Zu Grunde liegende Frage (siehe auch unter Offene Fragen):
- Liegen die Daten allein bei der Heimateinrichtung und werden live on demand vom edu-ID System abgefragt oder
- Werden die Daten bei Änderung an der Heimateinrichtung Richtung edu-ID gepusht, sodass sie dort offline liegen
- Werden die Daten regelmäßig von Heimateinrichtung gepulled, sodass sie bei edu-ID offline liegen
Datendeprovisionierung
Regelmäßige Mail an hinterlegte E-Mail-Adresse zur Sicherstellung, ob die Adresse noch funktioniert. Falls sie nicht funktioniert, ggf Fallback-Mechanismen zur weiteren Prüfung und anschließend möglicherweise Anstoßen der Deprovisionierung.
Weitere Themen
Wie kommt der Nutzer zu einer edu-ID?
- NICHT ohne Zutun des Nutzers
- Nutzer muss selbst einen edu-ID Account anlegen
- Verknüpfung mit Hochschul-ID und -Daten über zwei Wege:
- Ausgehend von der eduID → Anmeldung am lokalen IdP, eduID-System erhält Identität der Einrichtung
- Übertragen der edu-ID an lokales System
- Abfragen von edu-ID IdP
- Ausgehend von Einrichtung → edu-ID landet im lokalen IDM
- Anschließende Synchronisation der Daten mit edu-ID System (SCIM, Attribute Query [AQ])
- Workflow muss den Nutzer ganz eindeutig darauf lotsen, dass er sich keine weitere ID anlegt („Haben Sie bereits eine ID? Klicken Sie hier…“)
Durch bestehenden edu-ID Account ist es egal, ob der Nutzer an verschiedenen Stellen mit verschiedenen Datensätzen gemeldet wird; die unterschiedlichen Daten werden in den jeweiligen Affiliation Contexts abgelegt.
Identity Matching muss möglich sein, falls ein Nutzer sich über welche Wege auch immer mehrere edu-IDs besorgt hat. In solch einem Fall muss auch Identitätserkennung über unterschiedliche Identifikatoren (unterschiedliche Namenseinsetzung bspw.) möglich sein.
Nächster Termin
Themen für die weitere Arbeit
- 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…
- Identity-Management-System notwendig
- System von SWITCH nachnutzen und erweitern?
- Evaluierung sonstiger verfügbarer Systeme
Hausaufgaben - neue Aktionen
- 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)
- UC 2.3 Nutzung von eduroam für weitere Dienste → Nachfrage außerhalb der VC-Treffen (Wolfgang)
- Kreuzmatrix zu den Anforderungen (Ramon)
- Kreuzmatrix genutzte Attribute vs. Use Case (Ramon)
- Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.)
- Beschreibung, wie aus technischer Sicht SP-/dienstseitig eine LoA-Evaluierung erfolgen kann (Wolfgang)