Sven Erik Matzen

Software Architect | Cloud & Security Expert | AI-enabled Solutions

The ID That Stays Silent: eIDAS 2.0, the EU Identity Wallet, and the Art of Revealing Only What Is Needed

🎧 Listen to this article

Compliance · 2026-09-03

EU label: fully AI-generated content Fully AI-generated article (no prior review).

The Hook: The Bouncer Who Knows Too Much

Picture a perfectly ordinary scene. You want to order a bottle of wine online, open a bank account, or simply enter a platform that requires you to confirm you are over eighteen. Today this almost always follows the same pattern: you pull out your ID card, hold it up to a camera, or type your full details into a form. In doing so, the other side — the online shop, the bank, the platform — learns not just that you are of legal age. It learns your full name, your exact date of birth, your ID number, often your address and your face. For the simple statement "is over 18," your ID card delivers an entire dossier along with it.

It is as if a bouncer who really only needs a yes or a no photocopied your complete résumé every single time and filed it away in a cabinet you will never see again. Multiplied by every service, every sign-up, every purchase, this produces over the years a vast, scattered, linkable portrait of your life — spread across hundreds of databases whose security you don't know and whose business model is often hidden from you.

It is precisely this state of affairs that the European Union wants to fundamentally rebuild. On 20 May 2024, Regulation (EU) 2024/1183 entered into force — commonly called eIDAS 2.0. Its centerpiece is the EU Digital Identity Wallet, or EUDI Wallet: a digital wallet on your smartphone that every Member State must offer, free of charge, to its citizens, residents, and businesses by the end of 2026. The vision is a Europe-wide, state-backed digital ID with a radically different disposition from the bouncer above: it is meant to reveal only what is actually needed — ideally nothing more than a plain "Yes, over 18," with no name, no date of birth, no ID number.

For someone like Sven — a Senior AI Engineer with one foot in IT security, cloud architecture, and compliance — eIDAS 2.0 is a fascinating intersection. Here European regulatory craft, decades of matured cryptography (selective disclosure, zero-knowledge proofs, post-quantum methods), and hard questions of systems design all collide. And as so often in digital policy, behind the ungainly regulatory text lies a deep tension: between convenience and control, between security and surveillance, between a beautiful privacy vision and the hard reality of its technical implementation. This article takes you along the full distance.

Part 1: From eIDAS 1.0 to eIDAS 2.0 — Why a New Regulation Was Needed at All

To understand eIDAS 2.0, you have to glance briefly at its predecessor. The original eIDAS Regulation (EU) 910/2014 — the acronym stands for electronic IDentification, Authentication and trust Services — was, in 2014, a genuinely important building block of the digital single market. It created a European legal framework for electronic signatures, seals, timestamps, and website certificates, and in principle enabled the cross-border recognition of national electronic identities. Whoever had a state eID system in one country was supposed to be able to log in with it at public authorities in other Member States.

The catch: in practice, eIDAS 1.0 fell far short of that vision. The regulation did not oblige states to provide an eID system at all — only to recognize existing foreign ones. The result was a patchwork. Some countries had mature, widely used systems; others had nothing, or only island solutions for a handful of administrative procedures. Cross-border, little worked, and for the private sector — the online shop, the bank, the platform — the whole thing was barely usable. By the Commission's own estimates, only a small share of Europeans regularly used a state-issued digital identity means at all.

In parallel, another problem grew up. Global corporations filled the vacuum. "Sign in with Google," "Sign in with Apple," "Sign in with Facebook" — these login buttons became the de facto identity infrastructure of everyday life, with all the side effects for privacy, concentration of power, and dependency. The EU saw a strategic question of sovereignty: who controls the identity layer of Europeans' digital lives?

Out of this diagnosis came eIDAS 2.0. Commission President Ursula von der Leyen announced a "European digital identity" in her 2020 State of the Union address; the regulatory proposal followed in June 2021. After the usual wrangling among Commission, Parliament, and Council, the text was signed on 11 April 2024, published in the Official Journal on 30 April 2024, and entered into force on 20 May 2024 as Regulation (EU) 2024/1183. Formally, eIDAS 2.0 is not an entirely new regulation but a far-reaching amendment of the old eIDAS Regulation 910/2014 — but the intervention is so fundamental that the nickname "2.0" has stuck.

