Digital ID done right: verifiable claims without the surveillance

I’m Australian. I live in the UK. Both of my governments are equally responsible for the mess that’s unfolding right now.

Australia’s Online Safety Amendment Act kicked things off in December 2025, banning under-16s from social media and requiring platforms to prove they’re enforcing it.¹ The UK’s Online Safety Act followed through in July 2025, mandating “highly effective” age verification for any site hosting adult content—a certain hub beginning with P, a site that specialises in fans, Reddit, the lot—with fines up to £18 million or 10% of global turnover for non-compliance.² Imgur took one look at the compliance requirements and pulled out of the UK entirely.³ And it’s spreading. France approved an under-15 social media ban in January 2026.⁴ Spain announced theirs today—under-16s, with “real barriers that work, not just checkboxes.”⁵ Denmark’s ban is expected to pass by mid-2026. Greece is drafting theirs now. The EU’s Digital Services Act already requires age-appropriate protections across the bloc.⁶

Every major democracy (bar the freedom one) is converging on the same conclusion: platforms need to know how old their users are. And the instinct is right. We do need to protect developing minds from harmful content. The evidence on adolescent mental health and unconstrained social media exposure is damning, and the status quo of letting 12-year-olds self-declare their way past a checkbox has been a farce for twenty years.

But here’s the thing. Every implementation so far has been designed around the wrong question. Governments are asking “how do we identify people?” when they should be asking “how do we verify claims without identifying anyone?”

The result is a landscape where age verification means uploading a photo of your passport to a third-party service and hoping they don’t get breached. Or running your face through an AI model that guesses your age from your bone structure—biometric surveillance by another name. The UK’s approach under the Online Safety Act saw VPN usage spike over 1,400% on the first day of enforcement, as adults quite reasonably decided they’d rather route their traffic through Ireland than hand their driving licence to a site that specialises in fans.

The government should very much stay out of your business. But businesses should feel confident they can’t be held liable when the age check gets worked around. A 14-year-old with a bushy beard might just defeat today’s facial estimation. A borrowed credit card defeats the payment check. A VPN defeats the geo-fence entirely.

So let’s explore: can we un-fuck this?

Yes.

You already use most of this technology

Here’s the thing that makes this whole situation so maddening: the building blocks for privacy-preserving identity verification aren’t some far-off research project. They’re running on your phone right now… while you’re reading this.

Every time you log into a website and it remembers who you are without asking for your password again, there’s a good chance a JSON Web Token (JWT) is doing the heavy lifting.⁷ A JWT is just a signed blob of information. It has three parts: a header that says how it was made (signed), a payload full of “claims” (who and what type of meatbag you are), and a signature that proves the whole thing hasn’t been tampered with.

Here’s what a typical JWT payload looks like when you log into, say, your bank:

{
  "sub": "user_38291",
  "name": "Will Hackett",
  "email": "will@example.com",
  "iat": 1706918400
}

See that sub field? That’s a unique identifier. It’s how the bank knows you’re you. And that’s fine for banking—they’re legally required to know who you are. But now look at what every age verification system is doing: they’re taking this same pattern and cramming your entire identity into it just to answer the question “is this person old enough?”

That’s like asking someone for their passport because you want to know if they prefer tea or coffee.

What if the token looked like this instead?

{
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "iat": 1706918400
}

No sub. No name. No email. No date of birth. Just the answers to the questions that actually matter, signed by someone you trust. The service asks “are you over 18?” and gets a cryptographic true back. It never learns your name, your birthday, your address, or the fact that you’re a 30-something Australian living in London who still eats cheese despite what it does to him.

That’s the entire concept. The rest of this article is about making it real.

How the signatures actually work (without the maths degree)

A signed token is useless if you can’t verify who signed it. This is where JSON Web Key Sets (JWKS) come in.⁸ It’s a fancy name for a simple idea: the signer publishes their public key at a URL, and anyone who receives a signed token can check it against that key.

{
  "keys": [{
    "kty": "EC",
    "kid": "uk-gov-age-verification-2026",
    "use": "sig",
    "crv": "P-256",
    "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
    "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
  }]
}

