The verifier registrar: the role two ecosystems invented separately

They converged on everything except the part that decides

Open Google Wallet's identity verification spec, put it next to the European age verification Blueprint, and the first impression is déjà vu. Both speak OpenID4VP over the browser's Digital Credentials API. Both use mdoc credentials per ISO/IEC 18013-5, presented through the 18013-7 profile. Both sign the request as a JAR with ES256 and an X.509 chain, identify the verifier by the hash of its certificate, and require the response to come back encrypted under an ephemeral key minted for that single transaction.

The convergence reaches somewhere I still find remarkable: the zero-knowledge scheme is literally the same one. Google publishes its ZK track on longfellow-libzk-v1. Annex B of the European Blueprint evaluated five candidate schemes, picked ECDSA Anonymous Credentials by Frigo and shelat, and the reference implementation it cites is that same Google library. Two ecosystems that don't coordinate ended up, on the hardest cryptographic piece of the lot, running the same code.

And yet they are not interchangeable. Not remotely.

Because the protocol was never the hard part. The hard part is the question no protocol answers: who do I trust, and who gets to decide that?

Two questions, not one

People talk about "the trust model" as if it were one thing. In age verification it is two, and the two ecosystems answer each of them differently.

First: who vouches for the credential? When a proof arrives claiming someone is over 18, what entitles me to believe it?

In the European framework, the answer is a chain that terminates in an accreditation. An accredited attestation provider issues the credential; its signing certificate appears on a European Trusted List published in ETSI TS 119 612 format and signed by the Commission. The verifier downloads that list, checks the signature against a known signer, and only then accepts the issuer. The important property isn't that the list exists: it's that it is signed and auditable. Anyone can download it, verify it, and contradict whoever claims an issuer is on it.

It's worth clearing up a common misconception here, because it changes the whole comparison that follows: the issuer doesn't have to be a public administration. Nothing in the framework says the age credential must come from whoever issues the identity document. A bank, a telco, a notary or an identity platform can perfectly well issue it — verifying a document, or relying on information they already hold that establishes age, since a bank has known its customer's date of birth since onboarding. What the framework fixes isn't who issues, it's who decides that issuer counts: a member state, through an accreditation procedure, with that decision published in a signed list anyone can check.

In Google Wallet, the answer is a file of IACA certificates that Google publishes. And here is a detail that gets skipped and that strikes me as the most important thing in the whole business: for ID Pass — the credential Google is rolling out in Europe — the IACA is Google's own. The documentation is explicit: apart from the United States, every country uses the same IACA certificate for ID Pass. The anchor isn't a public accreditation, nor the state that issued the document the credential derives from: it's the company serving the wallet itself.

And the credential itself has a different provenance. To enrol an ID Pass, the user photographs the data page of their passport, reads the NFC chip with their phone, and passes a video selfie check. That is a serious document verification pipeline and it works — it is in production in the UK, Brazil, India, Singapore and Taiwan. But it is a credential derived by the wallet provider from a document the user shows it, not an attestation issued by the authority that issued that document.

Then there's the other route, which Google announced in June: private issuers. Its first national partner for EU age assurance is Sparkasse. That is, a German savings bank issuing an age credential into an American company's wallet, anchored in that company's IACA. In deployment terms it is far quicker than waiting for twenty-seven states to accredit issuers, and that is presumably why it exists.

And this is where the earlier misconception would have wrecked the argument. What's interesting is not that Sparkasse is a private company: that same savings bank could be an accredited issuer inside the European framework, issuing the AV credential, if Germany opted for that credential and accredited it for the purpose. Same issuer, same data, same age check. What differs between the two cases isn't who issues — it's who said that issuer counts, and whether that decision can be looked up. In one case it's a member state through a public procedure, and the decision lives on a signed list. In the other it's a company, and the decision lives in its trust store.

