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:48] – Wolfgang Pempe | de:aai:eduid:vc_2020-08-18 [2020/09/23 10:22] – [Hausaufgaben - neue Aktionen] Pfeiffer, Ramon | ||
---|---|---|---|
Zeile 88: | Zeile 88: | ||
* Name and family name at Birth | * Name and family name at Birth | ||
* Place of birth | * Place of birth | ||
+ | Beschluss [[de: | ||
+ | * " | ||
Offene Punkte: | Offene Punkte: | ||
* Ist der Kerndatensatz äquivalent zum eIDAS Mindestdatensatz? | * Ist der Kerndatensatz äquivalent zum eIDAS Mindestdatensatz? | ||
- | * Wollen wir an frühestmöglicher Stelle einen Abgleich der Daten mit dem eID System herstellen? | + | * Wollen wir an frühestmöglicher Stelle einen Abgleich der Daten mit einem eID System herstellen? |
* Woher kommen die Daten? | * Woher kommen die Daten? | ||
* Verknüpfung mit anderen Identifiern | * Verknüpfung mit anderen Identifiern | ||
- | Wie kommt der Nutzer zu einer eduID? | + | === Verlässlichkeit |
- | - NICHT ohne Zutun des Nutzers | + | (-> [[de: |
- | - Nutzer muss selbst eduID anlegen | + | |
- | - Zusammenfügen mit Hochschul-ID über zwei Wege | + | |
- | - Ausgehend | + | |
- | - Zurückspielen der eduID in lokales System | + | |
- | - Abfragen von eduID IdP | + | |
- | - Ausgehend von Einrichtung | + | |
- | | + | |
- | - Workflow muss den Nutzer ganz eindeutig darauf lotsen, dass er sich keine weitere ID anlegt (" | + | |
- | Durch bestehende eduID 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 eduIDs besorgt hat. In solch einem Fall muss auch Identitätserkennung über unterschiedliche Identifikatoren (unterschiedliche Namenseinsetzung bspw.) möglich sein. | ||
- | |||
- | Etwas aus dem Kontext: | ||
Die Anwendung weiß selbst, welches Mindest-LoA sie hat und weist ggf. den Nutzer an, seine Daten zu verifizieren. | Die Anwendung weiß selbst, welches Mindest-LoA sie hat und weist ggf. den Nutzer an, seine Daten zu verifizieren. | ||
- | |||
- | |||
- | |||
Möglicher Workflow: | Möglicher Workflow: | ||
- | Anwendung sagt "Gib mir die Attribute mit der 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 | + | Anwendung sagt "Gib mir die Attribute mit deren LoA" |
- | Zu Grunde liegende Frage: | + | * IdP hat die Attribute nicht in der LoA, also wird nichts übermittelt. |
- | - Liegen die Daten allein bei der Heimateinrichtung und werden live on demand vom eduID System abgefragt oder | + | * SP weiß nicht, ob IdP im Fehlerzustand ist oder ob die Daten nicht vorhanden sind oder ob LoA nicht passt |
- | - Werden die Daten bei Änderung an der Heimateinrichtung Richtung | + | * IdP liefert die Attribute aus, zusammen mit der jeweiligen LoA-Auszeichnung |
- | - Werden die Daten regelmäßig von Heimateinrichtung gepulled, sodass sie bei eduID offline liegen | + | * SP muss selbst entscheiden, |
+ | |||
+ | === Mechanismus zur Datenhaltung und zur -synchronisation=== | ||
+ | Zu Grunde liegende Frage (siehe auch unter [[de: | ||
+ | | ||
+ | | ||
+ | | ||
=== Datendeprovisionierung === | === Datendeprovisionierung === | ||
Regelmäßige Mail an hinterlegte E-Mail-Adresse zur Sicherstellung, | 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. | ||
- | ==== Themen für die weitere Arbeit ==== | + | 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 | ||
* [[de: | * [[de: | ||
* Übersicht über mögliche [[de: | * Übersicht über mögliche [[de: | ||
Zeile 148: | Zeile 150: | ||
===== Hausaufgaben - neue Aktionen ===== | ===== Hausaufgaben - neue Aktionen ===== | ||
- | | + | |
- | * Bei Gelegenheit(tm) [[https:// | + | |
- | * Kreuzmatrix zu den Anforderungen (Ramon) | + | * Bei Gelegenheit™ [[https:// |
- | * Kreuzmatrix genutzte Attribute vs. Use Case (Ramon) | + | * UC 2.3 Nutzung von eduroam für weitere Dienste → Nachfrage außerhalb der VC-Treffen (Wolfgang) |
+ | * {{: | ||
+ | * {{: | ||
* Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.) | * Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.) | ||
* Beschreibung, | * Beschreibung, | ||
+ | |||
+ |