US Supreme Court Upholds Texas Porn ID Law

Would it not be reasonable and safe and private to implement age verification through login.gov? An Oauth implementation that knows your identity and age can produce a verifiable token that attests your age but not identity. The only way your identity would leak would be if both the porn site and the oauth retain the tokens (which they would both claim not to do else no one would use this), and the attacker gets access to both.

I know it's unlikely to happen because of America's (misguided IMO) extreme distaste for digital government ID, but it seems like the current solution (people uploading pictures of their driver's license to porn websites) is worse in every possible way.

You need something like Verifiable Credentials to do this properly imo. You don't want something like OAuth because the login service knows which websites you're requesting the login from.

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.

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.