[ineptech]

I'm not suggesting that people actually authenticate to Pornhub using Login.gov's oauth, they would continue to auth (or not) as they do now. Login.gov can issue a token saying, in essence, "A user authenticated to me, and that user over 21, but I'm not going to identify them, I'll just give you a random GUID so this token will be unique".

edit to add more details, since I'm thinking it through: the token would need to include the issue date and be signed obviously, and would be ephemeral. Properly implemented, it could be done entirely in the browser (Firefox would have a "age verification provider" pull-down) in way that's transparent to the user and both private and secure. And since you have to be 18 to get a credit card, essentially any service you pay for with a credit card in your own name ought to be able to attest your age, even if it hasn't done KYC or scanned a government ID.

[NekkoDroid]

What I've been thinking of is (although very similar):

1. Government has private/public key or similar for "Is above 18/21/legal age" 2. Site generates random data 3. Sends data to user 4. User somehow sends the data to government for signing (be it via some login or whatever) 5. User gets signed data back and sends it to the site 6. Site verifies the data against the public key

I guess the signing part could be done with all sorts of different methods, but the site would still need to be able to somehow figure out how it was signed and get the appropriate public key for it.

The main problem I see is that this isn't exactly stateless, so you do need some form of (semi-)persistent identifier on the server side.

[ndriscoll]

You can put all of the state into the browser:

1. Site generates an AES key for the verification request. Gives it to the browser along with (short) expiration time in an encrypted cookie (so the browser can't see or forge the key). Encrypts a request to .gov (using .gov public key) saying "use <key> to encrypt a token for <requesting IP>". Gives that request to the user to present to .gov.

2. Browser asks user if they'd like to request age verification. Proceed.

3. Gov does ID verification. Checks requesting IP matches. Creates tokens for "over16", "over18", "over21", and any other magic ages that laws exist for, each individually encrypted with site AES key and IP-bound. Gives all tokens back to the browser so .gov doesn't know which will be used. e.g.

    {
      "over13": "<encrypted token>",
      "over16": "<encrypted token>",
      "over18": "<encrypted token>",
      "over21": "<encrypted token>"
    }

4. Browser asks user which token they want to give to the site (that could actually be part of step 2, and the site could indicate which one it would like).

5. Site gets single relevant token back, decrypts the cookie, and uses the key to decrypt the token. Checks requesting IP in response token matches. Checks token signature against .gov public key.

.gov only learns that some age-restricted service was requested, but not even which age. Server only learns user is over the required age. Browser can't see or modify any of the messages between .gov and site because they're all encrypted.

With such a protocol, adding more age-restricted use-cases (e.g. buying cigarettes/alcohol, gambling, social media/advertising/anything where you need COPPA's "I am over 13" assertion) would increase overall privacy.

[stvltvs]

It also needs to prevent sharing the age verification token.

[ahtihn]

Look into "Verifiable Credentials" (aka VCs)

You can have a digital ID that you store in a wallet. You can then present the credential and selectively disclose information.

There's a bunch of W3C specs and RFCs around this.