I don't say this as a reproach. It's a perfectly defensible design choice with an enormous advantage: you don't need twenty-seven states to finish their rollouts before you have something that works today. But it is a different kind of claim. One says "someone the State of X accredited for this attests that this person is of age, and you can check the accreditation." The other says "someone we admitted to our trust store attests that they are, and the admission isn't public." Both can be true, and in both the issuer might be exactly the same company. They are not the same sentence, and a verifier that treats them as equivalent is quietly blending two levels of assurance.

And yet the cryptography is the same

There's an implementation detail that changes how this difference looks, and it surprised me when I checked it. You'd expect that accepting two different trust models means writing two verifiers. It doesn't: the cryptographic part is identical. An X.509 chain validator takes a handful of trusted certificates in DER plus a chain to check against them, and it could not care less whether those bytes came out of a European Trusted List signed by the Commission or a PEM file published by a company. The OpenWallet Foundation's reference mdoc library says so in its own function signature: it asks for an array of bytes, and nothing else.

So supporting both ecosystems isn't new cryptography. The entire difference lives upstream of the validator, in how you got those bytes. And there they have nothing in common:

• Provenance. A Trusted List is a signed document. You verify its signature against a signer you pinned in advance, and from there the anchor set vouches for itself: you can redo the check offline six months later and prove what it said. A certificate file carries no signature over its content; its only provenance is the TLS connection to the domain you downloaded it from. There's nothing to pin and nothing to re-verify. If you want evidence, you have to manufacture it yourself — keep a copy and its hash, and record when you fetched it.
• Status. Every Trusted List entry carries its role and its status — this certificate may issue; this service is in force or withdrawn. That's revocation of the role, not just of the certificate: an issuer can stop counting without its X.509 expiring or landing on any revocation list. A certificate file is flat. There, "revoking" means someone deletes a line, and without re-fetching you never find out — nor can you tell "it's gone" from "the fetch failed".
• Freshness. The list tells you when it expires as evidence. The file has no date: a stale copy and a fresh one are indistinguishable.

Put differently: in one case trust travels in a document that defends itself; in the other it travels in a channel, and the channel leaves no trace. The expensive part of accepting Google isn't verifying. It's being able to say afterwards, with proof, what you based the acceptance on — and that you have to build by hand, because the ecosystem doesn't provide it.

Second: who vouches for the verifier? When a wallet receives a request saying "prove you're over 18," how does it know the asker is entitled to ask?

Before answering, we have to stop and mark a boundary that gets skipped far too easily. Europe doesn't have one framework, it has two, and they answer this question in opposite ways.

The age verification Blueprint doesn't register the verifier at all. It's the AV-specific profile, the one deployed today for checking that someone is of age. In it, the verifier's identifier is the hash of its own certificate: self-asserted, with nobody behind it vouching; and the QR fallback path, used when the browser doesn't expose the credentials API, goes unsigned. Nobody accredits anybody. The wallet doesn't know who is asking, and the design assumes it doesn't need to, because the credential can only answer one thing: yes or no on age. The minimisation doesn't come from authorising the asker — it comes from the answer being unable to say anything else. It isn't a gap in the profile: it is the profile.

The full EUDI framework does register, and it's the one that applies when age comes not from an AV credential but from the attributes of the PID, the wallet's identity credential. There the relying party registers with its member state and obtains two certificates: an access certificate, answering "who is making this connection?", and a registration certificate, answering "which data may they request, under what legal basis, and for what purpose?". And it isn't decorative: the registration certificate bounds the request — if the RP asks for a credential its certificate doesn't authorise, the wallet catches it and warns the user, who decides whether to go ahead; some member states have opted for a strict reading and reject the request without asking. That's overasking prevention written into the protocol, not into policy. Public register, identifiable authority, administrative procedure, right of appeal.

The gap between the two is enormous and shouldn't be averaged away. Comparing "Europe" with Google without saying which of the two lets you tell more or less any story you like.

In Google Wallet, the verifier fills in an intake form and Google decides. If it likes what it sees, it adds your root certificate to its trust store. It's a private allowlist, run by a company, with no publication and no external audit.

