A Cryptographer's Feedback on the European Digital Identity Framework

The period to give feedback to the EU Commission on its first batch of implementing acts regarding the forthcoming legislation about digital identities (known as EIDAS 2.0) has just ended. I, therefore, wanted to share my thoughts on one key issue that’s been heavily discussed: The current proposal does not ensure the privacy feature “unlinkability” (i.e., making sure that no one can trace how we use our digital identities).

In particular, I would like to address the issue of using ISO18013-5 as the sole standard for verifiable credentials in the EU Digital Identity Wallets (EUDIW). As we will see below, choosing only this standard comes at the cost of sacrificing the mentioned privacy feature.

Btw. before starting: Don’t worry – the issue I describe in this post was also submitted as direct feedback to the commission on the implementing acts.

First, let us start out with a bit of background (this can safely be skipped by any reader familiar with eIDAS).

The Regulation (EU) 2024/1183 (commonly referred to as eIDAS 2.0) law that took force in May 2024, is an amendment to the Regulation (EU) 2014/910 (referred to as just eIDAS) which was enacted in 2014. The new legislation mandates that all EU states develop a digital wallet (referred to as EUDIWs) for their citizens within Q2 of 2026 and additionally lays the legal foundation for how services enabling trust are to be provided in the EU. The new legislation touches upon a wide range of topics including a framework for issuing, holding, and controlling electronic certificates and attestations that both public and private organizations can issue. Noteworthily, it has been decided that the EU should develop an EU-wide interoperable framework for verifiable credentials (VCs), referred to as a “Union toolbox for the European Digital Identity Framework”. Concretely, this will be an “Architecture and Reference Framework” (referred to as the ARF) that is under development by the commission. Additionally, the law mandates that the commission must add legally binding details to the proposal through a series of implementing acts of which we have now seen the first batch of draft acts.

An important privacy feature that some VC-proof mechanisms (i.e., the mechanism used by wallets to prove that certain claims are correct towards verifiers/relying parties) have is called unlinkability. The meaning of this technical property can informally be stated as that no colluding parties should be able to gather more information about a holder of a VC than what they individually already know. That is, if a user makes a verifiable presentation to two different relying parties, then even though these two parties would compare these two presentations they should be able to learn nothing more than what they knew individually. That is, the proof format should not even reveal that this presentation was made by the same holder. Similarly, it must be guaranteed that even though an issuer and a relying party collude to obtain more information about the use of a certain credential, they should not be able to learn anything new. That is, essentially, this guarantees that the holder of a credential is untraceable when using their credential.

Noteworthily, Article 5a 16 b) of eIDAS 2.0 requires the following by the EUDIW framework:

Modulo (or “mutatis mutandis” as I guess it would be phrased using EU lingo) the typo in the legislation requiring it to be unlikeable, I interpret this as stating that unlinkability is a requirement for EUDIW.

Now, with that out of the way, let’s get onto the real topic of this post. The Implementing Acts, states that the only proof mechanisms for the VCs in EUDIWS must be that following the standard of ISO18013-5 (in particular, Article 8 together with Annex I of the act about “Integrity and Core Functionality” and Article 5 together with Annex I of the act about “Protocols and Interfaces”).

So why is that such a big deal you may ask?

The reason is that this standard does not achieve unlinkability as defined above. To understand why this is, it is necessary to provide a bit more detail about how the proof mechanism of ISO18013-5 works.

At the core, ISO18013-5 relies on a cryptographic technique called a “commitment scheme”. This is a simple (but yet very useful) cryptographic scheme that allows a party to “commit” to some value such that no other party learns the committed value (a property known as “hiding”). The party that created the commitment will as a side-product when producing the commitment, additionally, obtain some information (known as an “opening”) that can be used to reveal the value inside the commitment ensuring that only the original value that was committed to can be revealed (this property is known as “binding”). A useful mental picture for this is that a party puts the value into a unique box that they at a later point can show a trick how to open to reveal the value inside.

