Findynet feedback to the second batch of eIDAS implementation regulations

Background

The European Regulation 2024/1183 (11 April 2024) on establishing the European Digital Identity Framework entered into force on May 19^th, 2024. The regulation amends regulation 910/2014 on electronic identification and trust services for electronic transactions in the internal market, also known as eIDAS. In addition to the original regulation and the amendment, the consolidated text has also been published in the EUR-Lex service.

The regulation mandates that the Commission establish lists of reference standards, specifications, and procedures to implement it. The Commission will do this through implementing acts. The drafts of the first implementing regulations were published for views and feedback in August, and Findynet provided feedback in September. The drafts of the next five implementing regulations were published for views and feedback in November.

Registration of relying parties

We believe that the registration of relying parties proposed by the regulation is not needed in all use cases. Instead of national registration policies, attestation schemes or rulebooks should set the requirement when required, and the attestations should contain metadata about the authorities recognizing the authorized relying parties.

“Where more than one national register is established, a wallet-relying party shall be included in one register only.”

We do not support the idea of national registers and a master list published by the Commission. Instead, healthcare providers should be recognized in one trust chain, social security institutions in another, and education providers in a third. This leads to a model where the authorities in the trust chain know their direct subordinates and can decide which attestations or attributes those subordinates should be entitled to receive.

“The information shall be available through a single national application programming interface (‘API’) and through a national website”

The model of multiple registers and a single API can lead to availability and performance issues. If attestations contain metadata about their respective trust models, a wallet always knows where to look for information related to a specific attestation. This enables a more distributed model which is not so vulnerable to a single point of failure.

The Annex requires that the single API “be a REST API, supporting JSON as format” and “be published as an OpenAPI version 3, together with the appropriate documentation.”

The Annex should point to an OpenAPI specification that all API providers should implement. Otherwise, all member states would need to spend time and effort designing APIs that perform the same functions as neighboring countries but have different structures and parameter names. Similarly, wallet providers would need to support all these API variations.

“The Commission, in collaboration with Member States, should closely monitor the development of new or alternative standards on which relying-party access certificates could be implemented. In particular, trust models that have proven their efficacy and security in Member States should be assessed.”

We believe that a trust model based on the OpenID Federation protocol would provide a better fit for relying-party authentication than issuing certificates and publishing lists of certificate issuers. In OpenID Federation, a relying party can publish a simple file (entity configuration) that states who they are and points to an authority. That authority would be a similar entity to the proposed wallet relying-party access certificate issuer, but instead of issuing certificates, they would publish a service containing subordinate statements about the organizations they recognize.

Although the OpenID Federation specification is not yet a mature standard, it has been developed for years and is far more mature than a system composed of certificates, registries, and national APIs that have yet to be designed.

Verification of electronic attestation of attributes

“This Implementing Regulation defines rules for qualified electronic attestations of attributes and electronic attestations of attributes issued by or on behalf of a public sector body responsible for an authentic source.”

Since electronic attestation of attributes is the term the eIDAS regulation uses to refer to digital credentials, the name of the implementing regulation translates to “verification of digital credentials.”

Verification of digital credentials is a widely used and accepted term. For example, see the definition of verification in the ToIP glossary and the definition of verification in the W3C Verifiable Credentials Data Model specification. The term is also used in the same sense in the ISO international standard 18013-5 (see definitions of mDL Reader and mDL Verifier).

Despite the draft title, it doesn’t address the verification of digital credentials. Instead, the draft defines rules for issuance (Article 3), revocation (Article 4), notification (Article 5), publication of lists (Article 6), creation of catalogues (Articles 7 and 8), and verification of attributes against authentic sources (Article 9). Notably, verification of attributes here refers to a process performed by the issuer at the time of issuance. In contrast, verification of digital credentials is performed by the relying party receiving the credential.

This implementing regulation only covers qualified attestations of electronic attributes and attestations based on public sector authentic sources. Most digital credentials will likely fall outside the scope of this regulation.

The scheme catalogue proposed in Article 8 has many strengths. Trust ecosystems require clear documentation on the rules, roles, and responsibilities, as well as the governance model of the ecosystem. We hope the technical specifications used for the catalogue are compatible with specifications in other trust ecosystems.

Cross-border identity matching

According to Article 2 (paragraph 3), when attributes for identity matching are “made available through a wallet”, they are specified in the annex of the implementing regulation 2024/2977. When attributes are “made available through a notified electronic identification scheme”, they are specified in the older implementing regulation 2015/1501.

This is somewhat confusing, as wallets are provided under electronic identification schemes (see 2024/2981).

The 2015 implementing act includes “a unique identifier constructed by the sending Member State in accordance with the technical specifications for the purposes of cross-border identification and which is as persistent as possible in time.”

“The attributes which shall be used as the starting point for unequivocal identity matching … shall be the mandatory attributes … and the optional attributes needed to ensure that the presented dataset is unique.”

This places a burden on organizations performing identity matching. They must acquire and maintain up-to-date knowledge of attribute requirements for every digital identity scheme across Europe. Every system used for identity matching must be able to store all mandatory and optional attributes. In some cases, they must store heaps of optional attributes that serve no purpose other than cross-border identity matching.

The responsibility of determining the necessary attributes for unequivocal identity matching should rest with the PID provider.

The person identification data in the wallet should include a unique identifier for cross-border identification. While we understand the opposition to unique identifiers, the rationale is unclear. The identifier could be something simple like a hash of the person identification data (including mandatory and optional attributes). Every PID issuer is able to generate it, it is not vulnerable to transliteration issues, it can be transferred and stored as a compact string, it simplifies identity matching, and it doesn’t violate or endanger the privacy of individuals in any way.