Zeige QuelltextÄltere VersionenLinks hierherNach oben Letzte ÄnderungenPer E-Mail sendenDruckenPermalink × edu-ID - Attribute und Datenmodell (zurück zur Übersicht) Siehe hierzu auch die bisherigen Ergebnisse der Arbeitsgruppe Attribute. Kernattribute Über eIDAS-konforme eID-Systeme sind folgende Attribute verfügbar und verifizierbar (vgl. 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 Fragen: Damit ist der Kerndatensatz gesetzt, welche weiteren Attribute sind für die jeweiligen Use Cases notwendig? Siehe auch die Kreuzmatrix unten. Ergeben sich hierfür Konsequenzen für das Datenmodell? Können wir das Datenmodell von SWITCH 1:1 übernehmen? Aufstellung der beim Treffen am 11.12.2020 als essentiell bewerteten Attribute Meeting Notes Adresse: eIDAS-Datensatz: Unterschied zw. 'Address' und 'Current address'? DH: besser in SAML-Spezifikation schauen? Wohl tatsächlich nur eine Adresse, siehe hier (Seite 6) Verfügbar über nPA: BSI TR-03130 DE: aktuelle Meldeadresse, nicht notwendigerweise Postanschrift Postanschrift muss nutzerseitig zur Verfügung gestellt werden SWITCH edu-ID: nur Postanschrift, Validierung über Code per Briefpost E-Mail: mehrere, primäre und zusätzliche Adressen, sowohl persönlicher als auch Affiliation-Kontext SWITCH edu-ID: Validierung über Challenge-Mail Telefonnummer(n): SWITCH edu-ID: Validierung per SMS bei Mobilfunknummer; Dienst-Festnetznummer aus Affiliation Mobil- und Festnetznummer separat erfassen, sowohl im persönlichen als auch im Affiliationkontext (Multi-Value) Identifier: manche können sowohl über Affiliation als auch über User zur Verfügung gestellt werden ORCID: Nutzer sollten sich selber registrieren bwIDM2: ORCID sollte in Hochschul-IdM hinterlegt werden, könnte dann also auch aus der Affiliation kommen SWITCH: OAuth2-Schnittstelle zur Verifizierung, Verknüpfung muss von User erstellt werden Problem: Mehrere ORCIDs pro User ↔ Affiliation. Fehlermeldung? ORCID in Affiliation-Kontext belassen. GND: existiert eine Schnittstelle analog ORCID? Namen: Namensvor- und zusätze Bestandteile des Namens? Parsing erforderlich (fällt weg) Nur Vor- und Nachname unterscheiden Titel: technisch irrelevant, Freitextfeld Geburtsort: Erforderlich - ist in allen Fällen ein Rückschluss auf Geburtsland möglich? Geburtsland: Schwierig, aber ohnehin nicht essentiell Personal Pronouns oder bevorzugte Anrede oder ähnliches Weitere Kontaktdaten: weitere Telefonnummern und Adressen abgedeckt über andere Datenfelder Attribute im Affiliation Kontext: SWITCH: einige lokale Prägungen Mindestens eIDAS-Kerndaten dfnEduPerson AAIplus Attributset schacPersonalUniqueCode Identifier: spätestens bei Betriebskonzept klären, ob Heimat- oder edu-ID Identifier zum Einsatz kommt, lokale IDs für Migrationsszenarien Materialien Kreuzmatrix genutzte Attribute vs. Use Case Datenmodell SWITCH edu-ID Standard Attribute Model Extended Model Zuletzt geändert: vor 13 Monaten Anmelden