[AnthonyMouse]

How is this supposed to protect against timing correlation attacks? If each time User 1234 signs into a particular site, Bob Smith requests a token, we know with high probability that Bob Smith is User 1234 (or anyway is using his ID to request tokens).

You can solve this by giving the user a generic token that asserts that the bearer is e.g. over 18 and is valid on any site for e.g. 30 days, and then Bob can request arbitrarily many tokens on the first of the month and use them as needed. But now all of this ZK proof stuff is making things unnecessarily complicated, because you could then give every user the same token that expires at the end of 30 days. They're fungible and anonymous. Anonymous means you can't distinguish one from the other means you don't need different users to be different, and then you don't have to worry about vulnerabilities in your ZK system.

Which leads back to the main problem with this whole mess: All it takes is for one person with an adult ID to share the token. Which is the problem with all of these systems -- most of the population has an ID and they can share access to it. There is no way to catch them or stop them if they're actually anonymous. If you could, they wouldn't be, and then the system fails as an invasion of privacy.

[numtel]

Yes, there's definitely many scenarios to consider that I've been wondering too about now that I've got it built this way. That's why it's in testnet only.

In my zk group scheme, you do get one token for each epoch. (could be 30 days) It's simply suggested that you wait as long as possible between joining the group on your main account before minting your token on the anon account.

Finding applications for ZK tech is complicated because it only works for such narrow circumstances. Although in your case of "give every user the same token" makes the users anonymous to everyone except the issuer. The issuer is still able to know to whom they're giving them. With a ZK proof, the bearer instead mints the token by proving that they are one from the set of people the issuer has verified. The issuer cannot then break the privacy.

As for mitigating people sharing their tokens, of course that's always a fear but I think mitigation strategies would be unique to each application's use case.

[AnthonyMouse]

> In my zk group scheme, you do get one token for each epoch. (could be 30 days) It's simply suggested that you wait as long as possible between joining the group on your main account before minting your token on the anon account.

I'm not sure this is the same thing. What I was suggesting is that the token you get doesn't depend on the site you're using it on at all. All you do is ask the government for a token and they give you one and you can use it anywhere you want for 30 days and then it expires and you ask for more.

If the tokens are unique to you then you'd have to request a bunch of them because you don't want to use the same one twice on two different sites. If everybody had the same one then that wouldn't matter because the token can't identify any particular user.

> Although in your case of "give every user the same token" makes the users anonymous to everyone except the issuer. The issuer is still able to know to whom they're giving them.

But this is solved by making the token entirely generic.

The problem we have is that Bob wants to visit an adult site without associating that with his social security number. If all Bob does is request the generic token which is the same for everyone and asserts that anybody who has it is an adult, the issuer knows that Bob requested it, but not if Bob has a kink or is buying a beer or is just requesting a token on the off chance he might need one later or is applying for a job at a casino or is hiring for a job at a casino, since this system is so simple the way you verify the token is by requesting it yourself and comparing the one the user submitted to see if it's the same one. It's literally just a single secret password for everyone that the government changes once a month and only gives out to adults.

> As for mitigating people sharing their tokens, of course that's always a fear but I think mitigation strategies would be unique to each application's use case.

It's not clear how you're supposed to mitigate it in this case.

Suppose Bob hates this system and wants to destroy it because it blocks adults without a valid ID from accessing lawful content, e.g. because they're from another country. So Bob hooks up his own valid ID to a server via Tor and configures it to sign any request for age verification from anyone.

Now there two possibilities. One, the system can find out who Bob is and shut him down, which proves that it doesn't protect your anonymity, is a massive invasion of privacy, and must be destroyed. Two, there is actually no way to identify Bob, and then the system has been destroyed by Bob.

[theptip]

I think you end up needing something like trusted compute for biometric verification (eg FaceID) so the authority can delegate real-time validation.

And perhaps you do randomized (risk-based) audits where you actually have to call the government to check in - but in general, physical ID also has the same high-level problem of some baseline of forgeries, and the name of the game is just making it expensive, not making it impossible.

One example of “make it expensive” would be to require unique device IDs to be registered, eg you bring in your iPhone (or Yubikey or whatever) and the DMV verified it’s not actually a non-certified device. This rests on keys being expensive to extract from the Secure Enclave.

Edit to add: lest folks get sidetracked on the requirement for a private company and device, you can also have a baseline in-person flow where you go to the DMV, and they physically verify you, and then hand you a short-lived token that you can then send to whoever wants to verify you. For example, you're signing up with an age-sensitive site, applying for benefits, etc. -- it's non-trivial, but with a bit of infra and UX it could be made usable. The point is that once you have that token, it's pseudonymous, and e.g. PornHub can't figure out your real ID from it, nor can the government tell where the token was submitted.

[AnthonyMouse]

> I think you end up needing something like trusted compute for biometric verification (eg FaceID) so the authority can delegate real-time validation.

That doesn't work because a) not all devices have cameras or trusted whatever and b) there are legitimate reasons to be able to use your ID without being there.

Suppose I want my search engine to be able to index the content on adult sites so it can return those results to adult users. I have a valid ID so I give it to my web crawler, that doesn't mean I'm willing to sit there all day and have it scan my face every 50ms when it moves on to the next website.

> And perhaps you do randomized (risk-based) audits where you actually have to call the government to check in

So then Bob calls in and says "Hi, this is Bob, yes this is a valid ID" and then carries on using it to supply age verification to anyone who wants it.

Unless you mean you're going to actually look into what Bob is using his ID to do, but now we're back to invasion of privacy, aren't we?

> - but in general, physical ID also has the same high-level problem of some baseline of forgeries, and the name of the game is just making it expensive, not making it impossible.

The difference is that physical forgeries are per-individual and generally require the acquirer to meet with the seller in person and risk criminal penalties, whereas digital things can be provided anonymously over the internet with no unit cost.

> One example of “make it expensive” would be to require unique device IDs to be registered, eg you bring in your iPhone (or Yubikey or whatever) and the DMV verified it’s not actually a non-certified device. This rests on keys being expensive to extract from the Secure Enclave.

Bob plugs his certified Yubikey or whatever into his server and has it age verify whatever anybody asks it to over the internet. The key never leaves the device.

Also, even if that wasn't the case, you would only need one person to extract a key from one device. This is the same reason DRM has failed to prevent Hollywood movies from appearing on piracy websites even if the median pirate doesn't know how to extract AACS keys or decrypt Netflix streams. (The reason they persist with the charade is that it prevents third parties from presenting a unified interface across media types and streaming services without their approval, not because it has ever been useful against copyright infringement. How many devices can recommend Netflix shows or YouTube videos based on what you watched on Disney+?)

The problem in this case is even worse because the "vulnerability" is actually an intrinsically mandatory feature. If you have a system that can't allow Bob to age verify whatever he wants to without revealing to the site who he is or the government what he's doing, your system is unacceptable. If you have a system that can do that and then Bob wants to age verify everything for everybody, your system is pointless.