Imagine the UK government publishes one of these at gov.uk/.well-known/jwks.json. Now when a site that specialises in fans receives an age verification token claiming you’re over 18, it doesn’t have to trust you. It doesn’t have to phone the government. It fetches the public key, checks the signature, and either the maths works or it doesn’t. No phone home. No API call. No “let me just check with HMRC (tax office).” The public key is public. The signature is maths. Done.

This is how every OAuth login already works. When you click “Sign in with Google,” the site you’re logging into doesn’t call Google to check if your token is legit—it grabs Google’s published JWKS and verifies the signature locally.

We’ve been doing this for over a decade. The infrastructure is literally sitting there, bored.

Just wait, you eager beaver… we’ll get into the privacy stuff in a minute.

But what if we only show part of the token?

Regular JWTs have a problem: the signature covers the entire payload. You can’t rip out the fields you don’t want to share without breaking the signature. If the government signs a token containing your age brackets, your name hash and your biometric template, you have to present the whole thing or nothing.

Enter Selective Disclosure JWTs (SD-JWTs).⁹ The concept is gloriously simple. The issuer signs the full credential, but each claim gets its own disclosure. The holder—that’s you, on your phone—can choose which claims to reveal. The rest stay hidden, but the signature still verifies.

So the government issues you this:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_13": true,
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "name_hash": "sha256:a1b2c3d4...",
  "biometric_template": "...",
  "nationality": "AU"
}

But when the site that specialises in fans asks for age verification, your device presents only this:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_18": true
}

The signature still checks out. The site gets its answer. And it never learns your name, your nationality, or the frankly embarrassing fact that you’re not yet 21 in whatever jurisdiction still cares about that.

W3C Verifiable Credentials take this even further with zero-knowledge proofs—cryptographic methods that let you prove a statement is true without revealing the underlying data at all.¹⁰ “Is this person over 18?” stops being a data disclosure and becomes a mathematical proof. The site doesn’t receive "over_18": true. It receives a proof that the statement is true, with no data attached.

It’s like a bouncer who can somehow verify your age by looking at a sealed envelope without opening it. Cryptographers are weird and wonderful people.

How this should actually work on your phone

Right, let’s put it all together. I promise this is less complicated than the current process of uploading a selfie holding your passport to a third-party verification service that may or may not get acquired by a company you’ve never heard of next year.

Step 1: Get your credential (once). Your device provides a framework for managing verifiable claims. You authenticate with your government’s identity provider once, on-device. In Estonia, that’s your eID. In the EU by end of 2026, it’ll be your EUDI Wallet.¹¹ In the UK, it could be GOV.UK One Login or whatever eventually replaces it. The government’s IdP issues a verifiable credential to your device—age brackets, name hash, biometric template—signed by the government’s key, verifiable against their published JWKS endpoint.

It lives in your device’s secure enclave. You do this once. Then you forget about it.

Step 2: The platform wraps it. Your platform provider (Apple, Google) acts as a proxy issuer. It takes the government-signed credential and re-issues it with a dual signature—the government’s original signature plus the platform’s own. A verifying service can now confirm two things: the claim came from a real government IdP, and it’s being presented through a legitimate platform. Crucially, neither the government nor the platform learns which service you’re presenting to. The government sees “Apple requested a credential.” Apple sees “a credential was stored.”

Neither sees “Will is trying to access a site that specialises in fans at 2am on a Tuesday.” Which is important. Not to me, personally… but in general.

Step 3: Answer questions, not data requests. When a service needs to verify a claim, the exchange looks like this:

Fans specialist → Your device: "Is this user over 18?"
Your device → Secure Enclave: [biometric check, signature generation]
Your device → Fans specialist: { "over_18": true, "sig": "..." }

In this case “Fans specialist” is… the service you’re trying to access…

The service asks a question. Your device answers it. The service gets a cryptographic yes or no. Nothing more. Not “what is your date of birth?” but “are you over 18?” Not “what is your name?” but “does this SHA-256 hash match?” Not “show me your face” but “does the on-device biometric check pass?”