And now the honest comparison, which is less comfortable than it looked: on the rail that actually verifies age today, the European one doesn't examine the verifier and Google's does. Google reads a form and decides; the AV Blueprint reads nothing, because it solved the problem from the other end — bounding what the credential can say instead of bounding who may ask. Two legitimate, opposite strategies: one limits the asker, the other limits the answer. Europe's machinery for accrediting verifiers exists, and it's better designed than a form… but it lives in the other framework, the PID one, which is also where there's rather more than a boolean to protect. And as of today it still isn't operating: no authorities are issuing those certificates in production yet.

And then both ran into the same problem

Where there's a gate, there's a queue. This applies to the EUDI framework and to Google — not to the AV Blueprint, which by registering nobody has neither this problem nor the control that causes it. There will be millions of services needing to check age, and neither twenty-seven national registers nor a review team in Mountain View can absorb that one at a time.

Both ecosystems arrived, separately, at the same structural answer: an intermediary tier that vouches for the ones below it. And this is where you see how different they are.

The European framework — the EUDI one, again, the one that registers — calls it an intermediary and has it recognised and regulated: it's Topic 44 of the ARF. The design is elegant: two certificates travel with each transaction. The intermediary's access certificate, which answers "who is making this connection?", and the end RP's registration certificate, which answers "on whose behalf, and are they legally authorised to ask for this?". The intermediary doesn't absorb its client's identity: it carries it. The RP still registers in its own country, still owns responsibility for what it asks, and the wallet can see both facts separately.

Google calls it a Verifier Registrar, and the mechanism is different: you become a private certificate authority inside Google's trust store. Your root goes on the allowlist; you issue leaf certificates for each of your clients. The end RP never talks to Google Wallet. From the outside, what's visible is your signature.

The difference is one of character, not of shape. In one case the intermediary is a figure anticipated by the rules, with responsibility distributed and traceability of who asked for what. In the other it is a figure under contract, where the registrar stands between Google and the world — and takes on what that implies.

What being the registrar involves

Worth being concrete here, because the Verifier Registrar terms are public and say very specific things. None of them is arbitrary: they are what you would expect from someone managing risk at global scale. But you want to understand them before you sign, not after.

You answer for your clients. Verbatim: you will be responsible for "all acts, omissions and liabilities" relating to your clients' use of the data. And there is an indemnity obligation against third-party claims arising from misuse by you or by your clients.

In the other direction, the ceiling is low. For the EEA you contract with Google Ireland, and total liability is capped at the greater of two figures: ten thousand euros, or what you have paid in the preceding twelve months. Since access to the data isn't billed, in practice the number is ten thousand euros. The asymmetry is striking, though not unusual for a service offered at no direct cost: whoever doesn't charge for access limits their exposure through it.

Access can be suspended without notice if Google reasonably believes there's a violation. Not an unusual clause in terms of service, but it changes what you can promise: build an SLA on a channel a third party can cut without warning and you're selling availability you don't control.

English law, English courts, with LCIA arbitration in London as the fallback.

And a data protection asymmetry that deserves a lawyer. With Google, the relationship is governed by the Controller-to-Controller Data Protection Terms — independent controllers. But an intermediary verifying on behalf of its clients is, in all likelihood, a processor with respect to them. Two different hats in the same transaction. It can be made to hold together, but it has to hold together on paper before you sign, not after.

On top of that sits the operational load: separate certificates for each RP during the initial launch period, each with a globally unique Distinguished Name; a revocation list you publish and maintain yourself, with an obligation to revoke promptly against abusive RPs; and a human review of two to three business days for every new client you onboard. Google acknowledges the overhead and says it will revisit alternatives — it mentions RP metadata hashes — after the initial rollout.

The CRL is worth dwelling on, because it's the most underestimated piece. A revocation list isn't a file: it's a public service whose outage invalidates other people's operations. It has uptime, it has monitoring, it has an emergency procedure. Anyone who thinks being a CA means running openssl a couple of times a year has never operated one.

