EFF launches Age Verification Hub

For the folks in the back row:

Age Verification isn't about Kids or Censorship, It's about Surveillance

Age Verification isn't about Kids or Censorship, It's about Surveillance

Age Verification isn't about Kids or Censorship, It's about Surveillance

Without even reaching for my tinfoil hat, the strategy at work here is clear [0 1 2]. If we have to know that you're not a minor, then we also have to know who you are so we can make any techniques to obfuscate that illegal. By turning this from "keep an eye on your kids" to "prove you're not a kid" they've created the conditions to make privacy itself illegal.

VPNs are next. Then PGP. Then anything else that makes it hard for them to know who you are, what you say, and who you say it to.

Please, please don't fall into the trap and start discussing whether or not this is going to be effective to protect kids. It isn't, and that isn't the point.

0 https://www.eff.org/deeplinks/2025/11/lawmakers-want-ban-vpn...

1 https://www.techradar.com/vpn/vpn-privacy-security/vpn-usage...

2 https://hansard.parliament.uk/Lords/2025-09-15/debates/57714...

That is untrue

(This includes being robust against law enforcement action, legal or otherwise.)

When I say "if we have to know you're not a kid, we have to know who you are" I'm not stating an actual truth, but the argument as it is playing out politically.

The EU age verification solution says implementations SHOULD implement[1] their ZKP protocol[2]. Not linking it to the user is stated as an explicit goal:

Unlinkability: The goal of the solution is to prevent user profiling and tracking by avoiding linkable transactions. Initially, the solution will rely on batch issuance to protect users from colluding RPs. Zero-Knowledge Proof (ZKP) mechanisms will be considered to offer protection. More details are provided in Section 7.

[1]: https://ageverification.dev/av-doc-technical-specification/d...

[2]: https://ageverification.dev/av-doc-technical-specification/d...

Assuming that's even a goal, of course. The cited paragraph mentions RPs (the websites, from what I understand), but makes no mention of attestation providers.

In the non-ZKP presentation, the "holder" (phone) sends the credential to the relying party (website), and the RP executes some verification algorithm. In the ZK presentation, the holder executes the verification algorithm and sends to the RP a proof that the algorithm was executed correctly.

The "proof" has this magical property that it reveals nothing other than the check passed. (You will have to take on faith that such proofs exist.) In particular, if the check was the predicate "I have a signature by ISSUER on HASH, and SHA256(DOCUMENT)==HASH, and DOCUMENT["age_gt_18"]=TRUE", anybody looking at the proof cannot infer ISSUER, HASH, DOCUMENT, or HASH, or nothing else really. "Cannot infer" means that the proof is some random object and all HASH, DOCUMENT, ISSUER, etc. that satisfy the predicate are equally likely, assuming that the randomness used in the proof is private to the holder. Moreover, a generating a proof uses fresh randomness each time, so given two proofs of the same statement, you still cannot tell whether they come from the same ISSUER, HASH, DOCUMENT, ...

The currently favored approach works like this. The DOCUMENT contains a device public key DPK. The corresponding secret key is stored in some secure hardware on the phone, designed so that I (or malware or whatever) cannot extract the secret key from the secure hardware. Think of it as a yubikey or something, but embedded in the phone. Every presentation flow will demand that the secure element produce a signature of a random challenge from the RP under the secret key of the secure hardware. In the ZKP presentation, the ZKP prover produces a proof that this signature verifies correctly, without disclosing the secret key of the secure hardware.

In your example, the parent could give the phone to the kid. However, in current incarnations, the secure hardware refuses to generate a signature unless unlocked by some kind of biometric identification, e.g. fingerprint. The fingerprint never leaves the secure hardware.

How does the issuer (e.g. the republic of France) know that DOCUMENT is bound to a given fingerprint? This is still under discussion, but as a first bid, a French citizen goes to city hall with his phone and obtains DOCUMENT after producing a fingerprint on the citizen's phone (as opposed to a device belonging to the republic of France). You can imagine other mechanisms based on physical tokens (yubikeys or embedded chips in credit cards, or whatever). Other proposals involve taking pictures compared against a picture stored in DOCUMENT. As always, one needs to be clear about the threat model.

In all these proposals the biometric identification unlocks the secure hardware into signing a nonce. The biometrics themselves are not part of the proof and are not sent to the relying party or to the issuer.