edu-ID – Architecture

(back to Overview)

See also Working group Technik

The following comments are based on the results of the Workshops in November 2019 in Bamberg. See also the Notes and the related Blackboard picture.

• Support for central edu-ID use cases
  • Onboarding
  • “Recognition”, uninterrupted use of services
  • Account linking, aggregation of attributes and identities (“affiliations”)
• Use of local or institution-specific service providers must still be possible
• Ideally a single IdP as authentication source (i.e. not edu-ID-IdP versus home IdP)
• edu-ID is issued/generated centrally –> central IdP for onboarding

(are not rendered superfluous by an edu-ID system, but take on a different role in some cases)

• Must manage edu-ID (the identifier) locally in the IdM
• …and be able to synchronise attributes with the edu-ID system, ideally via push API (SCIM), attribute query as an emergency/transitional solution
• Must generally continue to “serve” local SPs (often special configurations)
• Home IdP as preferred authentication source (in edu-ID scenarios, the edu-ID IdP provides the attributes).

• SWITCH model: A central IdP that is able to emulate the IdPs of the participating home institutions
• Hybrid model: Home IdPs and edu-ID IdP side by side, edu-ID IdP only for certain SPs / use cases
• Decentralised model: edu-ID system only provides the identifier and the core attributes provided by the users

• Based on hybrid model
• edu-ID system fulfils several roles:
  • IdP: for homeless users, especially in onboarding scenarios
  • Proxy-SP: home IdP as authentication source –> one user session (SSO)
    (use case “recognition”, uninterrupted use of services)
  • Attribute and identity aggregator
• Identifiers derived from edu-ID:
  • (targeted) pairwise-id, occasionally also (unique) subject-id
  • Are generated by the edu-ID system
  • … and could be retrieved and cached by the home IdPs via a data connector (web service). However, this can only be an emergency solution! (difficult for “edu-SPs”) –> SSO better via Proxy-SP (see above)
  • Discovery in “proxy mode”
    • Aim for the best possible user experience
    • Ideally no cascading selection
  • Account linking, aggregation of attributes and identities
    • Push API (like SWITCH) for provisioning user data to the edu-ID system
    • Linking of identities is not automatic, but user-controlled
    • Essential for FIDs and research infrastructures
    • To aggregate IDs reliably (no copy+paste), customised solutions are required (e.g. from ORCID)

Information about SCIM