And here the earlier point comes back, now from the verifier's side. In the European framework the status travels inside the signed list: if a revocation channel fails, the list still tells the truth about who is in and who has been withdrawn. In Google's model there is no such second source — the issuer anchors are a file with no status, and the registrar's CRL is the only revocation channel in the whole chain. A CRL outage doesn't degrade the signal: it erases it. That doesn't make the model unworkable, but it does raise the bar considerably on what "maintaining a revocation list" means.

And a note on the business model: Google's FAQ is clear that its current model and preference is to work directly with registrars and their direct end RPs, not with nested reseller or chained intermediary models. It isn't a contractual prohibition, but it's a statement of intent that closes the indirect channel in practice. Aggregator branding, by contrast, is entirely optional in the metadata: white-labelling fits.

The inversion I thought I'd found

What follows is the part I've rewritten most, because the first version was too satisfying to be true.

You'd expect the regulated European framework to be the strict one on data minimisation and the private framework to be the lax one, and reading Google's requirements the temptation is to conclude the opposite holds. It doesn't. What's there isn't an inversion: it's a difference in when it gets checked and who can act.

Google requires, per client and kept up to date, an annex listing: the data elements requested and the retention period for each one, individually; a description of the purpose and a justification of necessity; live links to the RP's terms and privacy policy; the approved territory; and an additional justification if you request a non-aggregated field when an aggregated one is available — if you ask for date of birth when age_over_18 exists, you have to explain why. It's the GDPR's minimisation principle turned into a form you must keep current and cannot deviate from without written approval.

It sounds like something Europe doesn't ask for. But it does. To register in the EUDI framework, an RP declares its intended use and links the service's privacy policies; and the registration certificate that comes out of that bounds which credentials it may request and for what purpose, to the point that the wallet catches and flags any request that exceeds what was declared — and, where the member state has opted for the strict reading, rejects it outright. That isn't a reviewer reading an annex: it's the protocol, on every transaction, with nobody having to watch.

The real difference is the timing and who holds the lever. Google examines the declaration before letting you in — two to three business days per new client — and its lever is contractual: cutting off your access. In the European framework nothing obliges the register to audit that declaration at the moment of registration, and in practice it generally isn't; it could be scrutinised in detail, but the substantive control doesn't live there. It lives afterwards: every registered RP has a data protection supervisory authority behind it, overseeing its GDPR compliance. That's a figure Google's model has no equivalent for, and the difference in power is not small — a review team can shut you out of its ecosystem; a supervisory authority can inspect you, order you to stop and fine you, and its decisions are appealable before a court.

So it isn't that one is strict and the other lax. One puts up a gate: prior control, private, passed once and then trusted. The other appoints a supervisor: subsequent control, public, never quite passed because it can turn up at any time. Each fails differently — the gate can't see what happens after it opens; the supervisor only acts once something has already happened.

What does still strike me as finer on Google's side is the per-item detail: retention period element by element, and the written justification for the non-aggregated field. That's a granularity the registration declaration doesn't descend to, and which in Europe is resolved through the RP's accountability to its supervisory authority — where the GDPR already had it, with more force but less artefact.

And it's worth remembering where none of this is needed: on the AV rail there's no declaration to make, because all that travels is an age_over_NN. There's no purpose to bound and no fine-grained field to justify when the credential can only say yes or no. All this machinery — on both sides — is the answer to a problem the AV Blueprint designed away.

Worth saying without triumphalism, in both directions: a private form is not democratic oversight, and the power asymmetry remains total, because whoever reviews the form can also suspend you without notice. But a control that gets applied every day is a control, and arriving early has value. There is something the European side could take from that operational granularity — the per-item detail, written down and kept current — without giving up an ounce of its legal force or its independent supervision.

From the announcement to the issuer list

On 4 June 2026, at Money 20/20 Europe, Google announced that ID Pass would reach Spain, Italy, France, Ireland and Estonia before the end of the summer, alongside an age credential built with Sparkasse as its first national partner for EU age assurance.

Today is 5 September. The public supported-issuers page lists mDLs from eleven North American jurisdictions, and ID Pass from the United States, Brazil, India, Singapore, Taiwan and the United Kingdom. Not one EU member state. The only European entry on that list left the Union years ago.

