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

~~NOTOC~~
====== edu-ID – Architecture ======
(back to [[de:aai:eduid:start|Overview]]) 

See also [[de:aai:eduid:ag8|Working group Technik]]

The following comments are based on the results of the [[de:aai:eduid:ws_nov_2019|Workshops in November 2019 in Bamberg]]. See also the [[https://pad.gwdg.de/pFJfGwNuQ_y7hrLvotYOCw|Notes]] and the related [[https://doku.tid.dfn.de/_media/de:aai:eduid:skizze_bamberg.jpg|Blackboard picture]].

==== Key requirements for an edu-ID system =====
  * 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

==== Requirements for home IdPs ====
(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).
    
==== Options for a technical solution ====
  * 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

==== Favoured solution model ====
  * 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)

==== Registration and initial onboarding ====
{{de:aai:eduid:registrierung_onboarding.png?800}}

==== Account linking and attribute/ID aggregation ====
{{de:aai:eduid:account-linking_sync.png?800}}

==== edu-ID-System as Proxy ====
{{de:aai:eduid:authn_proxy.png?800}}

==== Resources & Links ====
Information about [[https://scim.cloud//|SCIM]]