edu-ID Meeting 18.8.2020
(zurück zur Übersicht)
Videokonferenz, 13:00-17:00
Agenda
Vorbereitung
Offene Aktionen
Diskussion
Offene Fragen (s.o.)
Kernattribute und Datenmodell
(→ Wiki-Seite)
Orientierung an Datenmodell der SWITCH edu-ID (Standard vs. Extended Data Model)?
Definition Datenmodell:
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?
eIDAS Mindestdatensatz:
Beschluss Workshop Kaiserslautern:
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:
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
-
-
Deprovisionierung (siehe AAI+)
Vermeiden von Mehrfachanmeldungen
Rechtliche Fragen, Datenschutz
-
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
Hausaufgaben - neue Aktionen