The decisive difference from the first version: eIDAS 2.0 is no longer merely a recognition framework but a provision obligation. Every Member State must offer at least one EUDI Wallet by the end of 2026. And the regulation reaches deep into the private sector: certain sectors are obliged to accept the wallet as a means of logging in and proving attributes. A toothless offer becomes an ecosystem with mandatory force on both sides — providers and acceptance points alike.

Part 2: What the Wallet Actually Is — Anatomy of a Digital Wallet

The regulation's new Article 5a is the centerpiece and defines what an EUDI Wallet must be able to do. It is worth taking the "wallet" metaphor seriously, because it carries a long way. A physical wallet holds different cards from different issuers — ID card from the state, driving licence from the traffic authority, bank card from the bank, membership card from the club. You decide which card to pull out in which situation. eIDAS 2.0 transfers precisely this model into the digital realm.

At its core the wallet holds two kinds of evidence. The first and most important are the Person Identification Data (PID) — the state-issued core identity data, essentially the digital ID card: name, date of birth, unique identifier. This PID is loaded into the wallet by a state-authorized issuer and forms the trusted anchor. The second type are electronic attestations of attributes (Electronic Attestation of Attributes, EAA) — digital proofs of individual properties: driving licence, university diploma, professional qualification, bank details, health insurance, concert ticket. When such an attestation is issued by a qualified, strictly regulated trust service provider, it is called a qualified electronic attestation of attributes (QEAA), carrying especially high legal probative value.

With this, the wallet can do three big things. First: identify and authenticate a person to authorities and services — say, when logging in to the tax office or opening a bank account. Second: prove individual attributes — "I hold a valid class B driving licence," "I am a licensed physician," "I am over 18." Third: qualifiedly sign electronic documents — for private individuals the wallet contains a free means of producing a qualified electronic signature, which is legally equivalent to a handwritten signature.

An often-overlooked but important detail: the wallet must support pseudonyms. Many services don't need a real identity at all, but only a stable, recognizable identifier that cannot be traced back to the real person — for example, to maintain a user account without disclosing your real name. The regulation expressly mandates this option, as a bulwark against "over-identification," to which we will return.

And finally: using the wallet is voluntary. No one may be forced to use it, and those who do not may not be disadvantaged. This is a politically delicate assurance whose practical robustness will only become clear once more and more services offer the wallet as the most convenient — and, at some point, perhaps the only reasonable — path.

Part 3: Under the Hood — The Technical Architecture

A regulation prescribes what should apply; the real music plays in the question of how this works technically. Here the Architecture Reference Framework (ARF) comes in — an extensive, continuously evolving technical framework that the Commission develops together with the Member States. The ARF is not a law but a kind of shared "toolbox" of standards, protocols, and best practices meant to ensure the interoperability of the 27 national wallets. It has matured through many versions in recent years; the discussion of individual building blocks runs in public, including on GitHub.

Three technical foundations are central. The first are the credential formats — that is, in what data structure a proof actually exists. The ARF relies chiefly on two formats. One is ISO/IEC 18013-5, originally the international standard for the mobile driving licence (mDL), whose data model — the so-called mdoc — is generalized for other credentials. The other is SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential), a token-based format from the widespread JWT family, deliberately extended with the ability to disclose selectively. Both formats conceptually build on the W3C's Verifiable Credentials — an open standard for verifiable, cryptographically signed digital proofs.

The second foundation are the protocols for issuance and presentation. How does a proof get into the wallet, and how do you present it? For this the ARF relies on the OpenID family: OpenID for Verifiable Credential Issuance (OpenID4VCI) governs issuance, OpenID for Verifiable Presentations (OpenID4VP) governs presentation. These protocols define the dance among three roles worth committing to memory, because they structure the entire field: the issuer (e.g., the state or a university), the holder (the user with their wallet), and the relying party or verifier (e.g., the online shop). Keep the three roles in mind and the architecture makes sense.

