5 ms·

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

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.

Xelbair 1y ago
That limitation is enough to kill such proposal. Also authority could also do it. Nothing stops them from that.
- zigzag312 1y ago
  Yes, if site shares data with identity authority then a malicious identity authority can also share full identity data with the site.
AnthonyMouse 1y ago
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.
- Xelbair 1y ago
  Now make sure that only someone over 18 can generate token, and that token cannot be given to 3rd party for reuse.
  - AnthonyMouse 1y ago
    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 1y ago
      > 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 1y ago
        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.
- rcxdude 1y ago
  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 1y ago
    > 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.
magicalhippo 1y ago
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-makes-available-age-verification-blueprint https://digital-strategy.ec.europa.eu/en/news/commission-mak... [2]: https://news.ycombinator.com/item?id=44561797 https://news.ycombinator.com/item?id=44561797 [3]: https://ageverification.dev/Technical%20Specification/architecture-and-technical-specifications/#31-interactions https://ageverification.dev/Technical%20Specification/archit... [4]: https://ageverification.dev/Technical%20Specification/architecture-and-technical-specifications/#7-experimental-features https://ageverification.dev/Technical%20Specification/archit...
- zigzag312 1y ago
  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 1y ago
Apple is doing something: https://support.apple.com/en-gw/guide/apple-business-connect/abcb17bcda04/web 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-device-ot 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/ https://w3c-fedid.github.io/digital-credentials/

Xelbair 1y ago

That limitation is enough to kill such proposal. Also authority could also do it. Nothing stops them from that.

zigzag312 1y ago
Yes, if site shares data with identity authority then a malicious identity authority can also share full identity data with the site.

AnthonyMouse 1y ago

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.

Xelbair 1y ago
Now make sure that only someone over 18 can generate token, and that token cannot be given to 3rd party for reuse.
- AnthonyMouse 1y ago
  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 1y ago
    > 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 1y ago
      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.
rcxdude 1y ago
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 1y ago
  > 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.

magicalhippo 1y ago

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-makes-available-age-verification-blueprint https://digital-strategy.ec.europa.eu/en/news/commission-mak... [2]: https://news.ycombinator.com/item?id=44561797 https://news.ycombinator.com/item?id=44561797 [3]: https://ageverification.dev/Technical%20Specification/architecture-and-technical-specifications/#31-interactions https://ageverification.dev/Technical%20Specification/archit... [4]: https://ageverification.dev/Technical%20Specification/architecture-and-technical-specifications/#7-experimental-features https://ageverification.dev/Technical%20Specification/archit...

zigzag312 1y ago
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 1y ago

Apple is doing something: https://support.apple.com/en-gw/guide/apple-business-connect/abcb17bcda04/web 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-device-ot 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/ https://w3c-fedid.github.io/digital-credentials/