Who actually gets registered in the EU Digital Identity Wallet

The claim that keeps circulating

A recurring post format is doing well on social media right now. It goes roughly like this: a member state activates its digital identity wallet, it holds a driving licence and a health card, it looks like convenience — but underneath, it installs a single state-issued credential that logs every time a citizen proves who they are.

The factual parts are real. Member states are deploying wallets. They do hold identity credentials. Private platforms will connect to them.

The conclusion is not. And the way to check isn't to trust me or to trust the Commission — it's to read the Architecture and Reference Framework, the public technical specification that defines what these wallets must do. It's published at eudi.dev, it's versioned on GitHub, and it's readable.

I've been following its evolution closely for the past two years. Here are four things in it that don't fit the narrative.

1. The log exists. It belongs to you.

The ARF requires every EUDI Wallet to include a privacy dashboard: a built-in view giving the user an overview of all data exchanged with every service provider they've interacted with.

So the claim that "every use is recorded" is, in a narrow sense, correct. There is a record. What the claim gets wrong is who holds it. The dashboard is a user-facing transparency feature, on the user's device. It exists so you can audit who asked you for what — not so anyone can audit you.

This is close to an inversion of the surveillance reading. The specification's response to "how do we stop this being opaque?" was to mandate that the user gets the ledger.

And it goes further than "the state doesn't see it." Requirement WIAM_12a states that the Wallet Unit shall ensure the Wallet Provider — the body that issued you the wallet, typically a member state entity — cannot access the contents of the Wallet Unit: not which attestations you hold, not their status, not the values of their attributes, and not the contents of that log. The organisation that gave you the app is explicitly designed out of seeing what you do with it.

2. The issuer isn't in the loop when you present

This is the load-bearing technical point, and it's the one most posts miss entirely.

Under the ARF, presentation happens directly between the wallet on your device and the relying party asking for data. For remote flows the wallet speaks OpenID for Verifiable Presentations, in combination with the W3C Digital Credentials API. For in-person flows it uses ISO/IEC 18013-5 over NFC, Bluetooth Low Energy, or Wi-Fi Aware — which works with no internet connection at all.

In none of those flows does the issuing authority receive a notification. There is no call home. The credential was signed when it was issued; the verifier checks that signature against a public trust list. The government that issued your credential does not learn that you used it, when you used it, or where.

Denmark's AltID documentation states this plainly for its own implementation: the issuer cannot know that the credential is being used, nor where. That isn't a Danish design choice — it's what the underlying architecture requires.

The obvious follow-up is: fine, not the issuer — but what about the operating system? For QR and proximity flows, it isn't in the path either. The wallet renders the code, the response goes to the verifier, and proximity works with no network at all. The browser-native flow is a different story, and it's the strongest objection anyone raises about this architecture. I come back to it below.

3. The entity that has to register is the company, not you

This is the detail that most cleanly reverses the framing, and almost nobody covering this topic mentions it.

The EUDI ecosystem does involve a registration regime. It applies to relying parties — the platforms and services that want to request your attributes. They register in their member state, declare which specific data they intend to request, under what legal basis, and for what purpose. That declaration is bound into a certificate the wallet checks at presentation time.

Practically: when a service asks for your data, your wallet can verify that the requester is who they claim to be and that they're authorised to ask for that particular attribute. A service that registered to request age_over_18 and then tries to request your address doesn't get a technical pathway to do it.

The system that supposedly registers citizens is, at the registration layer, a system that registers companies and constrains what they're allowed to ask for.

4. Unlinkability is a build requirement, not a promise

The ARF treats unlinkability as a design property the architecture has to deliver: two different relying parties should not be able to correlate their interactions with you, and the issuer should not be able to trace where a credential travels.

That has concrete consequences in shipped code. AltID, the first age verification issuer on the EU's production Trusted List, issues its age credential in batches of 30 single-use attestations — same attributes, different metadata. Each presentation burns one. Two verifiers never receive the same artefact, so there's no shared identifier to join on. When the batch runs out, a new one is generated automatically.

That's engineering cost — key management, batch refresh, storage — spent on a property that has no user-visible benefit except that you can't be followed. Nobody builds that by accident.