The third foundation is the security of the device. The cryptographic keys that give the proofs their forgery resistance must be especially well protected — ideally in a tamper-resistant hardware element of the smartphone (secure element or similar secure execution environments). Only this way can the highest assurance level, high, which the regulation requires for many applications, be reached. This is precisely where it gets hard in practice, because access to these hardware elements on iPhone and Android is tightly controlled by the platform operators — one of the many points where the beautiful sovereignty vision meets the power relations of the smartphone market.

Part 4: Selective Disclosure and the Treacherous Problem of Linkability

Now we come to the real heart — the property meant to distinguish the EUDI Wallet from a mere digital binder of files. It is called selective disclosure, and its promise is that of the bouncer who finally learns to answer only the one question.

The principle is elegant. A proof — say, the digital ID card — contains many individual data fields: name, date of birth, address, ID number, and so on. In classic presentation you would have to present the whole document, and with it the issuer's cryptographic signature, which secures all fields together. Selective disclosure breaks that coupling apart: the wallet can hand over individual fields and withhold all others without the signature losing its validity. The online shop gets "over 18: yes" — and only that. Name, date of birth, everything else stays in the wallet.

Technically, in SD-JWT and mdoc this is solved via a clever scheme of hashed individual fields. Simplified: the issuer does not sign the plaintext fields directly, but cryptographic hash values (checksums) of the individual fields. The wallet can then selectively disclose the plaintext values of exactly those fields that are needed, together with the associated opening information — and the relying party can verify that these values genuinely fall under the issuer's original signature, without ever seeing the remaining fields. Anyone who has read the article on The Tree That Condenses Truth: Merkle Trees and the Art of Efficient Integrity Verification will recognize a related mode of thought here: proving the truth of individual components without disclosing the whole.

But now comes the treacherous subtlety that privacy advocates and cryptographers have been grappling with for years: linkability. Selective disclosure ensures that I reveal less. But it does not automatically ensure that the individual presentation events cannot be linked to one another. Two levels must be distinguished here, and the ARF names them carefully.

The first level is unlinkability toward relying parties (relying-party unlinkability): two different service providers to whom I have shown the same proof should not, by pooling their data, be able to tell that they are dealing with the same person. The second, stronger level is full unlinkability: even if all parties — including the issuer — collude, no one should be able to attribute the individual presentation events to one person.

The problem: simple selective-disclosure schemes do not achieve this unlinkability on their own. If the wallet presents the same signed proof multiple times, the same signature travels along each time — and an identical cryptographic signature is a perfect, unique re-identification value, a hidden homing-beacon signal. Different services could tell from that alone that they are dealing with the same person. One could request a fresh, single-use proof from the issuer for each transaction (so-called batch issuance with one-time credentials), but that only shifts the problem: the issuer then potentially knows how often and when its citizens use their proofs.

The clean cryptographic solution is called anonymous credentials and works with advanced signature schemes that generate a fresh, unrecognizable presentation per transaction — for example BBS+ signatures or Pointcheval-Sanders multi-signatures (PS-MS), which enable full unlinkability. An international standardization effort (ISO/IEC PWI 24843) aims to standardize BBS+ and PS-MS with blinded signatures. And beyond that, a technique already familiar to readers of this vault comes into focus: zero-knowledge proofs. With programmable zero-knowledge schemes — concretely zk-SNARKs — both can be achieved at once: selective disclosure and unlinkability. A zk-SNARK can be formulated as a circuit that takes a secret input (the witness, e.g., the full attestation of attributes) and a public statement (e.g., "the age attribute is greater than 18") and outputs a compact proof confirming exactly that statement — without revealing any linkable cryptographic identifier. Anyone who wants to dig into the mechanics behind it will find them in the article Proving Without Revealing: Zero-Knowledge Proofs from Ali Baba's Cave to zk-SNARKs.

