I've been trying to figure out how zero-knowledge stuff would work in practice for age verification, where "when issued" (or extremely coarse, like what year), "to whom", and "where it's used" are hidden from everyone except the individual holding the proof (since that's the gold standard, and the only one worth accepting).

I get that ZK techniques work, and reveal "nothing". That's useful.

But if they reveal nothing, isn't it wide open for abuse? Couldn't one over-18-person's proof become everyone's proof, because they can't tell it's the same proof, and the issuer can't tell where or how often the proof is being used? Or are there ways to construct data leaks that are not user-identifying but are abuse-identifying (and what would that even mean)?

> But if they reveal nothing, isn't it wide open for abuse? Couldn't one over-18-person's proof become everyone's proof, because they can't tell it's the same proof, and the issuer can't tell where or how often the proof is being used?

Yep!

This is why the concept of zero knowledge age gating is such a trap for technically minded people. They imagine receiving a private cryptographic object that can be used to anonymously confirm that the government says it was issued to someone over 18.

That’s completely useless because a single leaked token could be used forever, so nobody actually considers this.

All of the real proposals have various compromises baked in. Some people want to require device attestation, so you could only do this handshake from a government approved device running a government approved operating system. Forget using Linux or maybe even a general purpose computer at all.

Other proposals involve online government handshakes in various ways, with a pinky promise that the government won’t keep logs or tap it for national security purposes. So we get back to anonymous by trust only.

This may help: https://blog.vrypan.net/2026/06/29/260629-whats-wrong-with-e...

That's where trusted computing comes in.

Your proof proves two claims. That the person proving their age is over 18, and that they're using a device and software that hasn't been tampered with. That software requires human presence at every age check.

ZKPs for age assurance are trading off privacy at the expense of software malleability.

Note that this has nothing to do with open source; it's perfectly fine to release the source code for the relevant software. You can even allow for reproducible builds and full auditability if that's what you want.

Briefly, your government issues you a digital signed copy of a document, such as a driver's license or passport, that gets bound to a hardware security element that you own. In current implementations these are the secure elements of smart phones, but there is no reason that standalone hardware security elements could not be supported.

When you want to provide information from that document to a third party a protocol is used which allows you to demonstrate to the third party that (1) you have a document from the government bound to your hardware security device, (2) you have unlocked the hardware security device, (3) and the document says what you say it says (e.g., "the birthdate field in this document contains a value that is more than 18 years in the past").

This third party gets no additional information about the contents of your document. The protocol takes place entirely between your device and the third party, so the government that issued you the bound document has no idea when or if you use it.

Someone over 18 person could indeed decide to help others prove age, but they would either have to do it in person or be willing to loan their unlocked security element to those others.

There are different ways to think about this:

1. Imagine what the protocol would look like without privacy (zk allows you to “sign” a computation, so just do the computation in the clear)

2. Imagine what the protocol would look like by revealing a hash of the passport only (the idea of a “nullifier”, a unique identifier that hides the data and and can be revealed to prevent replays)

The first one should already answer your question: the way you would prevent replays or portability (I use your proof) is to attach some sort of session context to your proof

My understanding as someone who is just learning about the tech is that zero-knowledge isn't a great description of what is happening. The issuer (some party with the proof, like the government) shares the knowledge and that is only valid for a single verifier. So knowledge is held and is shared, just the minimum amount possible to be credible.

Idk if this scheme is zero knowledge, but what's wrong with it? :

- you enter ph and must age-verify. It says 'your secret: "capable peanut", enter age proof below'.

- you go to age-knower (e.g bank or government page). You provide the secret phrase, and you get back a cryptographically signed json with the secret phrase, a claim 'above18', and a field stating who attested for the age (e.g government or bank or whoever).

- you paste this signed json (maybe encoded as base64 or something) into ph. It will verify that the attestee is good, then use it's public key to verify the signature, before checking that the secret is the correct one, and that it contains the age-claim.

Is the problem that if ph and the attestee colludes they can compare the secret string and figure out who you are?

The proof is bound to a cryptographic key stored in a tamper-resistant module (as in a phone).

See https://educatedguesswork.org/posts/age-verification-id/#dev... for some more detail.

Even if you had to submit a picture of your driver's license, you can send someone else's

This is basically the double spending problem which has been solved in various ways.