You know how there are stores that sell restricted substances and verify your age by checking a provided ID? Have those same stores sell a cheap, sealed card with a confirmation code on it. You can enter that code online to verify any service. The code expires after a set period of time after it's first use to prevent sharing and misuse.

This system would be as secure as the restrictions on the restricted substance, such as alcohol, so it should be fine for "protecting the children"

The German government ID card has an age verification function:
It only sends one bit to the requesting service: Yes, over 18 or No, not over 18.
And it doesn't transmit back any data, so the state doesn't know what services you access.
Since you are required to have an ID card and the state knows your age, this would be a pretty good option (in Germany).

for a moment, let's ignore all of the conspiratorial conjecture (not that it isn't warranted).

by exposing an API for web services to identify the users age/birthday, how does that solve the issue of "protecting children online".

what's stopping a bad actor from identifying, tracking, and grooming children directly based on this same mechanism?

right now the majority of kids online are protected through anonymity, but once they are identified they can be targeted directly and the adults responsible for their well being are blissfully unaware because "the government is tracking their age".

also. what comes next is worse than the date. online content ratings. because there's no point in tracking age if you can't apply a ratings system.

Imagine entire swaths of the internet banned because the content rating doesn't meet the government requirements.

this is less about tracking users and more about censoring dissent.

I'm not sure if this is part of the "setting aside" stuff, but I'd ask why age needs to be verified and not simply stated.

I'm the admin on this device, I say I'm 50, why does the website need to check some ID to prove I'm 50? They trust what I reported, and if I lied to them that's on me. It shouldn't be the websites' job to validate.

I'm pretty sure there is already a cryptographic protocol that can do this, but that's not the point. We do NOT need age verification in software, it makes no sense. We need parents to take care of their own children because why would open-source software do the job of failed parenting? It's a social issue, not something that can be solved with technology. Or we would have put shock-collars on every kids when they don't behave.

For an implementation to work, it should: * Let the service know that the user is an adult by providing a verifiable proof of adulthood (eg. A proof that’s signed by a trusted authority/government) * Not let the service know any other information about the user besides what they already learn through http or TCP/IP *

Seems like that's exactly what https://yivi.app/en/ can do.

Here's one good answer: https://crypto.stackexchange.com/a/96283

It has the downside of requiring a physical device like a passport or some specific trusted long-running locally-kept identity store held by the user. But it's otherwise very good.

Another option does not require anything extra be kept by the user, but does slightly compromise privacy. The Government will not be able to track each time the user tries to access age-gated content, or even know what sources of age-gated content are being accessed, but they will know how many different sites the user has requested access to. It works like this:

1. The user creates or logs in to an account on the age-gated site.
2. The site creates a token T that can uniquely identify that user.
3. That token is then blinded B(T). Nobody who receives B(T) can learn anything about the user.
4. The user takes the token to the government age verification service (AVS).
5. The user presents the AVS with B(T) and whatever evidence is needed to verify age.
6. The AVS checks if the person should be verified. If not, we can end the flow here. If so, move on.
7. The AVS signs the blinded token using a trusted AVS certificate, S(B(T)) and returns it to the user.
8. The user returns the token to the site.
9. The site unblinds the token and obtains S(T). This allows them to see that it is the same token T representing the user, and to know that it was signed by the AVS, indicating that the user is of age.
10. The site marks in their database that the user has been age verified. On future visits to that site, the user can just log in as normal, no need to re-verify.

All of the moving around of the token can be automated by the browser/app, if it's designed to be able to do that. Unfortunately a typical OAuth-style redirect system probably would not work (someone with more knowledge please correct me), because it would expose to the AVS what site the token is being generated for. So the behaviour would need to be created bespoke. Or a user could have a file downloaded and be asked to share it manually.

There's also a potential exposure of information due to timing. If site X has a user begin the age verification flow at 8:01, and the AVS receives a request at 8:02, and the site receives a return response with a signed token at 8:05, then the government can, with a subpoena (or the consent of site X) work out that the user who started it at 8:01 and return at 8:05 is probably the same person who started verifying themselves at 8:02. Or at least narrow it down considerably. Making the redirect process manual would give the user the option to delay that, if they wanted even more privacy.

The site would probably want to store the unblinded, signed token, as long-term proof that they have indeed verified the user's age with the AVS. A subsequent subpoena would not give the Government any information they could not have obtained from a subpoena in an un-age-verified system, assuming the token does not include a timestamp.