3 ms·

Yes, the government should provide digital ID services. On my Coinpassport site in the documentation, [0] I make this plea to governments. I've made a testnet

by numtel 3y ago

Yes, the government should provide digital ID services. On my Coinpassport site in the documentation, [0] I make this plea to governments. I've made a testnet version that uses a basic ZK circuit to provide anonymity. [1] There's so many holes to my approach though with overlapping renewals, dual citizenship, etc. If governments simply provided this service it would be great. Passport NFC chips get close. [2] They contain the passport data signed and there's a project to extract those details into a ZKSNARK proof which is awesome but this doesn't prove that the person holding the passport is the person verifying like Stripe Identity does with the photo check. And it requires the nfc reader hardware, but that's not too bad for a requirement. Maybe something like risczero could prove that a phone photo matches the passport photo using ZK but it seems like a big project. [0] https://coinpassport.net/docs.html https://coinpassport.net/docs.html [1] https://test.coinpassport.net https://test.coinpassport.net [2] https://eprint.iacr.org/2022/878.pdf https://eprint.iacr.org/2022/878.pdf

theptip 3y ago
Yeah the hard case to solve is “prove it’s still <ID principal> that is generating the challenge”. With GenAI I wonder if images will be considered valid ID for long. “Generate a new video of face with camera pan” is currently hard (not impossible) to forge, but I doubt it will be in a year or two. You get back to multifactor auth, but then the system is more stateful, and still, what is the incentive not to share your ID & password with underage friends? (These challenges will also be faced with the OP’s scheme as well.)
AnthonyMouse 3y ago
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 3y ago
  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 3y ago
    > 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.

by numtel 3y ago

theptip 3y ago

Yeah the hard case to solve is “prove it’s still <ID principal> that is generating the challenge”. With GenAI I wonder if images will be considered valid ID for long. “Generate a new video of face with camera pan” is currently hard (not impossible) to forge, but I doubt it will be in a year or two. You get back to multifactor auth, but then the system is more stateful, and still, what is the incentive not to share your ID & password with underage friends? (These challenges will also be faced with the OP’s scheme as well.)

AnthonyMouse 3y ago

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 3y ago
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 3y ago
  > 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.