Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
de:aai:eduid:vc_2020-08-18 [2020/08/19 14:48] – Wolfgang Pempede:aai:eduid:vc_2020-08-18 [2020/10/09 11:19] – Wolfgang Pempe
Zeile 20: Zeile 20:
  
 ===== Offene Aktionen ===== ===== Offene Aktionen =====
-**[[de:aai:eduid:ws_feb_2010|Workshop Kaiserslautern Februar 2020]]**+ 
 +**[[:de:aai:eduid:ws_feb_2010|Workshop Kaiserslautern Februar 2020]]**
   * Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen)   * Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen)
   * Bundesdruckerei/D-Trust (Steffen), Fragen:   * Bundesdruckerei/D-Trust (Steffen), Fragen:
-    * Ausweis +      * Ausweis 
-      * Geburtsland? +        * Geburtsland? 
-      * zweite Nationialität?  +        * zweite Nationialität? 
-**[[de:aai:eduid:vc_2020-06-23|VC am 23.6.2020]]** + 
-  * Dokumentenablage, Projektmanagement, Richtung GitLab oder Vergleichbar -> Wolfgang  +**[[:de:aai:eduid:vc_2020-06-23|VC am 23.6.2020]]** 
-  * Erstellen von Wiki-Seiten unter [[de:aai:eduid:stuff#identifier-systeme|Materialien]] zu den jeweiligen anderen Identifiern in Kleingruppen, zudem kleine Einschätzung abgibt (Relevanz, Möglichkeiten und UseCases für Account Linking) +  * Dokumentenablage, Projektmanagement, Richtung GitLab oder Vergleichbar → Wolfgang 
-    * [[de:aai:eduid:myacademicid|MyAcademicID / StudentCard ID]] +  * Erstellen von Wiki-Seiten unter [[:de:aai:eduid:stuff#identifier-systeme|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 +      *  [[:de:aai:eduid:myacademicid|MyAcademicID / StudentCard ID]] 
-    * OZG +        * Petra, Thorsten, Wolfgang, Ramon 
-      * Detlef +      * OZG 
-    * OrcID +        * Detlef 
-      * Gerrit +      *  [[:de:aai:eduid:orcid|OrcID]] 
-    * eID / eIDAS +        * Gerrit 
-      * Detlef +      * eID / eIDAS 
-      * Jürgen nach dem 21.7.+        * Detlef 
 +        * Jürgen nach dem 21.7. 
  
 ===== Diskussion ===== ===== Diskussion =====
Zeile 88: Zeile 91:
   * Name and family name at Birth    * Name and family name at Birth
   * Place of birth    * Place of birth
 +Beschluss [[de:aai:eduid:ws_feb_2010#notizen|Workshop Kaiserslautern]]: 
 +  * "edu-ID startet mit eIDAS-kompatiblen eIDs (nPA, elektronischer Aufenthaltstitel)"
 Offene Punkte: Offene Punkte:
   * Ist der Kerndatensatz äquivalent zum eIDAS Mindestdatensatz? Nein, es ist der Konrad(r) (Kern- Oder Nennenswert Richtige, Andere Daten).   * Ist der Kerndatensatz äquivalent zum eIDAS Mindestdatensatz? Nein, es ist der Konrad(r) (Kern- Oder Nennenswert Richtige, Andere Daten).
-  * 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? (Ja)
   * 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 von Attributwerten === 
-- NICHT ohne Zutun des Nutzers +(-> [[de:aai:eduid:loa|Wiki-Seite]])
-- Nutzer muss selbst eduID anlegen +
-- Zusammenfügen mit Hochschul-ID über zwei Wege +
-    - Ausgehend von der eduID -> Anmeldung am lokalen IdP, eduID-System erhält Identität der Einrichtung +
-        - Zurückspielen der eduID in lokales System +
-        - Abfragen von eduID IdP +
-    - Ausgehend von Einrichtung -> eduID landet im lokalen IDM +
-        - Anschließende Synchronisation der Daten mit eduID 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 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, ob das mitgelieferte LoA ausreicht und ggf. den Benutzer auffordern, nachzuliefern 
  
-## 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 eduID gepusht, sodass sie dort offline liegen +  * 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, 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 [[de:aai:eduid:open_questions#vc_23_juni_2020|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 === === 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. 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 =====
 +[[de:aai:eduid:vc_2020-10-13|Dienstag, 13. Oktober 20202]] 
  
-==== Themen für die weitere Arbeit ====+===== Themen für die weitere Arbeit =====
   * [[de:aai:eduid:loa|Levels of Assurance]] spezifizieren (kontrolliertes Vokabular, Profile?)   * [[de:aai:eduid:loa|Levels of Assurance]] spezifizieren (kontrolliertes Vokabular, Profile?)
   * Übersicht über mögliche [[de:aai:eduid:stuff#identifier-systeme|zu verknüpfende Identifier-Systeme]]   * Übersicht über mögliche [[de:aai:eduid:stuff#identifier-systeme|zu verknüpfende Identifier-Systeme]]
Zeile 148: Zeile 155:
  
 ===== Hausaufgaben - neue Aktionen ===== ===== Hausaufgaben - neue Aktionen =====
-  * Haben sich durch die Nachbetrachtung der Use Cases und die weiteren Diskussionen weitere [[de:aai:eduid:usecases#anforderungen|Anforderungen]] ergeben? (alle) + 
-  * Bei Gelegenheit(tm) [[https://doku.tid.dfn.de/de:aai:eduid:uc_low_prio|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 [[de:aai:eduid:usecases|MUST-UC]] abgedeckt sind (alle) +  * Haben sich durch die Nachbetrachtung der Use Cases und die weiteren Diskussionen weitere [[:de:aai:eduid:usecases#anforderungen|Anforderungen]] ergeben? (alle) 
-  * Kreuzmatrix zu den Anforderungen (Ramon) +  * Bei Gelegenheit™ [[https://doku.tid.dfn.de/de:aai:eduid:uc_low_prio|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 [[:de:aai:eduid:usecases|MUST-UC]] abgedeckt sind (alle) 
-  * Kreuzmatrix genutzte Attribute vs. Use Case (Ramon)+  * UC 2.3 Nutzung von eduroam für weitere Dienste → Nachfrage außerhalb der VC-Treffen (Wolfgang) 
 +  * {{:de:aai:eduid:kreuzmatrix_anforderungen_-_use_cases.pdf|Kreuzmatrix}}  zu den Anforderungen (Ramon) 
 +  * {{:de:aai:eduid:kreuzmatrix_attribute_-_use_cases.pdf|Kreuzmatrix}}  genutzte Attribute vs. Use Case (Ramon)
   * Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.)   * Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.)
   * Beschreibung, wie aus technischer Sicht SP-/dienstseitig eine LoA-Evaluierung erfolgen kann (Wolfgang)   * Beschreibung, wie aus technischer Sicht SP-/dienstseitig eine LoA-Evaluierung erfolgen kann (Wolfgang)
 +
 +
  • Zuletzt geändert: vor 4 Jahren