With that in place, and squinting sufficiently with the eyes, the proof mechanism of ISO18013-5 works in the following way: To issue a VC, the issuer commits to the desired set of claims for the credentials and signs the commitments. Then they send the commitments, the openings of the commitments, and the issuer’s signature on the commitment to the holder.

To make a verifiable presentation to a verifier, the holder forwards the commitments, the issuer signature, the desired set of openings to the commitments with the properties they would like to disclose, and a signature on all of this (including a challenge provided by the verifier). When receiving such a presentation, the verifier will then do the obvious, i.e., verify the signatures under suitable public keys and open the commitments. Requiring the holder to sign the request ensures that only a holder knowing their secret key can make such a verifiable presentation. This property is known as holder-binding.

Below is a depiction of this simplified view of the protocol.

Clearly, the designers of ISO18013-5 have cared about the privacy for the holder. In particular, because of the indirection of signing commitments to claims instead of just signing the claims themselves, this proof mechanism allows the holder to selectively disclose only a subset of the attested attributes to the verifier/relying party. This property is known as selective disclosure and is in fact explicitly mentioned as a requirement in the eIDAS 2.0 legislation (Recital 16).

Unfortunately, it should be evident that making verifiable presentations with this proof mechanism provides several perfect correlators for any party trying to trace the use of such VC. In particular, the commitments (to be “hiding” these requires a certain amount of entropy and will therefore also be unique), the issuer signature, and the public key used to verify the holder's signature can be used as unique identifiers. This is not really friendly towards the privacy of the holder. In fact, this is quite the opposite of allowing the holder to remain untraceable!

To provide some degree of mitigation to this, ISO18013-5 allows issuing multiple versions of the same VC. Therefore, if the holder takes care to use such issued VC only once, then unlinkability towards colluding relying parties can be achieved.

However, note that any issuer that colludes with a relying party will still be able to perfectly trace the use of the verifiable credential, and therefore this solution does not offer the same strong form of unlinkability as discussed above.

So why did the EU Commission include only this standard in their draft implementing acts when it does not fulfill the privacy mandated by previous legislation? There exist several cryptographic techniques that enable VCs with proper unlinkability (i.e., such as CL-signatures or BBS+ signatures)? Well, for obvious reasons I don’t know the reasons for this. But that won’t prevent me from taking a guess on what may be at least a partial reason anyway.

Unlinkability is not the only requirement for EUDIW specified in eIDAS 2.0. Another requirement is stated in Article 5a 11:

Now, the level of assurance (commonly referred to as LoA) high has a very specific meaning as this is defined in the Implementing Regulation (EU) 2015/1502 that followed the initial eIDAS law. In particular, Annex I Section 2.2.1 of this legislation states the following as being one of (the many) requirements for a solution to reach LoA high:

“The electronic identification means protects against duplication and tampering as well as against attackers with high attack potential.”

Now, while this requirement may seem benign, it has surprisingly large implications. Translating this to our context, the requirement states that it should not be possible to copy/duplicate the key used to ensure the holder's binding. The way to ensure this is to store the key in secure hardware/secure elements that cannot be accessed by the user (neither physically nor digitally).

Unfortunately, the secure hardware/secure elements available for Android and iOS have a rather limited functionality. In particular, they only allow to do simple operations such as hashing, signing, and encrypting using the most basic cryptographic schemes such as ECDSA, AES, RSA, etc.

Schemes such as BBS+ ensure holder-binding using a different technique than just letting the holder place their signature on a challenge and revealing the signature on a set of claims. Instead, when making a presentation the holder does a zero-knowledge proof that they know a signature on a certain set of claims. To do such proof the holder must necessarily know the signature of the issuer on this set of claims and this is what provides the holder-binding to this scheme. However, doing these zero-knowledge proofs is not supported by current secure hardware elements in modern phones and it is therefore not possible to achieve a similar guarantee of anti-duplication measures. That is, the holder may be able to extract the signature from the issuer and thereby be able to make a presentation from other devices or share this with their friends who could then make such presentations.

Based on the above my guess is, that the commission when faced with the dilemma between achieving proper unlinkability and LoA high has chosen to opt for LoA high. Noteworthily, in the draft implementing act about “Integrity and Core Functionality” the commission states in Recital 6:

