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, | ||
| + | |||
| + | |||