For name verification, a service submits a hash—SHA-256 of first, middle and last name—and the credential returns whether it matches. The service never sees your actual name. For photo verification, the credential includes a biometric template (a mathematical representation, not a photo). The check runs locally on your device. The result—match or no match—is signed and returned. The biometric data never leaves your device. Ever.

Estonia nailed the architecture. Shame about the scope.

I’ve written before about Estonia’s digital identity system.¹² They’ve been running national eIDs since 2002, with X-Road providing the interoperability backbone connecting over 450 organisations.¹³ Every citizen over 15 has a digital identity. 99% of government services are online. The system saves an estimated 2% of GDP annually.¹⁴ It’s genuinely impressive. If you ever want to feel bad about GOV.UK, spend an afternoon reading about how Estonians file their taxes.

But Estonia’s system is a closed ecosystem. It works brilliantly for Estonian services—government, banking, healthcare, tax—because the entire stack is Estonian. You can’t use your Estonian eID to verify your age on Instagram, and Instagram has absolutely no reason to integrate with Estonia’s X-Road for a country of 1.3 million people. Fair enough.

The EU’s Digital Identity Wallet, mandated under eIDAS 2.0 for deployment by end of 2026, is designed to bridge this gap.¹⁵ Every member state must provide at least one EUDI Wallet. Very large online platforms must accept it for strong authentication. The wallet uses W3C verifiable credentials with selective disclosure built in.¹⁶ This is closer to the right model. But it still positions the wallet as an identity tool rather than a claims tool. The shift that needs to happen is from “prove who you are” to “answer this specific question.” It’s a subtle distinction, but it’s the whole game.

Apple and Google are 90% of the way there

This isn’t just a government problem. The platform providers need to build the integration layer, and the good news is they’ve almost accidentally built most of it already.

Apple manages the Secure Enclave—a hardware-isolated processor specifically designed for cryptographic operations and biometric data.¹⁷ Passkeys, built on the FIDO2/WebAuthn standard, already use this exact infrastructure for passwordless authentication.¹⁸ The private key never leaves the device. Biometric verification happens locally. The server only sees a cryptographic proof. Sound familiar? It’s the same pattern.

Extending this to verifiable claims is architecturally straightforward. Apple provides a framework. You authenticate with your government IdP through that framework. The credential is stored in the Secure Enclave alongside your passkeys. When a service requests a claim, the flow is identical to a passkey authentication: biometric check on-device, cryptographic proof sent to the server. The service knows the claim is valid. It doesn’t know who you are. Android has equivalent capabilities with StrongBox and the Trusted Execution Environment.

Browser vendors need to extend WebAuthn or create a parallel standard for claim verification. A website should be able to request a verified claim as easily as it requests a passkey. Same API pattern. Same UX. Same security model. The plumbing exists. It just needs someone to connect it. Given that Apple, Google and the FIDO Alliance have already proven they can coordinate on passkeys—which was itself a minor miracle of corporate cooperation—this isn’t as far-fetched as it sounds.

What nobody gets to see

Let me be specific about the privacy guarantees, because this is the part where most digital ID proposals fall apart and people rightfully start muttering about surveillance states.

Your government never learns which services you use. The platform provider proxies requests to the government IdP using its own keys. The government sees “Apple requested a credential.” It doesn’t see “Will visited a site that specialises in fans.” This matters.

Services never see your data. They receive cryptographic answers to specific questions. Not your name. Not your date of birth. Not your photo. A signed yes or no from a trusted issuer chain. That’s it.

No unique identifiers by default. The credential contains claims, not identifiers. There’s no user ID for services to correlate across platforms. You’re a set of verified facts, not a trackable entity. You can prove you’re over 18 on fifty different sites and none of them can tell it’s the same person. Try doing that with a passport upload.

For services that genuinely need to identify you—banking, law enforcement, regulated industries—the system supports a special class of credential with a government-issued identifier. But this identifier can only be dereferenced when both the platform provider and the government cooperate, using a key-splitting mechanism that requires both parties. One key alone is useless. This makes mass surveillance structurally impossible while preserving legitimate identification for regulated use cases. It’s the cryptographic equivalent of needing two keys to launch a nuclear missile, except instead of ending the world, you’re verifying someone’s identity for a mortgage application. Much less dramatic. Same maths.

