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

(back to Overview)


See also the previous results of the Working group Attribute.

The following attributes are available and verifiable via eIDAS-compliant eID systems (cf. 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 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?

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 here (Page 6)
  • Available via nPA: 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
  • schacPersonalUniqueCode
  • Identifier: clarify whether home or edu-ID identifier is used at the latest during operational concept, local IDs for migration scenarios

Data model SWITCH edu-ID

  • Last modified: 3 months ago