Got ready to read some bullshit,

Vitalik Buterin

nevermind. But damn, what a great read. I haven't given much thought to on-chain ID in years and he lays it out pretty well. Still sounds like encrypted tokens are the way to go, but we all need to have multiple forms for it to protect anonymity.

I'm not sure that is feasible, because in order to trust the answer, I feel the asker must know and trust the one providing the answer. It sounds like you're imagining a system with many different ID providers? What prevents me from creating my own provider that just answers "Yes", even for people under 18? If the site asking does not know it is my fake ID service providing the answer, I'm not sure they can trust any answer.

But I won't pretend to be an expert on this topic, so perhaps it is feasible somehow.

Or the government sets up an age verification service that doesn't store logs and only reports numbers in aggregate. The restricted site sends you and a unique id off to the government service, you verify there and it hands back the id & a yes/no token to the site.

The government already has nearly all the tools to make this happen. They already have id verification services to use & web front ends to copy. Just build the public API and insist restricted sites use it.

No, that's what I wrote as well. The identity service would not know what sites were visited or ideally not even how many sites were visited.

You could make it single-use tokens and rate limit individual users when they request too many tokens in a short time. Someone could still share their tokens with a friend, but it doesn't scale to where thousands are verifying with some stranger's id.

I think it should be easy to identify when an account is being shared. For example if it's used from different ip addresses within a short amount of time