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
But the bank and the horn content provider could collude and that would let the bank know that you're watching horn (shame, shame!).

The ZKP approach aims to prevent this attack method.

>>zb3+FP
Chase.com currently is using:

mPulse

Google Marketing Platform Meta

LinkedIn Ads

Trade Desk

Aggregate Knowledge (Trans Union)

Adobe Audience Manger

Can you elaborate on how the risk of ironbank and hornpub colluding by de-anonymizing you via rainbow tables or IP forensics is substantially greater than Chase and PornHub using - Google Marketing?

>>jwally+EU
It isn't, but due to bureaucracy, when designing a solution, it's that solution that has to be "secure" without really considering that the current outside situation is already insecure..

Anyway I'm not advocating for this solution, just addressing the question directly.