Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
de:aai:eduid:vc_2020-08-18 [2020/08/19 14:48] – Wolfgang Pempe | de:aai:eduid:vc_2020-08-18 [2020/10/12 09:16] (aktuell) – Wolfgang Pempe | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
~~NOTOC~~ | ~~NOTOC~~ | ||
+ | |||
====== edu-ID Meeting 18.8.2020 ====== | ====== edu-ID Meeting 18.8.2020 ====== | ||
- | (zurück zur [[de: | + | |
+ | (zurück zur [[:de: | ||
Videokonferenz, | Videokonferenz, | ||
+ | |||
{{INLINETOC 2}} | {{INLINETOC 2}} | ||
+ | |||
===== Agenda ===== | ===== Agenda ===== | ||
- | | + | |
+ | | ||
* Offene Aktionen (s.u.) | * Offene Aktionen (s.u.) | ||
- | * [[de: | + | * [[:de: |
- | * Was ist unklar, was fehlt? | + | * Was ist unklar, was fehlt? |
- | * Ergeben sich neue [[de: | + | * Ergeben sich neue [[:de: |
- | * Welche Anforderungen lassen sich aus den Use Cases für [[de: | + | * Welche Anforderungen lassen sich aus den Use Cases für [[:de: |
- | * [[de: | + | * [[:de: |
* Sonstiges und weiteres Vorgehen | * Sonstiges und weiteres Vorgehen | ||
* Nächster Termin | * Nächster Termin | ||
- | Pad für Notizen: https:// | + | |
+ | Pad für Notizen: | ||
===== Vorbereitung ===== | ===== Vorbereitung ===== | ||
- | | + | |
+ | | ||
===== Offene Aktionen ===== | ===== Offene Aktionen ===== | ||
- | **[[de: | + | |
+ | **[[:de: | ||
* Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen) | * Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen) | ||
* Bundesdruckerei/ | * Bundesdruckerei/ | ||
- | | + | |
- | * Geburtsland? | + | * Geburtsland? |
- | * zweite Nationialität? | + | * zweite Nationialität? |
- | **[[de: | + | |
- | * Dokumentenablage, | + | **[[:de: |
- | * Erstellen von Wiki-Seiten unter [[de: | + | * Dokumentenablage, |
- | * [[de: | + | * Erstellen von Wiki-Seiten unter [[:de: |
- | * Petra, Thorsten, Wolfgang, Ramon | + | * [[:de: |
- | * OZG | + | * Petra, Thorsten, Wolfgang, Ramon |
- | * Detlef | + | * OZG |
- | * OrcID | + | * Detlef |
- | * Gerrit | + | * |
- | * eID / eIDAS | + | * Gerrit |
- | * Detlef | + | * eID / eIDAS |
- | * Jürgen nach dem 21.7. | + | * Detlef |
+ | * Jürgen nach dem 21.7. | ||
===== 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=== | + | === Kernattribute und Datenmodell === |
- | (-> [[de: | + | |
+ | (→ [[:de: | ||
Orientierung an Datenmodell der SWITCH edu-ID (Standard vs. Extended Data Model)? | Orientierung an Datenmodell der SWITCH edu-ID (Standard vs. Extended Data Model)? | ||
Definition Datenmodell: | Definition Datenmodell: | ||
+ | |||
* Ganz grundsätzliche Datenstruktur? | * Ganz grundsätzliche Datenstruktur? | ||
* Generell Architektur des Systems? | * Generell Architektur des Systems? | ||
Zeile 59: | Zeile 70: | ||
Prinzipiell ist Unterteilung in verschiedene Kontexte, wie von der SWITCH vorgemacht, eine gute Grundlage für unsere Architektur. | Prinzipiell ist Unterteilung in verschiedene Kontexte, wie von der SWITCH vorgemacht, eine gute Grundlage für unsere Architektur. | ||
- | **Brainstorming Kerndatensatz: | + | **Brainstorming Kerndatensatz: |
- | Zentrale Frage: Was ist mit " | + | |
- | -> Die Menge der Pflichtfelder | + | Welches sind die Pflichtfelder? |
- | Welches sind die Pflichtfelder? | ||
* Name | * Name | ||
* Geb-Name | * Geb-Name | ||
Zeile 79: | Zeile 89: | ||
[[http:// | [[http:// | ||
- | | + | |
- | * Address | + | |
- | * Current address | + | * Address |
- | * Current family name | + | * Current address |
- | * Current first name(s) | + | * Current family name |
- | * Date of birth | + | * Current first name(s) |
- | * Gender | + | * Date of birth |
- | * Name and family name at Birth | + | * Gender |
- | * Place of birth | + | * Name and family name at Birth |
+ | * Place of birth | ||
+ | |||
+ | Beschluss [[: | ||
+ | |||
+ | * " | ||
Offene Punkte: | Offene Punkte: | ||
- | | + | |
- | * 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 | + | |
- | - 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 -> 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 (" | + | |
- | 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 | + | |
- | 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: | ||
+ | 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, | ||
- | Möglicher Workflow: | + | === Mechanismus zur Datenhaltung und zur -synchronisation === |
- | 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 | + | Zu Grunde liegende Frage (siehe auch unter [[: |
- | Zu Grunde liegende Frage: | + | |
- | - Liegen die Daten allein bei der Heimateinrichtung und werden live on demand vom eduID System abgefragt oder | + | * Liegen die Daten allein bei der Heimateinrichtung und werden live on demand vom edu-ID |
- | - Werden die Daten bei Änderung an der Heimateinrichtung Richtung | + | |
- | - Werden die Daten regelmäßig von Heimateinrichtung gepulled, sodass sie bei eduID offline liegen | + | |
=== 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? | ||
- | ==== Themen für die weitere Arbeit ==== | + | * NICHT ohne Zutun des Nutzers |
- | * [[de: | + | * Nutzer muss selbst einen edu-ID Account anlegen |
- | * Übersicht über mögliche [[de: | + | * 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. | ||
+ | |||
+ | ===== Nächster Termin ===== | ||
+ | |||
+ | [[: | ||
+ | |||
+ | ===== Themen für die weitere Arbeit ===== | ||
+ | |||
+ | * [[:de: | ||
+ | * Übersicht über mögliche [[:de: | ||
* Deprovisionierung (siehe AAI+) | * Deprovisionierung (siehe AAI+) | ||
* Vermeiden von Mehrfachanmeldungen | * Vermeiden von Mehrfachanmeldungen | ||
* Rechtliche Fragen, Datenschutz | * Rechtliche Fragen, Datenschutz | ||
- | * [[de: | + | * [[:de: |
* Registrierung eines zweiten Faktors (evtl. auch Verwaltung? | * Registrierung eines zweiten Faktors (evtl. auch Verwaltung? | ||
- | | + | |
- | * Sicherheit des Ausrollen des zweiten Faktors. Bei Selbstregistrierung besteht die Gefahr, dass der Account bereits kompromittiert ist... | + | * Sicherheit des Ausrollen des zweiten Faktors. Bei Selbstregistrierung besteht die Gefahr, dass der Account bereits kompromittiert ist… |
- | * Identity-Management-System notwendig | + | * Identity-Management-System notwendig |
- | * System von SWITCH nachnutzen und erweitern? | + | * System von SWITCH nachnutzen und erweitern? |
- | * Evaluierung sonstiger verfügbarer Systeme | + | * Evaluierung sonstiger verfügbarer Systeme |
===== 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, | ||
+ | |||
+ |