There’s already an answer to that. My state (and several others) have digital IDs that exist. I have an app on my phone called mID (<state> Mobile ID). I can present proof of just my age to a bartender using the app. They don’t see my address, birthday, DLnumber… nothing… Just that I’m indeed 21+.

I can present a qr barcode that will grant someone the ability to see my ID… I can choose what information to send by default… and if someone is requesting more information I can view/approve if I choose to.

There’s no reason why a simple request to this platform couldn’t do it. I have the other side of the app that let’s me read other people’s qr codes and validate whatever information I “need” to validate. If I can do it as an individual… I don’t see why website’s couldn’t.

Now… Do I want the state to particularly know that “BustySluts.com” wants to view my id? I can see this being intrusive… but there’s already answers like charging 1 penny to a credit card as well.

I would wholeheartedly be against my ISP doing anything other than being a carrier for my data. The ISP wouldn’t be able to tell if I’m on my computer or if my child is anyway. Middleware or not.

I’d preface this by saying the idea is bad and the legislators passing such laws should be voted out.
That said, looking at it from purely a technology point of view, it’s going to be difficult to implement in a secure and privacy preserving fashion. At minimum, there needs to be some sort of third party trust site where an adult site operator can validate age requests. In order to preserve privacy, this will need to operate via hashes and challenges which prevent either the adult website operator or the trust provider from marrying up user and usage data.
To spitball it:

1. All internet users are required to register with third party trust site (Trust Site).
   1a. Because any sort of profit motive would make this site untrustworthy, this probably has to be a government run site.
   1b. By law, the site would be forbidden from collecting or retaining logs or metadata of requests.
   1c. By law the site would be exempt from all wiretap requests including by law enforcement and security agencies. Violations would need to be pursued and punished very harshly. Which is one reason this whole thing is a Bad Idea™. Enforcement would never happen.
2. When a user visits any website (not just adult websites), the site sends a random nonce to the browser.
   2a. The nonce would be tied to the session via a session cookie.
   2b. The nonce is purely random with no site identifying information.
3. The user’s web browser communicates this nonce to the Trust Site along with the user’s credentials.
   3a. Nothing else is ever transmitted to the Trust Site. Just the nonce and credentials.
4. The Trust Server validates the credentials, appends a single bit to the nonce (Response).
   4a. A 1 means “is adult” a 0 means “is not adult” (Adult Bit)
5. The Trust Server digitally signs the Response with its private key.
   5a. The Trust Site’s public key is publicly available and expected to be cached by all websites.
6. The Trust Server sends the Response back to the user’s browser.
7. The user’s browser sends the Response back to the website.
8. The website validates the digital signature on the Response.
9. The website provides/denies content based on the Adult Bit in the Response.

As I said, this is just a spitball and probably has holes/problems. But, it is an attempt to look at the issue constructively.

This problem is always approached from the wrong angle (requiring verification of adults to view adult material) instead of the more freedom- and privacy-preserving method of requiring child-friendly sites to advertise to the browser that they are suitable for child web browsers.

What I mean by this, and the way that I would solve this problem, is to introduce an HTTP header such as X-Child-Friendly: true or X-Content-Rating: E and to put the onus on parents to set the child’s web browser to only allow browsing sites which return this header. Every browser would need to have a “Parental Control” mode that restricts browsing to sites that return this header, but this could easily become a standard. Instead of having every adult site implement your legislative controls, now you just need child-friendly sites to add a header to their responses.

The whitelist approach is less likely to allow adult sites to slip through the net, compared to the blacklist approach.

For those who say that children would find a way around this by installing a different browser or unlocking the parental controls: it should be the responsibility of parents to monitor their child’s access to the internet and installation of software. The current approach of trying to enforce age-verification on adult sites just shifts the problem to other adult sites that are not under the jurisdiction of the legislation.

Forcing age-verification for adults also has a huge bureaucratic cost and potential for abuse and loss of privacy. I think we know why legislators prefer this approach, and it isn’t to protect the children.

There’s no good way to do this without that information being available somewhere we don’t want it for privacy reasons. You shouldn’t trust a company with your information any more(or less) than the government.

Stop trying to be a nanny state, if people want to view porn, let them. If kids try to view porn, that’s up to the parents to manage.

The ISP middleware is an interesting idea, basically an SSO (think the “Sign in with Google” you see everywhere). However, this would require some level of integration between every ISP and adult site, which would get seriously tedious as such things roll out all over the country. This doesn’t even get into the fact that each law would vary somewhat in the specific requirements and that it just kicks the job to verifying IDs and ages to the ISP instead of the downstream site.