The state of play, in early September 2026, is a struggle over precisely this question. The ARF has taken up zero-knowledge proofs in a dedicated discussion topic ("Topic G"), and the Commission is working on technical specifications to anchor ZKP methods — building on mdoc and SD-JWT VC. So far, however, not a single one of the zk-SNARK schemes is formally standardized, which for a state high-security system is a serious obstacle. It is fair to say here: I am of the opinion that the wallet will start with simple selective disclosure and that full unlinkability will only be retrofitted step by step — the binding cryptographic foundation for it is not conclusively settled by the end of 2026.

Part 5: The Fight — Why Hundreds of Scientists Sounded the Alarm

No major EU digital law comes about without fierce debate, and eIDAS 2.0 has two lines of conflict you have to know in order to judge the law fairly.

The first and loudest concerns a side theater that packs a punch: Article 45 and the so-called QWACs (Qualified Website Authentication Certificates). Simplified, this is about the little certificates your browser uses to check whether a website is genuine — the basis of the padlock symbol and the encrypted HTTPS connection. In an earlier version, Article 45 would have obliged browsers to treat a new kind of state-authorized certificate (QWACs) as trustworthy, mandatorily. They would be issued by trust service providers who are approved not by the browser makers but by the governments of the Member States — and browsers would have had no right to remove a misbehaving certificate for security reasons.

For the security community this was a nightmare. In November 2023, over 500 scientists and researchers signed an open letter; organizations such as Mozilla and the Electronic Frontier Foundation (EFF) warned publicly. The core concern: if governments can compel which website certificates browsers must trust, then this potentially opens the door to state-sanctioned "man-in-the-middle" surveillance of encrypted web traffic — and undermines a browser-curated trust system painstakingly built up over decades. The letter put it sharply, warning that the rule was liable to "weaken the security of the internet as a whole." Following the criticism, the text was reworked — for instance with clauses meant not to compel the use of QWACs for encryption — yet many experts consider the underlying problem not fully resolved. It is an object lesson in how a well-meant sovereignty idea can become dangerous at a security-critical point of the internet.

The second line of conflict is subtler and concerns the wallet itself: the risk of over-identification and surveillance. Critics fear that such a convenient, ubiquitous identity infrastructure could lead services to routinely request more identity than they need — precisely because it is so easy. And a wallet that knows where and when you identify yourself everywhere would be a potentially perfect surveillance instrument.

Here the legislator has pushed back, and one should acknowledge this in the interest of balance. Article 5a and the accompanying data-protection provisions contain several hard guarantees. First: an express prohibition of profiling. The wallet provider may not collect unnecessary information about wallet use and may not combine the identification data with data from other services unless the user expressly requests it. Second: strict data separation — the data belonging to the wallet must be kept logically separate from the provider's other data. Third, and especially effective: a registration requirement for relying parties. Anyone wanting to use the wallet as a service provider must register in the Member State of their establishment and declare in advance which attributes they intend to request. The wallet can then technically enforce that a service may only request the data required for its registered purpose at all — a bolt against the bouncer's data-hoarding urge. Europe's data-protection authorities, too, such as Spain's AEPD, have examined in detailed analyses how this interacts with the General Data Protection Regulation, naming both the opportunities of data minimization and the residual risks.

The honest balance sheet, then, reads: on paper, eIDAS 2.0 has remarkably strong data-protection guarantees — probably stronger than any comparable state identity system in the world. Whether these guarantees hold in practice depends on two things: on the technical implementation (in particular the still-open unlinkability from Part 4) and on enforcement by supervisory authorities. Paper is patient; cryptographic unlinkability is not.

Part 6: The Roadmap, the Pilot Projects, and the First Big Test Case

How does a functioning system on millions of smartphones emerge from a regulation? eIDAS 2.0 follows a staggered timeline worth remembering. The regulation entered into force on 20 May 2024. By 24 December 2026, every Member State must provide at least one EUDI Wallet. And by 24 December 2027, the acceptance obligation kicks in for certain private-sector sectors: banks, healthcare, telecommunications, and very large online platforms must then accept the wallet as a means of authentication. The technical details are continuously fleshed out through implementing acts and the co-evolving ARF — the classic EU mechanism of filling the coarse law with fine-grained technical requirements.

