eIDAS 2.0 Architecture and Reference Framework – Eurosmart’s feedback

14 Apr 2022 eIDAS 2.0 Architecture and Reference Framework – Eurosmart’s feedback

The EU eIDAS expert group working on eIDAS 2.0 published on February 22nd, the European Digital Identity Architecture and Reference Framework (the “ARF”).

Eurosmart’s members have collectively reviewed this document and provided the EU eIDAS expert group with an exhaustive list of comments (the commenting table is available here).

Some of the key messages from this table can be summarised as follows:

Level of Assurance “High”

Not all technologies mentioned in the outline allow meeting the security requirements for Level of Assurance “High”, as they reach diverse levels of security. The ARF outline should clearly target level of assurance “High” and indicate what technologies enable reaching such a Level of Assurance for the Wallet.

Reliance on secure hardware solutions

The highest level of trust requires secure hardware solutions reaching the level “High”. The outline should be more explicit on this point. In particular, cryptographic functions should only leverage secure hardware solutions because it is instrumental for the security and strength of the Wallet. The outline should also make clearer that Trusted Execution Environments (TEE) and Secure Elements (SE) do not provide the same level of trust – level “Substantial” for TEE and level “High” for SE.

User control

The outline refers to “full control” and “sole control” without defining these terms, especially with regards to sovereignty over data (e.g. cloud solutions), encryption keys, and the way the data are controlled by the mobile phone, SE, TEE etc. “Full” and “sole control” would deserve further explanation.

In addition, the concept of “breach of control” is introduced in the outline but not defined, while this concept does not appear in the legislative proposal.

Definitions of entities

Many entities are introduced by the outline. Some can be found in the eIDAS legislative proposal, and others are new (e.g. gateways, providers of registries, catalogues of attributes, PID providers). The outline should contain a definition clause to define all of them.

Clarify requirements

The outline should be clearer on the requirements that apply to the entities. For instance, which entities need to register?

Moreover, the responsibilities of the relying parties could be made more explicit. When relying on parties authenticate the attestations, should they verify the validity of the attestation? Should they also authenticate the PID? Another question is left unanswered: how does the relying party know that an operational phase is run at a given level of assurance (i.e. “High” or “Substantial”)? These points deserve clarifications. 

Mutual authentication between the Wallet and relying parties

Some details are missing for mutual authentication between the Wallet and relying parties. One missing element is the configuration and update in the Wallet of the authorisation and/or revocation list(s) of relying parties. Another missing element is the configuration of the trust anchors to be used by the Wallet to authenticate the relying parties.

Regarding the implementation of mutual authentication, the framework should leverage Qualified Website Authentication Certificates (QWACs).

In addition, mutual authentication should go beyond identification and authentication of endpoints; it should set a trusted channel whereby any subsequent communications between both parties -during the session- are protected in integrity, authenticity and confidentiality.