zlacker

>>sschue+(OP)
Here's my crack at a good-enough solution for the U.S. It doesn't have a ton of granularity - but the concept is shovel ready now, dirt cheap, and privacy preserving.

Video Demo: https://www.youtube.com/watch?v=MmcUJ5u65Q0

Actual Demo: https://app.hornpub.click

How it works:

1) Go to app.horpub.click

2) Create an ephemeral passkey

3) Extract its public-key and id (this binds the credential you're creating to your device)

4) The user copies this data to their bank's Age-Verification-Section

5) The bank creates an object that it signs with an attestation of the user's age (KYC) and their pass-key-public-key

6) The user copies this back to app.hornpub.click

7) The passkey is verified on the server, the bank's signature is verified by the server, some other meta-data is verified to make sure nothing weird is happening.

8) The user's age has been verified by their bank without the bank knowing who is asking for verification

* This method is more private than anything requiring sharing your photo-id online

* This method doesn't trigger GLBA or GDPR (user copies data themselves)

* This method is free to the merchant (hornpub)

>>jwally+GE
What's crazy to me is why they didn't go for that kind of implementation. This works well, ensures privacy, can be audited easily, and doesn't need a f*cking app on my phone.

>>Someon+TG
If you read the guidelines they actually want to implement a double-blind approach with ZKPs, which imo is significantly better than a challenge-response pub key system in term of privacy.

If you're not familiar this would mean the verifier doesn't learns anything except a statement about attributes (age, license, etc); and the EU doesn't learn what attributes have been tried to verify or by who.