| ▲ | zigzag312 3 days ago |
| Wouldn't age verification without revealing identity be solved with a service that acts as an identity authority? 1) Site that needs to verify age generates a globally unique id, creates requested data array ["is_over_18"], valid_until property and hmac signature of this message. 2) Client forwards just the id and requested data array to identity authority. Identity authority returns the id, map of data {"is_over_18": true}, public key information, and signature of returned message. 3) Client returns original message with message received from identity authority to the site. Site verifies that id's and requested data match in both messages, original message authenticity via HMAC and signature of message from identity authority using public key cryptography. User hasn't revealed any PII data besides "is_over_18" value to the site and identity authority doesn't know which site user is accessing. Requirements: User registers and verifies identity at identity authority. Site trusts identity authority. Limitations: Site could, behind the scenes, send the generated ID to the identity authority, informing it which site was accessed using this ID. |
|
| ▲ | magicalhippo 3 days ago | parent | next [-] |
| EU is working on something like this[1] (got limited discussion here[2]). I haven't looked into it very much, but at a glance it doesn't sound terrible. Here's the basic flow[3]: - The User initiates an age verification process by enrolling with an Attestation Provider (AP), which collects the necessary evidence from authentic sources or trusted 3rd party private data sources. - The AP generates a Proof of Age attestation and issues it to the Age Verification App Instance (AVI) of the User. - The AVI presents the attestation to a Relying Party (RP) when attempting to access age-restricted services. - The RP checks the validity of the attestation, referencing the trusted list to confirm the AP's authorisation. So it uses an app on a mobile device as a proxy of sorts. They're also working on incorporating zero-knowledge proofs[4]. [1]: https://digital-strategy.ec.europa.eu/en/news/commission-mak... [2]: https://news.ycombinator.com/item?id=44561797 [3]: https://ageverification.dev/Technical%20Specification/archit... [4]: https://ageverification.dev/Technical%20Specification/archit... |
| |
| ▲ | zigzag312 3 days ago | parent [-] | | Yeah, something like that. I wonder, if their zero-knowledge proof version prevents leaking of identity, if any service is sharing data with the other. |
|
|
| ▲ | skybrian 3 days ago | parent | prev | next [-] |
| Apple is doing something: https://support.apple.com/en-gw/guide/apple-business-connect... > When you integrate with Verify with Wallet on the Web, you disclose the identity information your website requests and for how long. Your website then receives permission to request only the specific data required to address your use case. This prevents users from having to overshare their identity information. Neither the state issuing authority nor Apple can see when and where a user shares their ID. Google is doing something: https://developer.chrome.com/blog/digital-credentials-cross-... > The Digital Credentials (DC) API, allowing Chrome users on Android to present digital credentials from a wallet app on the same device, is already in an origin trial. We are now extending this origin trial to support cross-device digital credentials presentation. With the cross-device capability, users can now scan a QR code displayed on desktop Chrome to establish a connection to securely present credentials from their Android phone. Web standard for Digital Credentials:
https://w3c-fedid.github.io/digital-credentials/ |
|
| ▲ | AnthonyMouse 3 days ago | parent | prev | next [-] |
| You're making this far more complicated than it needs to be. It requires no cryptography more than a random number generator. Create a service that generates a random token and then gives it to anyone who is over 18. Any service with any employee who is over 18 can get the token and then compare it to the one submitted by the client. Everyone uses the same token across every service and the token is only available to someone over 18. The security isn't any worse than having user or service-specific tokens and the privacy is significantly better. |
| |
| ▲ | rcxdude 3 days ago | parent | next [-] | | There's still privacy issues here: e.g. the service is generally still aware of what services the user is using that require verification. ZKP can eliminate this hole. | | |
| ▲ | AnthonyMouse 3 days ago | parent [-] | | > e.g. the service is generally still aware of what services the user is using that require verification How? The token isn't specific to any user or service. The only information the ID provider gets is that you requested the token and the only thing the service verifying your age gets is the same token shared by everyone over 18. | | |
| ▲ | rcxdude 3 days ago | parent [-] | | Ahh, I see what you mean. Yeah, that works if you're gonna completely give up on the whole 'making it hard for someone to share the codes' thing | | |
| ▲ | AnthonyMouse a day ago | parent [-] | | There isn't any good way of making it hard for someone to share the codes unless you're going to set up an Orwellian panopticon that tracks where everybody is using them, and since that is totally unacceptable and half measures are uselessly ineffective, it's reasonable to just accept that codes are going to be shared. |
|
|
| |
| ▲ | zigzag312 3 days ago | parent | prev | next [-] | | Same token for multiple people would improve anonymity for sure. But someone could share this token publicly and then everyone could have it. | | |
| ▲ | AnthonyMouse 3 days ago | parent [-] | | > But someone could share this token publicly and then everyone could have it. How is this any different than using any other way of doing it? It's always the case that someone can provide their ID and let someone else use it. | | |
| ▲ | zigzag312 3 days ago | parent | next [-] | | If someone shares their ID publicly, that person could be identified and blocked, so this would probably be limited to sharing of ID to the people in person's social circle. If someone uploads shared token publicly, it's hard to identify who did it and anyone can use it until you rotate the token for everybody. | | |
| ▲ | AnthonyMouse a day ago | parent [-] | | > If someone shares their ID publicly, that person could be identified and blocked, so this would probably be limited to sharing of ID to the people in person's social circle. This was the thing your proposal was supposed to do: > User hasn't revealed any PII data besides "is_over_18" value to the site and identity authority doesn't know which site user is accessing. If you have that, someone sets up a service that uses their ID (or a set of IDs from any data breach) to provide tokens to anyone. If the tokens can be mapped back to the IDs, the alleged privacy protection is fake. If they can't, you don't know whose ID is being used to generate tokens for third parties. Your choices are "no real privacy protection" or "you don't know who is sharing tokens" and the first one is unacceptable, at which point you might as well use the simpler system. |
| |
| ▲ | OJFord 3 days ago | parent | prev [-] | | In the solution you described as 'far more complicated than it needs to be', this is significantly mitigated by the inclusion of a valid_until timestamp. | | |
| ▲ | AnthonyMouse a day ago | parent [-] | | If this is actually a necessary component then you can just change the code for everyone once each ID renewal interval and then the old code expires once the last person with an ID with the old code has their ID expire. |
|
|
| |
| ▲ | Xelbair 3 days ago | parent | prev [-] | | Now make sure that only someone over 18 can generate token, and that token cannot be given to 3rd party for reuse. | | |
| ▲ | AnthonyMouse 3 days ago | parent [-] | | The first problem is easy: Write the token on the back of your ID when the government issues it to someone over 18. The second problem is universally intractable. If you have the cooperation of someone over 18, the service will let you in and has no way of knowing that the person using it is a different person. | | |
| ▲ | OJFord 3 days ago | parent [-] | | > The first problem is easy: Write the token on the back of your ID when the government issues it to someone over 18. Now realise the UK doesn't have a government issued national ID. Not to mention if it did this would mean everyone re-requesting it on their 18th birthday... | | |
| ▲ | AnthonyMouse a day ago | parent [-] | | It doesn't have to be a national ID. It doesn't have to be any specific ID at all. Pass a national law requiring local governments to print the token on their local IDs. If you want the token between when you turn 18 and when you next renew your ID then show your ID to any adult at any government office or anywhere else and have them give it to you, or get it from your parents. |
|
|
|
|
|
| ▲ | Xelbair 3 days ago | parent | prev [-] |
| That limitation is enough to kill such proposal. Also authority could also do it.
Nothing stops them from that. |
| |
| ▲ | zigzag312 3 days ago | parent [-] | | Yes, if site shares data with identity authority then a malicious identity authority can also share full identity data with the site. |
|
