Zeige QuelltextÄltere VersionenLinks hierherNach oben Letzte ÄnderungenPer E-Mail sendenDruckenPermalink × Dies ist eine alte Version des Dokuments! edu-ID Meeting 18.8.2020 (zurück zur Übersicht) Videokonferenz, 13:00-17:00 Inhaltsverzeichnis Agenda Vorbereitung Offene Aktionen Diskussion Nächster Termin Themen für die weitere Arbeit Hausaufgaben - neue Aktionen Agenda Überarbeitete Wiki-Struktur (Einstiegsseite u.a.m.) Offene Aktionen (s.u.) Konsolidierte Use Cases Was ist unklar, was fehlt? Ergeben sich neue Anforderungen? Welche Anforderungen lassen sich aus den Use Cases für Kernattribute und Datenmodell ableiten? Offene Fragen Sonstiges und weiteres Vorgehen Nächster Termin Pad für Notizen: https://pad.gwdg.de/mXLxVJrNQmSHyKdBliTxXg?both Vorbereitung Durchsicht Use Cases Offene Aktionen Workshop Kaiserslautern Februar 2020 Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen) Bundesdruckerei/D-Trust (Steffen), Fragen: Ausweis Geburtsland? zweite Nationialität? VC am 23.6.2020 Dokumentenablage, Projektmanagement, Richtung GitLab oder Vergleichbar → Wolfgang Erstellen von Wiki-Seiten unter Materialien zu den jeweiligen anderen Identifiern in Kleingruppen, zudem kleine Einschätzung abgibt (Relevanz, Möglichkeiten und UseCases für Account Linking) MyAcademicID / StudentCard ID Petra, Thorsten, Wolfgang, Ramon OZG Detlef OrcID Gerrit eID / eIDAS Detlef Jürgen nach dem 21.7. Diskussion (Rohdaten: Pad) Offene Fragen (s.o.) Weitere Staatsbürgerschaften in nPA? → Nein, siehe Informationen aus dem Personalausweisportal. Auch per Ausweisapp nicht auslesbar. Kernattribute und Datenmodell (→ Wiki-Seite) 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 „Kerndatensatz“ gemeint? → Die Menge der Pflichtfelder Welches sind die Pflichtfelder? Im Grunde die Attribute aus UC 1: 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? eIDAS Mindestdatensatz: 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 Beschluss Workshop Kaiserslautern: „edu-ID startet mit eIDAS-kompatiblen eIDs (nPA, elektronischer Aufenthaltstitel)“ Offene Punkte: Ist der Kerndatensatz äquivalent zum eIDAS Mindestdatensatz? Nein, es ist der Konrad® (Kern- Oder Nennenswert Richtige, Andere Daten). 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 (→ Wiki-Seite) 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, 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 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 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 Dienstag, 13. Oktober 20202 Themen für die weitere Arbeit Levels of Assurance spezifizieren (kontrolliertes Vokabular, Profile?) Übersicht über mögliche zu verknüpfende Identifier-Systeme Deprovisionierung (siehe AAI+) Vermeiden von Mehrfachanmeldungen Rechtliche Fragen, Datenschutz Architektur edu-ID System (Affiliation-Daten in Echtzeit?) Registrierung eines zweiten Faktors (evtl. auch Verwaltung?) Sicheres Verknüpfen eines zweiten Faktors mit einen Account Sicherheit des Ausrollen des zweiten Faktors. Bei Selbstregistrierung besteht die Gefahr, dass der Account bereits kompromittiert ist… Identity-Management-System notwendig System von SWITCH nachnutzen und erweitern? Evaluierung sonstiger verfügbarer Systeme Hausaufgaben - neue Aktionen Haben sich durch die Nachbetrachtung der Use Cases und die weiteren Diskussionen weitere Anforderungen ergeben? (alle) Bei Gelegenheit™ 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 MUST-UC abgedeckt sind (alle) UC 2.3 Nutzung von eduroam für weitere Dienste → Nachfrage außerhalb der VC-Treffen (Wolfgang) Kreuzmatrix zu den Anforderungen (Ramon) Kreuzmatrix genutzte Attribute vs. Use Case (Ramon) Abgleich Mindestdatensatz eIDAS vs Attribut-Kreuzmatrix (n.n.) Beschreibung, wie aus technischer Sicht SP-/dienstseitig eine LoA-Evaluierung erfolgen kann (Wolfgang) Zuletzt geändert: vor 4 Jahren Anmelden