Has eIDAS been successful so far? What is stopping it from being adopted more rapidly? In light of the European Commission's open public consultation on eIDAS, we would like to share our notes on its current weakness and improvements to make eIDAS a success that might be helpful in answering these questions.

Current Weaknesses

Limited Scope

The scope of eIDAS is, by design, limited only for eGovernment services. An eID with pan-European reach may only be notified by the government of a Member State. The scope is also limited in accessibility by commercial entities. This barrier is legal and technical and creates a psychological barrier for users– using official means of identification.

Poor usability

Users must make a two-step selection of an electronic identification means. Next, an additional multistep process is required for each electronic identification usage. In the current state, users are only exposed to these difficult user scenarios sporadically, making it even more difficult for them. With an extended scope, the users would, in contrast, be exposed to quite a long multistep process for every electronic identification use.

Maintenance complexity for RP/receiving countries

Need to respond to new national electronic identification schemes. Need for updating the selection for users, as well as design and implementation of middleware-based schemes support.

Complicated identifier & personal data management for RP

Complications related to the management of identifiers and personal data of users are transferred to the weakest systems (target systems). The system design for managing identifiers and personal information is incomplete – the current simplified design of individual electronic identification means does not support reliable and consistent use by target RP systems.

Lifecycle / Sustainability

It does not guarantee the long-term stability of the link between the user and his assets.

Indirectly, it enforces a change in the same user's identifier with a new electronic identification means (of the same kind/species) instead of reliable long-term identification. Therefore, it is impossible to link a user to their assets persistently over time, since users change electronic identification means.

Unreliability of identification based on personal data

Unresolved reliability of electronic identification regarding very usual real-life issues/problematics eg. frequent names, typos, or "foreign" names.

The uniqueness and unambiguity of the information used to identify the user are not guaranteed. With prolonged intensive use, the likelihood of confusion and identity conflicts will increase.

Security

The target application's data channel is not authenticated and linked to user authentication. The binding of the data channel is missing. The system design prevents the fixation of security vulnerabilities that allow MITM attacks, even if the electronic identification means authentication protocol itself is secure enough.

The unresolved security issue of the "middleware based" eID in "requesting country" - the middleware is a possible method to ensure the security of the target application, which is partly outside the scope of eIDAS.

Using proofing instead of authentication

Each authentication is associated with personal data transfer as if identity proofing was always carried out in the target system. Such an approach has profound negative systemic implications for overall safety, long-term sustainability, as well as privacy.

Insufficient privacy protection

Only global identifiers are used while Sector identifiers are missing. The result is a compromise of national privacy measures.

Each authentication passes through eIDAS nodes – these potentially function as a "big brother." Such design conflicts with GDPR's privacy by design requirements. It stimulates a real and psychological barrier to widespread use (the state monitors all activities on the internet).

Restricted to government identity proofing only

Currently, eIDAS only supports one type of verification and one type of verified data – identity information provided by Identity documents and fundamental identities of respective governments.

Suggested Design Goals & Improvements

Universal authentication and eID infrastructure

eIDAS must extend the scope to be available for universal use in everyday life: eGov, Single Market, including IoT. The goal must be a universal eID infrastructure – by analogy as telecommunications or internet. Not only a particular product for partial/sector use.

Protection of long-term assets

Must have the ability to protect target assets in the long term – even when exchanging an electronic identification means for any reason (obsolescence, loss, emergency).

The design scope should also manage long-term identifiers in a secure environment for target systems.

Sustainability

Must be designed for long-term use and expect an evolution of electronic identification means during the user's life - expect new technologies, new cryptographies, etc.

High availability of target services

High resistance to failures, including user's electronic identification means device failures. User eID redundancy support.

Note: This requires distinguishing a redundant electronic identification means from an eID forgery.

Openness to different electronic identification means

By default, eIDAS should support automated interaction with many authentication technologies. It must also ensure to expect a dynamic development of technologies in the future.

Use of standardized interfaces to ensure interoperability and technological neutrality. The standardized interface must follow all other outlined principles.

Technological basis: Standard data channel authentication interface, which does not require electronic identification means communication standardization + full automation of authentication communication routing.

Security improvement

Ensure cryptographically strong authentication of the target application's data channel and link data channel authentication to user authentication.

Note that the transmission of data used for user authentication (password, challenge-response), using the target application's data channel, is not enough to authenticate the data channel.

Improving privacy protection

Design scope must ensure management of pseudonymous identifiers with minimal scope of use and minimum lifetime in unprotected communication (analogy of the use of sector identifiers).

Decentralization of the use of electronic identification means – the exclusion of "big brother" by design. Separation of identity proofing from repeated authentication. (discussed further in Separation of proofing from authentication or transactions)

Simplification for both users and RP

· Users - Automated recognition of the user's electronic identification means. There is no need to bother the user by entering the electronic identification means type correctly. All the user has to do is use it. This will increase not only comfort but also security – reducing the chances of social attacks.

· Service providers - e.g. providing stable identifiers for RP (including privacy). The eID infrastructure ensures that the RP can use a single long-term valid identifier of the same user in the long term and reliably, even if the user uses different electronic identification means (at different times of life and at the same time).

Simplifying design and governance

Replacing "proxy based" and "middleware based" architectures with a universal design.

Change the architecture, so that system solutions and interfaces are unified and do not depend on the internal implementation of electronic identification means.

Replacement with architecture using "external authentication of a target service's standardized data channel."

Extending functionality

Additional functionality is needed for universal deployment, including:

• Support for authenticated transactions, including authentication between 3 entities.
• Direct online payments to reduce the EU financial sector's dependence on the US
• Online anonymous voting, including safe, remote online elections, thus excluding threats to democracy even in epidemiologically complicated situations such as COVID-19.
• Remote secondary identity proofing for RP – electronic identification means will use personal data only for secondary proofing. In repeated use, there will only be authentication or transactions without the need to use unnecessary personal information.

Separation of proofing from authentication or transactions

Change in the architecture so that repeated authentication or authenticated transactions do not require repeated identity proofing (and transfer the necessary personal data to do so, addressing duplicates, typos, and ambiguities with each authentication on the target application side in "requesting country").

Proper use and design of a system of identifiers, including the promotion of privacy and long-term sustainability.

Commercial identity proofing service support

Open the market for a wide range of proofing and a wide range of personal data used in proofing – including state-guaranteed identity, commercially or institutionally guaranteed identity, social proofing, confirmations managed by the user - the user controls the confirmation when passing personal data.

Changing the security strategy

Emphasize the use of dynamic resilience using flexibility and computing power available common equipment that users already have, instead of using special HW based security methods that are currently promoted by Trust services.