Everything happens on-device. Verifier keys never leave the secure enclave. No central server processes your biometrics. No cloud service sees your government credentials. The proof is generated locally and transmitted to the service. Nothing else moves.

What needs to happen

The technology is ready. The standards exist. The hardware is deployed on billions of devices. What’s missing is the will to coordinate, which, given that we’re talking about governments, platform providers and standards bodies, should only take… let’s be optimistic and say five years… or a hundred in the UK.

Governments need to publish keys for their identity providers and issue verifiable credentials that support selective disclosure. Estonia’s already done the hard part. The EU is mandating wallets by 2026. The UK is exploring digital ID. Australia is… well, Australia is trying to figure out how to stop 14-year-olds from creating TikTok accounts, which feels like it might benefit from having a decent age verification system rather than just threatening platforms with fines. The infrastructure commitments are in motion. Someone just needs to make them talk to each other.

Platform providers need to build the framework layer—on-device credential management, proxy issuance, secure enclave integration for claim verification. Apple and Google are 90% there with passkeys. The remaining 10% is extending the same architecture to verifiable claims. Given that both companies would very much like to be the gatekeepers of your digital identity (and charge a modest fee for the privilege), I suspect the business incentive exists.

Browser vendors need to extend WebAuthn or create a parallel standard for claim verification. A website should be able to request a verified claim as easily as it requests a passkey authentication. Same API pattern. Same UX. Same security model.

And services need to stop asking for documents and start asking questions. “Is this user over 16?” is a yes/no question. It shouldn’t require a passport. It shouldn’t require a selfie. It shouldn’t require uploading a photo of your driving licence to a company headquartered in a jurisdiction you can’t spell. It requires a single signed boolean, verified against a published public key.

We’ve spent twenty years building identity systems that treat surveillance as a feature. It’s time to build one that treats privacy as the architecture.

The next time someone asks you to upload your passport to prove you’re old enough to look at memes, remember: the technology to do this properly already exists. It’s been battle-tested for a decade. It’s running on your phone right now. The only thing stopping us is the same thing that stops most good ideas in technology—getting three different groups of people who don’t particularly like each other to agree on a standard.

So basically, any day now…

Australian Government eSafety Commissioner: Social Media Age Restrictions ↩
UK Online Safety Act 2023 ↩
The Register: Imgur exits the UK as parent company faces fine — geo-blocked all UK users from 30 September 2025 rather than comply with Online Safety Act age verification requirements ↩
Al Jazeera: French MPs approve law seeking ban on social media for children below 15 — approved January 2026 by 116 votes to 23 ↩
Euronews: Spain to ban social media platforms for children under 16 — announced 3 February 2026 at the World Government Summit ↩
European Commission: The Digital Services Act ↩
IETF RFC 7519: JSON Web Token (JWT) ↩
IETF RFC 7517: JSON Web Key (JWK) ↩
IETF: SD-JWT-based Verifiable Credentials (SD-JWT VC) ↩
W3C: Verifiable Credentials Data Model v2.0 ↩
European Commission: European Digital Identity — mandates EUDI Wallets for all member states by end of 2026 ↩
Will Hackett: Reclaiming the commons: the case for an accountable internet ↩
e-Estonia: X-Road interoperability platform — connects over 450 organisations via open-source, decentralised data exchange ↩
University of Liverpool: As the UK plans to introduce digital IDs, what can it learn from pioneer Estonia? ↩
eIDAS 2.0 Regulation (EU) 2024/1183 — entered into force May 2024, wallets due by end of 2026 ↩
W3C: Verifiable Credentials Implementation Guidelines — Selective Disclosure and Zero-Knowledge Proofs ↩
Apple: About the security of passkeys — passkeys use Secure Enclave for key generation and biometric verification ↩
FIDO Alliance: Passkeys — FIDO2/WebAuthn standard for passwordless authentication ↩