Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:aai:eduid:vc_2020-08-18 [2020/08/19 14:36] – [Diskussion] Wolfgang Pempe | de:aai:eduid:vc_2020-08-18 [2020/08/19 15:38] – Wolfgang Pempe | ||
---|---|---|---|
Zeile 41: | Zeile 41: | ||
===== Diskussion ===== | ===== Diskussion ===== | ||
(Rohdaten: [[https:// | (Rohdaten: [[https:// | ||
+ | |||
+ | \\ | ||
===Offene Fragen (s.o.)=== | ===Offene Fragen (s.o.)=== | ||
* Weitere Staatsbürgerschaften in nPA? | * Weitere Staatsbürgerschaften in nPA? | ||
* -> Nein, siehe Informationen aus dem [[https:// | * -> Nein, siehe Informationen aus dem [[https:// | ||
+ | |||
+ | ===Kernattribute und Datenmodell=== | ||
+ | (-> [[de: | ||
+ | |||
+ | 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 " | ||
+ | -> Die Menge der Pflichtfelder | ||
+ | |||
+ | Welches sind die Pflichtfelder? | ||
+ | * 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? | ||
+ | |||
+ | [[http:// | ||
+ | * 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 | ||
+ | |||
+ | Offene Punkte: | ||
+ | * Ist der Kerndatensatz äquivalent zum eIDAS Mindestdatensatz? | ||
+ | * 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 === | ||
+ | (-> [[de: | ||
+ | |||
+ | 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, | ||
+ | |||
+ | === Mechanismus zur Datenhaltung und zur -synchronisation=== | ||
+ | Zu Grunde liegende Frage (siehe auch unter [[de: | ||
+ | * 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, | ||
+ | |||
+ | === 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 (" | ||
+ | |||
+ | 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. | ||
- | ==== Themen für die weitere Arbeit ==== | + | ===== Themen für die weitere Arbeit |
* [[de: | * [[de: | ||
* Übersicht über mögliche [[de: | * Übersicht über mögliche [[de: | ||
Zeile 64: | Zeile 151: | ||
* Haben sich durch die Nachbetrachtung der Use Cases und die weiteren Diskussionen weitere [[de: | * Haben sich durch die Nachbetrachtung der Use Cases und die weiteren Diskussionen weitere [[de: | ||
* Bei Gelegenheit(tm) [[https:// | * Bei Gelegenheit(tm) [[https:// | ||
+ | * UC 2.3 Nutzung von eduroam für weitere Dienste -> Nachfrage außerhalb der VC-Treffen (Wolfgang) | ||
* Kreuzmatrix zu den Anforderungen (Ramon) | * Kreuzmatrix zu den Anforderungen (Ramon) | ||
* Kreuzmatrix genutzte Attribute vs. Use Case (Ramon) | * Kreuzmatrix genutzte Attribute vs. Use Case (Ramon) | ||
* Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.) | * Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.) | ||
* Beschreibung, | * Beschreibung, |