FIXME **This page is not fully translated, yet. Please help completing the translation.**\\ //(remove this paragraph once the translation is finished)//

====== edu-ID - Attribute and Data model ======
~~NOTOC~~
(back to [[de:aai:eduid:start|Overview]])

\\

See also the previous results of the [[de:aai:eduid:ag2|Working group Attribute]].

==== Key attributes ====
The following attributes are available and verifiable via eIDAS-compliant eID systems (cf. [[http://mapping.semic.eu/vdm/about/html/http%3A%2F%2Fmapping.semic.eu%2Fvdm%2Fid%2Fcv%2Feb004434a93bbeaa2ba5968d26af06be|eIDAS Minimum data set]]):
  * 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 	

**Questions:**
  *This sets the core data set; which other attributes are for the respective [[de:aai:eduid:usecases|Use Cases]] neccessary? See also the cross-matrix below. 
  * Does this have consequences for the data model?
  * Can we adopt the SWITCH data model 1:1?

==== List of attributes rated as essential at the meeting on 11.12.2020 ====
[[de:aai:eduid:vc_2020-12-11|Meeting Notes]]

**Addresses:**
  * eIDAS-Data set: Difference between 'Address' and 'Current address'? DH: better have a look at the SAML specification? Probably only **one** address, see [[https://ec.europa.eu/cefdigital/wiki/download/attachments/82773108/eIDAS%20SAML%20Attribute%20Profile%20v1.2%20Final.pdf?version=2&modificationDate=1571068651772&api=v2|here]] (Page 6)
  * Available via 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: current registration address, not necessarily postal address
  * Postal address must be provided by the user
  * SWITCH edu-ID: postal address only, validation via code by letter post

**E-Mail:**
  * Multiple, primary and additional addresses, both personal and affiliation context
  * SWITCH edu-ID: validation via challenge mail

**Telephone number(s):**
  * SWITCH edu-ID: validation via SMS for mobile phone number; service landline number from affiliation
  * Record mobile and landline numbers separately, both in the personal and affiliation context (multi-value)

**Identifier:**
  * some can be made available via affiliation as well as via user  
  * ORCID: users should register themselves
  * bwIDM2: ORCID should be stored in university IDM, could then also come from the affiliation
  * SWITCH: OAuth2 interface for verification, link must be created by user
  * Problem: Multiple ORCIDs per user <-> affiliation. Error message? Leave ORCID in affiliation context.
  * GND: does an interface analogous to ORCID exist?

**Names:**
  * Name prefixes and suffixes part of the name? Parsing required (not applicable)
  * Distinguish between first and last name only

**Title:**
  * technically irrelevant, free text field

**Place of birth:**
  * Required - is it possible to infer the country of birth in all cases? 

**Country of birth:**
  * Difficult, but not essential anyway

**Personal pronouns**
  * or preferred form of address or similar

**Additional contact details:**
  * further telephone numbers and addresses
  * covered via other data fields

**Attributes in the affiliation context:**
  * SWITCH: some local imprints
  * At least eIDAS key data
  * dfnEduPerson
  * [[en:aai:attributes_best_practice|AAIplus attribute set]]
  * schacPersonalUniqueCode
  * Identifier: clarify whether home or edu-ID identifier is used at the latest during operational concept, local IDs for migration scenarios
==== Materials ====
  * {{:en:aai:eduid:kreuzmatrix_attribute_-_use_cases.pdf|Cross-matrix}} used attributes vs. use case
=== Data model 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]]