eIDAS Overview - RUB-NDS/FutureTrust GitHub Wiki

eIDAS is not a standalone Single-Sign-On solution but a compatibility layer between different eID integrations. This interoperability framework, defined in Commission Implementing Regulation 2015/1501[1], is limited to the cross-border communication of identity information. The eIDAS technical specification is based on SAML 2.0. It consists of four parts, each briefly described in the following paragraphs.

The eIDAS interoperability architecture defines the components processing the cross-border information exchange[2]. These are called eIDAS-Nodes, further divided into an eIDAS-Service for interfacing to a national eID scheme and an eIDAS-Connector communicating with relying parties. The interoperability architecture defines the deployment models of these components, which a member state can decide to be centralised or decentralised. It in particular specifies security requirements like the requirement for signed SAML requests and responses and for encrypted assertions. The overall trust model based on SAML metadata and notified metadata signer certificates as trust anchors are set.

The eIDAS message format profiles the SAML 2.0 messages communicated between eIDAS-Services and eIDAS-Connectors (the message formats between an eID scheme and the eIDAS Service, the eIDAS-Connector and the Relying Party, respectively, are national and not specified by eIDAS). The message format is to a large extent based on the outcome of the STORK Large Scale Pilot, which eIDAS has refined and better aligned with other standards like the Kantara eGovernment profile. It is a SAML browser WebSSO Profile with HTTP POST and Redirect bindings.

For the description of the eIDAS architecture the following definitions are used[3]:

  • Sending member state: Member state whose eID scheme is used for authentication, sends data to the receiving member state.
  • Receiving member state: Member state in which a relying party requests an authentication.
  • eIDAS-Node: Entity which is involved in cross-border authentication, can be an eIDAS-Connector or eIDAS-Service.
  • eIDAS-Connector: eIDAS-Node requesting cross-border authentication.
  • eIDAS-Service: eIDAS-Node providing cross-border authentication, can be an eIDAS-Proxy-Service or an eIDAS-Middleware-Service.
  • eIDAS-Proxy-Service: eIDAS-Service operated by the Sending member state and providing personal identification data.
  • eIDAS-Middleware-Service: An eIDAS-Service running Middleware provided by the Sending member state, operated by the Receiving member state and providing personal identification data.
  • Proxy based scheme: A (notified) eID scheme which provides cross-border authentication via an eIDAS-Proxy-Service.
  • Middleware based scheme: A (notified) eID scheme which provides cross-border authentication via eIDAS-Middleware-Service.
  • Middleware: Software provided by a member state notifying a Middleware based scheme which is used by receiving member states to operate eIDAS-Middleware-Service.
  • Receiving member state: Each Receiving member state operates one or more eIDAS-Connectors. These do not have to run by the member states, they can also be operated by public and private institutions which are located in this member state.
  • Sending member state: Sending member states have two options for the integration:
    • Proxy-based scheme: The Sending member state operates an eIDAS-Proxy-Service which relays the authentication requests and assertions between an eIDAS-Connector and the eID scheme of the Sending member state.
    • Middleware based scheme: The Sending member state provides a Middleware to other member states which have to be integrated into the eIDAS-Connector of the Receiving member states.

The protocol flow between these parties works as follows:

1) The relying party sends an authentication request to an eIDAS-Connector. The request may contain the identifier of the sending member state, if the relying party already knows which Sending member state is used. The request also contains a Level of Assurance (LoA) which has to be fulfilled by the Sending member state.

2) The eIDAS-Connector asks the relying party which member state should be used, if this was not already stated in the authentication request.

3) The eIDAS-Connector sends a SAML-AuthenticationRequest, which contains the type and name of the relying party to the eIDAS-Service of the Sending member state. The desired Level of Assurance is specified in the request.

4) The eIDAS-Service verifies the authenticity of the SAML-AuthenticationRequest. If it cannot serve the required Level of Assurance, it returns with an error.

5) The eIDAS-Service performs the authentication of the user in the Sending member state which fulfills the specified Level of Assurance and sends a SAML-AuthnResponse to the eIDAS-Connector.

6) The eIDAS-Connector verifies the SAML-AuthnResponse and sends the received authenticated person identification data to the relying party.

References

1. ^ Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means pursuant to Article 8(3) of Regulation (EU) No 910/2014. (September 2015). Retrieved from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOL_2015_235_R_0002
2. ^ 2015/1501/EU. (2015). Commission Implementing Regulation (EU) 2015/1501 of 8 September 2015 on the interoperability framework pursuant to Article 12(8) of Regulation (EU) No 910/2014. of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market (Text with EEA relevance). http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2015_235_R_0001. 3. ^ Subgroup, e. T. (11 2015). eIDAS - Interoperability Architecture. Retrieved from https://joinup.ec.europa.eu/sites/default/files/eidas_-_crypto_requirements_for_the_eidas_interoperability_framework_v1.0.pdf

FutureTrust
⚠️ **GitHub.com Fallback** ⚠️