To be clear, I’m not advocating for online age verification. I’m very much against it in any form. I’m just curious from a technical standpoint if it’s possible somehow to construct an accurate age verification system that doesn’t compromise a user’s privacy? i.e., it doesn’t expose the person’s identity to anyone nor leaves behind a paper trail that can be traced to that person?


In principle it should be possible to do a zero-knowledge proof.
This means that the website asking for age verification asks a yes/no question like “Is this user 18+?” and the age verification service (like a digital ID provided by the government or whatever) answers “yes” or “no” accordingly, but without telling anything else about the user. Also, the verification service should ideally not know who asked for the age verification.
So the site you want to visit only knows the thing they need to know: Whether you are 18+ or not. Nothing else. And the age verification service only knows somebody asked for age verification and provided the answer, but do not know which site you visited.
This is all possible, but I don’t have high hopes this is the intended implementation of any government seeking age verification, so don’t get your hopes up.
Does that mean the government sees all the sites I’ve visited?
No, that’s what I wrote as well. The identity service would not know what sites were visited or ideally not even how many sites were visited.
I worked in this field for 3 years, a lot of the core parts are written, but there are a few key pieces missing and no one has taken it to real production.
You can use a passport in pretty much any country and prove you’re over a certain age. Here is a demo: https://github.com/dog-18/dog18
The parts that are missing are primarily around making secure nullifiers, which prevents someone from reusing identities, but also without revealing any private information. We were pursuing research that allowed nullifier generation in MPC where none of the servers or the users knew the “salt” that their identity was hashed with, so no one could recover the original piece of unique data (like their passport number, even if a govt had a hunch about which passports signed up to a service) but it would also prevent them from signing up with multiple accounts. We got our funding cut pretty bad and management was a mess, so I left and that research I think was shut down. This really is the key part to actually make that viable in the real world though. It’s maybe a year worth of research and a year worth of production left to make that practical.
There are some pretty strong arguments that even zk proof is a flawed way of preserving privacy though, in a variety of ways. It prevents pseudonymity by enabling one-user-one-account, and it leaves users vulnerable to being coerced to reveal their full online activities by handing over cryptographic keys.
Got ready to read some bullshit,
Vitalik Buterin
nevermind. But damn, what a great read. I haven’t given much thought to on-chain ID in years and he lays it out pretty well. Still sounds like encrypted tokens are the way to go, but we all need to have multiple forms for it to protect anonymity.
If there’s one person who knows their applied zk proofs, it’s that guy.
Not monero or zcash devs?
Indeed, technologically it is absolutely possible in multiple ways.
But the tempting possibilities of doing more than that are just too great.
The one who asked the verification service also shouldn’t know who the verification service is, imho.
I’m not sure that is feasible, because in order to trust the answer, I feel the asker must know and trust the one providing the answer. It sounds like you’re imagining a system with many different ID providers? What prevents me from creating my own provider that just answers “Yes”, even for people under 18? If the site asking does not know it is my fake ID service providing the answer, I’m not sure they can trust any answer.
But I won’t pretend to be an expert on this topic, so perhaps it is feasible somehow.
This is possible if there’s a central authority for that that everyone can agree to trust, like the government records directly. The issue is ensuring the rest of the chain remains anonymous so the only thing the authority gets is the request that an undisclosed service is verifying John Doe is 18+ and nothing else. And that’s not something many governments are going to want to allow with the increasingly alarming amount of authoritarian leadership.
doesn’t this just raise the authentication requirements? like in the uk we got added checks for who was could work, and lots of deliveroo drivers shared the login + password of someone they knew who was verified.
You could make it single-use tokens and rate limit individual users when they request too many tokens in a short time. Someone could still share their tokens with a friend, but it doesn’t scale to where thousands are verifying with some stranger’s id.
I think it should be easy to identify when an account is being shared. For example if it’s used from different ip addresses within a short amount of time