It seems that the unlinkability requirement has now been specified to hold only against colluding relying parties as provided with the batch issuance of VCs following ISO18013-5.

If you have made it this far in my post you are probably left wondering: Would there be a way to obtain both properties? I.e., is there any way of achieving holder binding that is resistant to duplication while still obtaining proper unlinkability? Well, one way forward would be if the providers of the secure elements would allow additional operations (such as those necessary for BBS+) in the secure hardware. However, given the timeframe for the legislation to be fully implemented (i.e., all EU countries must offer a wallet within 19 months from now) this does not seem very likely to happen.

So alternative approaches are needed. Luckily, several different groups are actively working to develop alternative solutions that are compatible with existing secure hardware modules.

At Partisia we believe that an effective approach to achieving unlinkability while still living up to the requirements of LoA High would be to use zero-knowledge techniques. The core idea is for the holder to make a verifiable presentation by proving possession of a valid issuer’s signature on a set of claims that the holder would like to disclose instead of forwarding the actual signature. Using zero-knowledge proofs for this allows the holder to create presentations that remain unlinkable because they do not reveal any information about the issuer’s actual signature. A concrete example of a VC scheme that utilizes such an approach is the BBS(+) scheme.

So this approach solves the linkability issue. However, what about achieving this LoA high that required taking measures against duplication i.e., storing the holder’s key in tamperproof hardware?

As stated above, there is unfortunately no hardware support for such “fancy” cryptography as BBS(+). Therefore, it seems that we need to default back to the mechanism of ISO18013-5 to bind such a verifiable presentation tightly to the holder. That is, the holder must sign the entire presentation (including a challenge from the relying party) with their unique signing key stored in a secure hardware module using whatever signature scheme the tamper-proof hardware supports (for example ECDSA or RSA).

However, if done naively by simply forwarding this signature along with the presentation, we are back to square one. The reason is that this approach again introduces a linkability issue: the same holder key is used to verify the signature on multiple such presentations and therefore this is a perfect correlator that could be used to track users across different relying parties/issuing parties.

Therefore, instead of simply forwarding the signature on the presentation including the challenge, one must again look towards zero-knowledge techniques. Concretely, one approach is to let the holder prove possession of a valid signature on the presentation that can be verified by their public verification key without directly revealing it. This could for example be made possible by letting the holder’s verification key (i.e., the one whose corresponding signing key is stored in secure hardware) be one of the attributes in the credential signed by the issuer. Then in zero-knowledge, the holder can prove that they know a signature on the verifiable presentation that verifies under the verification key for which the holder also knows a signature by the issuer. Because the verifier learns nothing but the fact that the holder knows such a signature that verifies under a key for which the holder knows a signature, there is nothing that verifiers/relying parties can use to link together presentations, so such a solution would achieve unlinkability. But how about the holder-binding with measures against duplication?

To make such zero-knowledge proof the holder must be able to create a signature on the challenge posed by the relying party. As the signing key would be stored in a secure hardware module similar to the ISO18013-5 scheme, this would provide the same measures against duplication of such keys as required by LoA High.

The short answer is: Unfortunately not. To the best of my knowledge, there exists no high-quality implementation of the approach outlined above and there is quite a bit of standardization work to be done before such a solution would be ready for an EU-wide digital identity infrastructure. Additionally, all EU countries are on a tight deadline to implement and make the EUDIW available to their citizens within Q2 2026.

Personally, I do however believe that such a solution would be worth the work as it would offer a significant privacy advantage for the citizens of the EU. As a minimum, I think that the implementing acts should permit the use of modern cryptographic tools deemed secure by the research community. For some reason, I am strangely confident that there will be plenty of European technology companies that can deliver on such a privacy-preserving solution in a timely fashion.

Disclaimer: The unlinkability issue highlighted above is by no means a new insight. In fact, it has been known for a long time and has been brought forward to the commission in several open letters by academia and also mentioned several times as feedback to the architecture and reference framework developed by a working group organized by the commission.