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

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