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 has been heavily discussed: the current proposal does not ensure the privacy feature “unlinkability”, which is to say, 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 that privacy feature.
Before we start: the issue I describe here was also submitted as direct feedback to the Commission on the implementing acts.
Background
First, a bit of background. This can safely be skipped by any reader familiar with eIDAS.
Regulation (EU) 2024/1183 (commonly referred to as eIDAS 2.0), which took force in May 2024, is an amendment to Regulation (EU) 2014/910 (referred to as just eIDAS) enacted in 2014. The new legislation mandates that all EU states develop a digital wallet 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. It touches 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.
Notably, 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 (the ARF) under development by the Commission. The law also mandates that the Commission add legally binding detail through a series of implementing acts, of which we have now seen the first batch of drafts.
An important privacy feature that some VC proof mechanisms have is called unlinkability. Informally, the property says that no colluding parties should be able to gather more information about the holder of a credential than what they individually already know. If a user makes a verifiable presentation to two different relying parties, then even if those two parties compare the presentations, they should learn nothing beyond what each knew on its own. The proof format should not even reveal that both presentations came from the same holder. Similarly, it must hold even when an issuer and a relying party collude. In essence, the holder of a credential stays untraceable when using it.
Article 5a 16 b) of eIDAS 2.0 requires the following of the wallet framework:
The technical framework of the European Digital Identity Wallet shall: … (b) enable privacy-preserving techniques which ensure unlikeability, where the attestation of attributes does not require the identification of the user.
Modulo the typo in the legislation requiring it to be unlikeable, I read this as stating that unlinkability is a requirement.
Why ISO18013-5 is linkable
The implementing acts state that the only proof mechanism for VCs in the wallets must be the one following the ISO18013-5 standard, in Article 8 together with Annex I of the act on “Integrity and Core Functionality”, and Article 5 together with Annex I of the act on “Protocols and Interfaces”.
So why is that such a big deal? Because this standard does not achieve unlinkability as defined above. To see why, it helps to know how its proof mechanism works.
At the core, ISO18013-5 relies on a cryptographic technique called a commitment scheme. This is a simple but very useful primitive that allows a party to commit to a value such that no other party learns it, a property known as hiding. The committing party obtains, as a side product, some information known as an opening, which can be used to reveal the value inside the commitment, and only the original value can be revealed, a property known as binding. A useful mental picture: a party puts the value in a unique box that they can later show a trick to open.
With that in place, and squinting sufficiently, the proof mechanism works as follows. To issue a credential, the issuer commits to the desired set of claims and signs the commitments. It then sends the commitments, their openings, and the issuer signature to the holder. To make a verifiable presentation, the holder forwards the commitments, the issuer signature, the openings for the properties they wish to disclose, and a signature over all of it including a challenge from the verifier. The verifier checks the signatures under suitable public keys and opens the commitments. Requiring the holder to sign the request ensures only a holder who knows their secret key can present, a property known as holder binding.
The designers of ISO18013-5 clearly cared about holder privacy. Signing commitments to claims rather than the claims themselves is what lets the holder selectively disclose a subset of attested attributes, a property called selective disclosure and one that eIDAS 2.0 explicitly requires in Recital 16.
Unfortunately, presentations made this way hand several perfect correlators to anyone trying to trace the use of a credential. The commitments (which need enough entropy to be hiding, and are therefore unique), the issuer signature, and the public key used to verify the holder’s signature all work as unique identifiers. That is quite the opposite of allowing a holder to remain untraceable.
As mitigation, ISO18013-5 permits issuing multiple copies of the same credential. If the holder is careful to use each copy only once, unlinkability against colluding relying parties can be achieved. But any issuer colluding with a relying party can still trace use perfectly, so this does not deliver the stronger form of unlinkability described above.
The dilemma
So why did the Commission include only this standard when it does not deliver the privacy mandated by the earlier legislation, given that techniques enabling proper unlinkability exist, such as CL signatures or BBS+ signatures? For obvious reasons I do not know. That will not stop me from guessing at a partial reason.
Unlinkability is not the only requirement. Article 5a 11 states:
European Digital Identity Wallets shall be provided under an electronic identification scheme with assurance level high.
Level of assurance high has a specific meaning, defined in Implementing Regulation (EU) 2015/1502. Annex I Section 2.2.1 lists, among many requirements, that “the electronic identification means protects against duplication and tampering as well as against attackers with high attack potential.”
Benign as that sounds, it has large implications. In our context it means the key used for holder binding must not be copyable, and the way to ensure that is to store it in secure hardware the user cannot reach, physically or digitally.
The secure elements available on Android and iOS have rather limited functionality. They allow simple operations such as hashing, signing, and encrypting with basic schemes like ECDSA, AES, and RSA. Schemes such as BBS+ establish holder binding differently: the holder proves in zero knowledge that they know a signature over a set of claims. Producing that proof requires knowing the issuer’s signature, and that knowledge is what binds the credential to the holder. Current secure elements cannot perform those proofs, so the same anti-duplication guarantee is not available. The holder could extract the signature and present from other devices, or share it with friends who could then present.
My guess is that, faced with the dilemma between proper unlinkability and LoA high, the Commission chose LoA high. Notably, Recital 6 of the draft act on Integrity and Core Functionality states:
To ensure data protection by design and by default, the wallets should be provided with several privacy enhancing features. These features should ensure that the wallets are to be used without the wallet user being trackable across different wallet relying parties. …
It seems the unlinkability requirement has been narrowed to hold only against colluding relying parties, which batch issuance under ISO18013-5 does provide.
Can we have it all?
If you have made it this far you are probably wondering whether both properties are obtainable: is there a way to achieve holder binding that resists duplication while still getting proper unlinkability?
One path would be for the providers of secure elements to allow the additional operations that BBS+ needs. Given that, at the time of writing, every EU country must offer a wallet within 19 months, that does not seem likely. So alternative approaches are needed, and several groups are actively developing solutions compatible with existing secure hardware.
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 present by proving possession of a valid issuer signature over the claims they wish to disclose, instead of forwarding the signature itself. Because the proof reveals nothing about the actual signature, presentations stay unlinkable. BBS(+) is a concrete example of a scheme built this way.
That solves linkability. What about LoA high, which required storing the holder’s key in tamper-proof hardware? There is no hardware support for cryptography as fancy as BBS(+), so it seems we need to default back to the ISO18013-5 mechanism to bind a presentation tightly to the holder: the holder signs the whole presentation, including the verifier’s challenge, with a unique signing key held in a secure element, using whatever scheme that hardware supports.
Done naively, by simply forwarding that signature, we are back where we started, because the same holder key verifies every presentation and is therefore a perfect correlator. So we look to zero knowledge again. One approach is to let the holder’s verification key be one of the attributes the issuer signs in the credential. The holder then proves, in zero knowledge, that they know a signature over the presentation which verifies under a key for which they also know an issuer signature. The verifier learns only that the holder knows such signatures, so there is nothing left to link presentations by. And since the signing key still lives in a secure element, the anti-duplication measures LoA high demands are still in place.
Is it that simple?
Unfortunately not. To the best of my knowledge there is no high-quality implementation of the approach outlined above, and considerable standardization work would be needed before it could underpin an EU-wide identity infrastructure. All EU countries are also on a tight deadline to make wallets available within Q2 2026.
Personally, I believe such a solution would be worth the work, because it would offer a significant privacy advantage to the citizens of the EU. At a minimum, I think 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 able to deliver a privacy-preserving solution in a timely fashion.
One caveat worth stating plainly: the unlinkability issue highlighted here is by no means a new insight. It has been known for a long time, has been put to the Commission in several open letters from academia, and has been raised repeatedly as feedback to the Architecture and Reference Framework developed by the Commission’s working group.
Want to talk about what unlinkable credentials would mean for your wallet or verification flow?
