Dies ist eine alte Version des Dokuments!

edu-ID Meeting 18.8.2020

(zurück zur Übersicht)
Videokonferenz, 13:00-17:00

Inhaltsverzeichnis

Agenda

Pad für Notizen: https://pad.gwdg.de/mXLxVJrNQmSHyKdBliTxXg?both

Vorbereitung

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)

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

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 dem eID System herstellen?
  • Woher kommen die Daten?
  • Verknüpfung mit anderen Identifiern

Wie kommt der Nutzer zu einer eduID? - NICHT ohne Zutun des Nutzers - Nutzer muss selbst eduID anlegen - Zusammenfügen mit Hochschul-ID über zwei Wege

  1. Ausgehend von der eduID → Anmeldung am lokalen IdP, eduID-System erhält Identität der Einrichtung
    1. Zurückspielen der eduID in lokales System
    2. Abfragen von eduID IdP
  2. Ausgehend von Einrichtung → eduID landet im lokalen IDM
    1. Anschließende Synchronisation der Daten mit eduID System (SCIM, Attribute Query (AQ))
  3. 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.

Möglicher Workflow: Anwendung sagt „Gib mir die Attribute mit der LoA“ - IdP hat die Attribute nicht in der LoA, also wird nichts übermittelt.

  1. 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

  1. SP muss selbst entscheiden, ob das mitgelieferte LoA ausreicht und ggf. den Benutzer auffordern, nachzuliefern

## Mechanismus zur Datenhaltung und zur -synchronisation Zu Grunde liegende Frage: - Liegen die Daten allein bei der Heimateinrichtung und werden live on demand vom eduID System abgefragt oder - Werden die Daten bei Änderung an der Heimateinrichtung Richtung eduID gepusht, sodass sie dort offline liegen - Werden die Daten regelmäßig von Heimateinrichtung gepulled, sodass sie bei eduID 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.

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)
  • 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