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.

Whatever technical solution is implemented needs to:

1. Not inform the authentication provider about which websites you're visiting.

2. Not inform the websites about your meat space identity.

Unless I'm missing something, what I'm describing satisfies both of these (unless one or both parties are malicious).

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.

It also needs to prevent sharing the age verification token.

> (unless one or both parties are malicious)

It should be assumed (for the purpose of evaluating if a system is actually secure) that they both are, and are working together.

Validation can be done cryptographically so that assertions (like age) can be verified by one party, and consumed by another party, without either of those parties being able to tie the combination together, even if they are actively cooperating.

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.

Add

3. Not allow someone who gets both (1) a log of authentication provider transactions, including timestamps, who was being verified, and whatever output the provider generated, and (2) a log of the website's age checks including timestamps, website accounts, and whatever proof was provided to match them up to associate real IDs from the authentication provider with website account IDs.

To make this work I think any such system will need to be so widely used that there are hundreds or thousands of verifications happening every second at each authentication provider and typical users get verified many times a day, and there should probably be some random delays introduced by the user's computer.

Otherwise it could be too easy to unmask people by looking at verification timing. If you are trying to unmask a user who verified through provider P and P only did a verification for one person that day it is very likely that is the person you are trying to unmask.

Yes, uploading IDs to commercial entities (porn or not) is terrible. Coinbase's recent KYC breach is going to lead to a metric ton of identity theft. While there used to be penalties for securities fraud- no more of that under Trump- there are no penalties for privacy violations and until there are, commercially pervasive KYC is an absolutely awful idea.

Wrt login.gov, as someone who has contracted with fedgov and knows some former 18f people, absolutely excellent humans and technologists- their work notwithstanding, Musk's criminal rampage through fedgov databases and US SC complacence with same has turned me into a rabid libertarian. Cities and states are set up to- and should be funded to- provide individual constituent service. Fedgov is just not.

At this point, I can't even imagine a return to normal governing, let alone good governing. Like imposing enormous fines for ISPs selling user traffic data for packet analysis, to sell name-associated web traffic data to any company or foreign power even when the user is behind a VPN.

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.