~~NOTOC~~

====== edu-ID Meeting 18.8.2020 ======

(zurück zur [[:de:aai:eduid:start|Übersicht]])\\
Videokonferenz, 13:00-17:00

{{INLINETOC 2}}

===== Agenda =====

  * Überarbeitete Wiki-Struktur ([[:de:aai:eduid:start|Einstiegsseite]] u.a.m.)
  * Offene Aktionen (s.u.)
  *  [[:de:aai:eduid:usecases|Konsolidierte Use Cases]]
      * Was ist unklar, was fehlt?
      * Ergeben sich neue [[:de:aai:eduid:usecases#anforderungen|Anforderungen]]?
      * Welche Anforderungen lassen sich aus den Use Cases für [[:de:aai:eduid:attributes|Kernattribute und Datenmodell]] ableiten?
  * [[:de:aai:eduid:open_questions|Offene Fragen]]
  * Sonstiges und weiteres Vorgehen
  * Nächster Termin

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

===== Vorbereitung =====

  * Durchsicht [[:de:aai:eduid:usecases|Use Cases]]

===== Offene Aktionen =====

**[[:de:aai:eduid:ws_feb_2010|Workshop Kaiserslautern Februar 2020]]**
  * Mit Onboarding-Anbietern reden: Kontakt herstellen zu: Uni-Assist (Steffen)
  * Bundesdruckerei/D-Trust (Steffen), Fragen:
      * Ausweis
        * Geburtsland?
        * zweite Nationialität?

**[[:de:aai:eduid:vc_2020-06-23|VC am 23.6.2020]]**
  * Dokumentenablage, Projektmanagement, Richtung GitLab oder Vergleichbar → Wolfgang
  * Erstellen von Wiki-Seiten unter [[:de:aai:eduid:stuff#identifier-systeme|Materialien]] zu den jeweiligen anderen Identifiern in Kleingruppen, zudem kleine Einschätzung abgibt (Relevanz, Möglichkeiten und UseCases für Account Linking)
      *  [[:de:aai:eduid:myacademicid|MyAcademicID / StudentCard ID]]
        * Petra, Thorsten, Wolfgang, Ramon
      * OZG
        * Detlef
      *  [[:de:aai:eduid:orcid|OrcID]]
        * Gerrit
      * eID / eIDAS
        * Detlef
        * Jürgen nach dem 21.7.

===== Diskussion =====

(Rohdaten: [[https://pad.gwdg.de/mXLxVJrNQmSHyKdBliTxXg|Pad]])

=== Offene Fragen (s.o.) ===

  * Weitere Staatsbürgerschaften in nPA?
  * → Nein, siehe Informationen aus dem [[https://www.personalausweisportal.de/SharedDocs/FAQs/DE/Fragen-und-Antworten/Welche_Daten-sind-auf-dem-Ausweis-gespeichert-und.html#:~:text=Patientenverf%C3%BCgungen%20abgespeichert%20werden%3F-,Welche%20Daten%20sind%20auf%20dem%20Ausweis%20gespeichert%20und%20wie,werden%2C%20welche%20Daten%20%C3%BCbertragen%20werden%3F&text=Diese%20Daten%20sind%20standardm%C3%A4%C3%9Fig%20im,Familienname%20und%20Vornamen|Personalausweisportal]]. Auch per Ausweisapp nicht auslesbar.

=== Kernattribute und Datenmodell ===

(→ [[:de:aai:eduid:attributes|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 [[:de:aai:eduid:usecases#uc_1_student_lifecycle|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?

[[http://mapping.semic.eu/vdm/about/html/http%3A%2F%2Fmapping.semic.eu%2Fvdm%2Fid%2Fcv%2Feb004434a93bbeaa2ba5968d26af06be|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 [[:de:aai:eduid:ws_feb_2010#notizen|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 ===

(→ [[:de:aai:eduid:loa|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 [[:de:aai:eduid:open_questions#vc_23_juni_2020|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 =====

[[:de:aai:eduid:vc_2020-10-13|Dienstag, 13. Oktober 20202]]

===== Themen für die weitere Arbeit =====

  * [[:de:aai:eduid:loa|Levels of Assurance]] spezifizieren (kontrolliertes Vokabular, Profile?)
  * Übersicht über mögliche [[:de:aai:eduid:stuff#identifier-systeme|zu verknüpfende Identifier-Systeme]]
  * Deprovisionierung (siehe AAI+)
  * Vermeiden von Mehrfachanmeldungen
  * Rechtliche Fragen, Datenschutz
  * [[:de:aai:eduid:architektur|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 [[:de:aai:eduid:usecases#anforderungen|Anforderungen]] ergeben? (alle)
  * Bei Gelegenheit™ [[https://doku.tid.dfn.de/de:aai:eduid:uc_low_prio|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 [[:de:aai:eduid:usecases|MUST-UC]] abgedeckt sind (alle)
  * UC 2.3 Nutzung von eduroam für weitere Dienste → Nachfrage außerhalb der VC-Treffen (Wolfgang)
  * {{:de:aai:eduid:kreuzmatrix_anforderungen_-_use_cases.pdf|Kreuzmatrix}}  zu den Anforderungen (Ramon)
  * {{:de:aai:eduid:kreuzmatrix_attribute_-_use_cases.pdf|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)