It's also not the whole story. I come back below to what batches don't solve.

Age verification is the sharpest example

The EU Age Verification Blueprint, built on the same foundations, exists specifically to break the link between proving your age and revealing your identity.

The relying party receives one boolean: over the requested threshold, yes or no. Not your name, not your birthdate, not a document number, not a persistent identifier. AltID's credential carries nine thresholds — 13, 15, 16, 18, 21, 23, 25, 27, 67 — and the verifier requests exactly one. A platform checking age_over_18 never learns whether you're also over 21.

This is driven directly by law, not goodwill. DSA Article 28(3) states that platforms are not required to process additional personal data solely to determine whether a user is a minor. The technical design had to satisfy that constraint.

What's actually worth worrying about

None of this means there are no legitimate questions. There are — and the best of them arrived in the comments on my last piece, from people who've been in this field considerably longer than I have. They're also not the ones going viral, which is the whole problem.

Some of what follows is outside what this article set out to do. This started as a look at a specific design choice — what the specification requires of wallets and verifiers — and several of these objections operate at a different level entirely. I'm including them anyway, because ignoring a good objection is worse than answering it incompletely. But they're topics with their own weight, and I'm not going to close them here.

The execution environment. The sharpest objection to this architecture has nothing to do with issuers, verifiers or trust lists. It concerns the device — and it's worth separating carefully from a related question it constantly gets confused with.

Cryptography protects data in transit and at rest. It does not protect data from the environment executing it. A wallet's privacy-preserving component receives sensitive data and transforms it into something safe to share — but the app performing that transformation runs inside an operating system it doesn't control. If that environment can observe the input before the transformation, the transformation protects you from the verifier, not from the environment. Denis Roio has made this argument consistently and in public: it holds even with zero-knowledge proofs, because the OS sees the data going in. Process isolation for the privacy-preserving component isn't a nice-to-have. It's the precondition for the guarantee to mean anything at all.

This isn't about where the private keys live — key storage is a separate problem with separate answers. It's about the process: the app's memory, its screen and its I/O belong to the operating system, whatever hardware holds the keys.

That objection stands. I don't think it has a good answer today.

Two honest qualifications, though. First: none of this is specific to EUDI. Your banking app, your 2FA, your password manager and your email run under the same trust model today. That doesn't make the objection wrong — it makes it an objection to mobile computing that EUDI inherits rather than invents. Second: "the OS could correlate telemetry with presentations" is a claim about capability, not about observed behaviour. But the argument doesn't need Google to be doing it today. It needs the architecture not to prevent it — and it doesn't. If your privacy model depends on a platform vendor choosing not to look, that isn't a privacy model. It's a trust arrangement.

There's a position that follows this all the way down: if the silicon belongs to Apple, Google or Qualcomm, the stack is compromised at the root and no cryptography above it can fix that. It's coherent. But its conclusion isn't "fix the framework" — it's "wait for a device that doesn't exist yet." I don't think that's wrong so much as it's a different question: not "is this deployment sound?" but "should we be doing any of this on hardware we don't control?" That's a real question. It just isn't one a platform with a compliance deadline in December can act on.

The attestation dependency. A different problem, routinely conflated with the first — and unlike the first, this one the framework does answer. For a wallet to prove that it's the genuine app, unmodified, running on a device that hasn't been tampered with, it needs some form of integrity attestation. The path of least resistance is Google's Play Integrity API or Apple's equivalent, and the Netherlands and Italy use Play Integrity unconditionally. Switzerland dropped it, citing data protection, data sovereignty and freedom of choice. Users of de-Googled Android distributions like GrapheneOS or /e/OS can find themselves locked out of public infrastructure.

The framework requires the property — that a wallet can demonstrate its own integrity — but it doesn't prescribe the mechanism. Member states are free to build wallets with no dependency on US platform services. Play Integrity is a Google service that needs Play Services and a Google account; it is the easiest way to get the property, not the required one. Switzerland is the proof that the alternative ships.

