====== edu-ID - Attribute und Datenmodell ======
~~NOTOC~~
(zurück zur [[de:aai:eduid:start|Übersicht]])

\\

Siehe hierzu auch die bisherigen Ergebnisse der [[de:aai:eduid:ag2|Arbeitsgruppe Attribute]].

==== Kernattribute ====
Über eIDAS-konforme eID-Systeme sind folgende Attribute verfügbar und verifizierbar (vgl. [[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 	

**Fragen:**
  *Damit ist der Kerndatensatz gesetzt, welche weiteren Attribute sind für die jeweiligen [[de:aai:eduid:usecases|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 ====
[[de:aai:eduid:vc_2020-12-11|Meeting Notes]]

**Adresse:**
  * eIDAS-Datensatz: Unterschied zw. 'Address' und 'Current address'? DH: besser in SAML-Spezifikation schauen? Wohl tatsächlich nur **eine** Adresse, siehe [[https://ec.europa.eu/cefdigital/wiki/download/attachments/82773108/eIDAS%20SAML%20Attribute%20Profile%20v1.2%20Final.pdf?version=2&modificationDate=1571068651772&api=v2|hier]] (Seite 6)
  * Verfügbar über nPA: [[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03130/TR-03130_TR-eID-Server_Part1.pdf?__blob=publicationFile&v=7
|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
  * [[de:aai:attributes_best_practice|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 ====
  * {{:de:aai:eduid:kreuzmatrix_attribute_-_use_cases.pdf|Kreuzmatrix}}  genutzte Attribute vs. Use Case
=== Datenmodell SWITCH edu-ID ====
  * [[https://www.switch.ch/edu-id/docs/services/attributes/|Standard Attribute Model]] 
  * [[https://www.switch.ch/edu-id/docs/services/attributes/extended-model/|Extended Model]]