I don't flag this as a gotcha: identity rollouts slip, that's normal, and five countries at once is ambitious. I flag it because it marks where to look. An announcement tells you what someone intends to do; a demonstration tells you the pipe works; the issuer list is the only thing that determines whether a verifier can accept anything today. Three different things, easily conflated — especially since the first is the one that circulates most.

So if you're deciding a wallet strategy, the data point you need isn't in the press release. It's on that list, and it's worth re-reading every few weeks, because "we accept any wallet" means very different things depending on the month.

The intermediary sees every transaction

There's a structural discomfort in this whole architecture worth saying out loud, because it affects both models equally, and because whoever names it first earns the right to be believed later.

If one entity sits between many services and many wallets, that entity sees every transaction of all of them. Even if the zero-knowledge proof is flawless. Even if no personal data is retained. Even if the credential only ever reveals a boolean.

Annex B of the Blueprint already warns that unlinkability isn't free, and that a too-fine validity period on the attestation can become a tracking vector. But the intermediary's risk is a different class: it isn't cryptographic, it's positional. Seeing that one domain requested a verification at a given instant identifies nobody on its own. Seeing that for thousands of domains, continuously, is another matter.

The only defensible answer is to design so you cannot correlate — not retaining what would make it possible, separating retention windows, and submitting the whole thing to audit — rather than promising you won't. And this is not a criticism of Google's model or of Europe's: it's a property of any architecture with an intermediary tier. I include myself without reservation — any service I build in this position, espuni included, inherits exactly the same problem and the same obligation. Whoever sells privacy, starting with me, has a duty to explain what they can see and to design so they cannot correlate. It isn't a finger pointed at anyone; it's the house rule for all of us who live in this layer.

The open question

A few weeks ago I wrote that in digital identity, formats converge and trust doesn't. That piece compared two public, sovereign ecosystems — the EU and Switzerland — and the conclusion was almost reassuring: two administrations making different technical choices, both in good faith, and a mutual-recognition problem that gets solved when somebody signs something.

This is a different thing. Here one side of the contrast is a company. And that introduces an asymmetry the earlier comparison didn't have: today, one of the two can adjust the rules faster than the other — add a metadata requirement, change the certificate profile, revise the terms of access. It is the natural counterpart of its greater deployment speed, and nothing prevents those terms from maturing and evening out as the ecosystem settles. In the meantime, though, it pays to know what you're signing.

On the contrary: it's an argument for integrating with Google Wallet with your eyes open. Google will have real volume on Android long before national wallets reach critical mass, and a service that needs to check ages today can't afford to wait. The question isn't whether to integrate, but doing it knowing exactly what you're signing, and not conflating two things that sound alike: accepting any wallet is market coverage; complying with eIDAS 2 is something else. You can — and probably should — want both. They are not the same.

What does seem clear is that being someone else's registrar is going from oddity to first-class role in both worlds. In one it's a figure anticipated by the rules, with distributed responsibility and a right of appeal. In the other it's a contract with aggregate liability, a ten-thousand-euro ceiling and suspension without notice.

Whoever takes on both roles at once — and in a multi-wallet ecosystem, someone will have to — will be operating simultaneously under two regimes that resemble each other in almost nothing. That isn't a project. It's a permanent cost. And it's worth booking it as one from the start, before it becomes the second year's surprise.

---

This article draws on public documentation consulted on 5 September 2026: Google Wallet's verifier registrar integration guide, its Terms of Service, its digital identity and credentials FAQ, and its supported issuers and IACA certificates page; the European age verification Blueprint and its Annex B on zero-knowledge proofs; the EUDI Wallet Architecture and Reference Framework (Topic 44, intermediaries); and public coverage of Google's announcement at Money 20/20 Europe on 4 June 2026. Commercial terms and issuer lists change; check the sources before making decisions. It reflects my own reading as an engineer working on the relying party side of age verification; it does not represent any organisation, and it is not legal advice.