So the dependency isn't in the framework. It's in an implementation choice — and it's a criticism of real deployments measured against the framework's own goals. It's also being made inside the process: there's an open discussion titled, verbatim, "Do not add Google Play Integrity integration" on the Age Verification specification repository.

The browser-native flow hands the OS metadata. When a wallet registers with Android's Credential Manager, it gives the system a credential data blob and a WASM matcher that the OS runs sandboxed against each incoming request. The sandbox protects the matching logic. The system still learns which wallets are registered, which origin asked, when, and which wallet the user picked — it needs that last one to route the request. Not the contents of the presentation. But the metadata graph around it.

Two things bound this. It only applies to the browser-native flow: QR and proximity leave the OS out, and AltID doesn't support the Digital Credentials API at all. And the ARF treats the API as conditional — Topic F sets explicit privacy expectations and states that if they aren't met, support won't be required. Spain's data protection authority filed comments on exactly this, asking about technological neutrality, resilience and digital sovereignty given that support came only from Chrome and Android. The same authority wrote to the ARF editors about Topic T, warning that wallet provider maintenance and support functions could enable tracking and surveillance; the editors responded point by point and amended the document. That's what scrutiny looks like when it works: a regulator, on the record, in a public repository, before deployment.

Network-level linkability. Batches of single-use credentials give you unlinkability at the credential layer — two verifiers never see the same artefact, so there's no shared identifier to join on. That part is real. But in a remote OID4VP flow your device makes an HTTPS request. The verifier sees an IP address, a TLS fingerprint, a timing window. If two verifiers share advertising infrastructure — or if it's simply the same verifier seeing you twice — credential-layer unlinkability doesn't erase network-layer linkability.

This isn't a flaw in the credential design. It's a boundary of what credential design can do. Unlinkability at the protocol layer is necessary and not sufficient, and a serious answer involves the network stack, which nobody's implementation currently has. Proximity flows sidestep it entirely — no network, no problem — which is one reason AltID's offline signed-QR mechanism is more interesting than it first looks.

This one is a whole subject on its own, and it isn't specific to EUDI or to age verification: it's a property of any credential system that speaks over a network. Morten Larsen made the point on my last article better than I'd made it myself, having gone through AltID's published source. It deserves proper treatment and it won't get it here. It belongs on the list anyway, because a design that gets the credential layer right and stops there hasn't finished the job.

Scope creep — and I'm part of it. This is the concern underneath the viral posts. They grope at it without articulating it, but it's real. Nothing above tells you what the wallet is for in 2030. A system built for administrative convenience, once everyone holds one and every service accepts it, generates pressure to expand. That expansion is a political decision taken later, in a different debate, by different people — and the technical elegance of the credential design has no bearing on it whatsoever.

You don't have to speculate about this. Age verification is scope creep happening in real time. Three years ago the EUDI Wallet was pitched as a way to file your taxes and carry your driving licence. Today it's being discussed as a gate for access to the internet, and I run a company that sells that gate. Denis Roio has argued that turning child protection into internet access control is a bad trade regardless of how well the cryptography works. That argument doesn't become wrong because the credential design turned out to be good. They're separate questions.

The technical answer to "can this be done without surveillance?" is yes. That is not an answer to "should this be done at all?" — and I'd rather that second question stayed open than watch my own industry answer it by default.

Every objection above survives contact with the specification. "It logs everywhere you go" doesn't — and the noise it generates crowds out the ones that would actually improve the system.

How to read the next one of these posts

One question separates the posts worth taking seriously from the ones that aren't: does it distinguish between what the specification requires and what a particular deployment might do?

A post that says "this deployment does X, which the ARF doesn't require, and here's the evidence" is doing something useful. A post that says "digital identity means surveillance" has skipped the step where you check.

The ARF is public. The Age Verification Blueprint has a technical portal. The reference implementations are open source on GitHub. Nothing here requires trusting anyone's summary — including this one.

---

Technical claims in this article are based on the EU Digital Identity Wallet Architecture and Reference Framework (published at eudi.dev), the EU Age Verification Blueprint technical specification, and "Om AltID" v1.4 (May 2026), published by Digitaliseringsstyrelsen.