You're making this far more complicated than it needs to be. It requires no cryptography more than a random number generator.

Create a service that generates a random token and then gives it to anyone who is over 18. Any service with any employee who is over 18 can get the token and then compare it to the one submitted by the client. Everyone uses the same token across every service and the token is only available to someone over 18.

The security isn't any worse than having user or service-specific tokens and the privacy is significantly better.

▲

rcxdude 3 days ago | parent | next [-]

There's still privacy issues here: e.g. the service is generally still aware of what services the user is using that require verification. ZKP can eliminate this hole.

▲

AnthonyMouse 3 days ago | parent [-]

> e.g. the service is generally still aware of what services the user is using that require verification

How? The token isn't specific to any user or service. The only information the ID provider gets is that you requested the token and the only thing the service verifying your age gets is the same token shared by everyone over 18.

▲

rcxdude 3 days ago | parent [-]

Ahh, I see what you mean. Yeah, that works if you're gonna completely give up on the whole 'making it hard for someone to share the codes' thing

	▲	AnthonyMouse a day ago \| parent [-]
		There isn't any good way of making it hard for someone to share the codes unless you're going to set up an Orwellian panopticon that tracks where everybody is using them, and since that is totally unacceptable and half measures are uselessly ineffective, it's reasonable to just accept that codes are going to be shared.

▲

zigzag312 3 days ago | parent | prev | next [-]

Same token for multiple people would improve anonymity for sure.

But someone could share this token publicly and then everyone could have it.

▲

AnthonyMouse 3 days ago | parent [-]

> But someone could share this token publicly and then everyone could have it.

How is this any different than using any other way of doing it? It's always the case that someone can provide their ID and let someone else use it.

▲

zigzag312 3 days ago | parent | next [-]

If someone shares their ID publicly, that person could be identified and blocked, so this would probably be limited to sharing of ID to the people in person's social circle.

If someone uploads shared token publicly, it's hard to identify who did it and anyone can use it until you rotate the token for everybody.

	▲	AnthonyMouse a day ago \| parent [-]
		> If someone shares their ID publicly, that person could be identified and blocked, so this would probably be limited to sharing of ID to the people in person's social circle. This was the thing your proposal was supposed to do: > User hasn't revealed any PII data besides "is_over_18" value to the site and identity authority doesn't know which site user is accessing. If you have that, someone sets up a service that uses their ID (or a set of IDs from any data breach) to provide tokens to anyone. If the tokens can be mapped back to the IDs, the alleged privacy protection is fake. If they can't, you don't know whose ID is being used to generate tokens for third parties. Your choices are "no real privacy protection" or "you don't know who is sharing tokens" and the first one is unacceptable, at which point you might as well use the simpler system.

▲

OJFord 3 days ago | parent | prev [-]

In the solution you described as 'far more complicated than it needs to be', this is significantly mitigated by the inclusion of a valid_until timestamp.

	▲	AnthonyMouse a day ago \| parent [-]
		If this is actually a necessary component then you can just change the code for everyone once each ID renewal interval and then the old code expires once the last person with an ID with the old code has their ID expire.

▲

Xelbair 3 days ago | parent | prev [-]

Now make sure that only someone over 18 can generate token, and that token cannot be given to 3rd party for reuse.

▲

AnthonyMouse 3 days ago | parent [-]

The first problem is easy: Write the token on the back of your ID when the government issues it to someone over 18.

The second problem is universally intractable. If you have the cooperation of someone over 18, the service will let you in and has no way of knowing that the person using it is a different person.

▲

OJFord 3 days ago | parent [-]

> The first problem is easy: Write the token on the back of your ID when the government issues it to someone over 18.

Now realise the UK doesn't have a government issued national ID. Not to mention if it did this would mean everyone re-requesting it on their 18th birthday...

	▲	AnthonyMouse a day ago \| parent [-]
		It doesn't have to be a national ID. It doesn't have to be any specific ID at all. Pass a national law requiring local governments to print the token on their local IDs. If you want the token between when you turn 18 and when you next renew your ID then show your ID to any adult at any government office or anywhere else and have them give it to you, or get it from your parents.