To keep this from failing on the drawing board, the Commission has, since 2023, funded several large Large-Scale Pilots — consortia of authorities and companies that test the wallet technology under real conditions and feed feedback into ARF development. Projects with names like POTENTIAL, EWC, NOBID, and DC4EU have tested use cases from account opening through the mobile driving licence to travel and education credentials. Several Member States are ahead of the formal deadline and have already launched national wallet implementations — France (France Identité), Austria (eAusweise), and Italy (IT-Wallet) are among the front-runners, with more countries following.

A particularly instructive first test case is age verification. The EU is advancing a dedicated age-proof solution — a kind of "mini-wallet" app meant to be integrated as a precursor and later building block into the EUDI Wallet. A group of front-runner Member States (including France, Denmark, Greece, Italy, Spain, Cyprus, and Ireland) is piloting this solution, with the goal of having, by the end of 2026, an infrastructure with which you can prove online, sparingly, that you are over 18. Here the whole tension shows itself in miniature. The use case sounds harmless and desirable — youth protection without an ID copy. But privacy organizations such as the EFF warned pointedly in 2026 against misunderstanding zero-knowledge proofs as a "silver bullet" of age verification: even a perfectly data-sparing age-proof mechanism does nothing to change the fact that a blanket age-verification mandate can end anonymous browsing on the internet and generate new dynamics of exclusion and surveillance. The technology solves the how of data minimization elegantly — but it does not answer the political question of whether the mandate should exist. Notably, meanwhile, even large platform operators are getting involved: Google published open-source zero-knowledge-proof libraries for age assurance in 2026, also with an eye to the European solution.

A final technical look ahead concerns longevity. An identity system meant to last for decades must factor in the coming threat from quantum computers. The cryptographic signatures that secure the proofs today could, in a few years, be broken by sufficiently large quantum machines — the "harvest now, decrypt later" logic unfolded in the article Harvest Now, Decrypt Later: Post-Quantum Cryptography and the Race Against the Quantum Computer applies here too. A future-proof eIDAS ecosystem will sooner or later have to integrate post-quantum methods, just as the crypto world is already doing on other fronts — for instance in the Signal protocol.

The Central Takeaway

If you take a single thing from this article, let it be this: eIDAS 2.0 is an attempt to cast the principle of data minimization from a legal ought-statement into a technical standard architecture — and the real fight is decided not in the regulatory text but in the cryptography beneath it. The vision of the ID that stays silent and reveals only the one bit "over 18: yes" is legally anchored and flanked by unusually strong data-protection guarantees. But whether it holds depends on an inconspicuous technical subtlety — unlinkability — that does not automatically come along with simple selective disclosure and whose clean solution (BBS+, PS multi-signatures, zk-SNARKs) is not bindingly standardized by the end of 2026.

For Sven's practice, this translates into a concrete call to action. Anyone building systems over the next two years that process identity, login, or proofs — whether as a service provider (relying party) or in the background — should settle three things early. First, the role: am I an issuer, holder infrastructure, or relying party, and which registration and purpose-limitation obligations does that impose on me? Second, data minimization as an architectural decision: as a matter of principle, request only the attribute that the transaction genuinely needs (the "over 18" rather than the date of birth) — not merely because eIDAS and the GDPR require it, but because every datum you don't collect is a datum that can never be leaked. And third, crypto agility: build systems so that signature and proof schemes are interchangeable, because the field — from unlinkability to post-quantum — is still in motion. Data minimization is, in the end, not a feature list but a posture you cast into the architecture before the first line of code is written.

Cross-References in the Vault

Reflection Question

The EUDI Wallet promises to make you the master of your own data — but it does so by having the state provide the trusted identity layer of your digital life, while the technical infrastructure runs on smartphones controlled by two US corporations. Whom, in the end, do you more readily trust with sovereignty over your digital identity — a democratically legitimated but potentially surveilling state, the global platform corporations who de facto hold that role today, or a purely decentralized, self-sovereign solution with no state anchor — and what price (in convenience, security, or control) are you willing to pay for your choice?

Sources

← All articles