Anonymous credentials. A central authority with verified age information of each person grants credentials that verify the age to third parties, but the authentication tokens used with the third party can't be used by the third party nor the central authority to identify anything else about the credential holder.
This is technically possible but politically impossible. Any system you make like this will get special government peaking exceptions added making it non-anonymous and probably rank corruption from industry lobbying will add some sort of user tracking for sale with data that is poorly anonymized. Once the sham system is in place they'll probably expand the requirement to other things.
The central authority should be someplace that already has your non-anonymous ID data, so using your ID for age verification doesn't give them any new ID information. The only new thing that them doing age verification adds is that they might keep a list of verification tokens they have issued.
Someone who obtained copies of the verification tokens you requested might go to various social media sites and ask them who used those tokens, allowing matching up your social media identities with your real identity.
That's fixed by making it so the token that is given to the social media site is not the token that came from site that checked your ID. You give the social media site a transformed token that you transform in such a way that the social media site can recognize that it was made from a legitimate token from the ID checker but does not match anything on the list of tokens that the ID checker has for you.
> The central authority should be someplace that already has your non-anonymous ID data, so using your ID for age verification doesn't give them any new ID information. The only new thing that them doing age verification adds is that they might keep a list of verification tokens they have issued.
But the central authority, a third party, will get a heads-up every time someone - whether child or adult - logs into the social media site. That's a privacy violation. Even if the verification system were set up in such a way that the third party wouldn't be able to know which exact website I'm trying to visit, the third party would be able to track how frequently I visit websites that require age verification. With just this law, it would be "you visited social media during X, Y, and Z times." With extensions of this law to other kinds of websites, it would be "you visited social media or porn or violent video games or alcohol sites during X, Y, and Z times", which obfuscates the kind of website I visit but also makes the internet into something I have to whip out an ID for just to use.
> That's fixed by making it so the token that is given to the social media site is not the token that came from site that checked your ID. You give the social media site a transformed token that you transform in such a way that the social media site can recognize that it was made from a legitimate token from the ID checker but does not match anything on the list of tokens that the ID checker has for you.
Is it possible to transform the token such that the social media site would be able to link it to your identity but an attacker who gains access to the social media site's data wouldn't? If so, I'd appreciate an example of a transformation for such a purpose. But it doesn't wipe out my privacy concern, that I - or anyone else - wouldn't be able to log in to a social media site without letting a third party know against my will.
> But the central authority, a third party, will get a heads-up every time someone - whether child or adult - logs into the social media site. That's a privacy violation. Even if the verification system were set up in such a way that the third party wouldn't be able to know which exact website I'm trying to visit, the third party would be able to track how frequently I visit websites that require age verification.
It doesn't have to work like this.
It's technically possible to do verification such that the authority (probably the government which already has a database with your age), doesn't get any communication when verification takes place. They'd have no idea which sites you visit or join, or how often.
And the site which receives the verification token doesn't learn anything about you other than your age is enough. They don't even learn your age or birthday. They couldn't tell the government about you even if subpoenaed.
(But if you tell them on your birthday that you are now old enough, having been unable to the day before, they'll be able to guess of course so it's not perfect in that way.)
Using modern cryptography, you don't send the authority-issued ID to anyone, as that would reveal too much. Instead, on your own device you generate unique, encrypted proofs that say you possess an ID meeting the age requirement. You generate these as often as you like for different sites, and they cannot be correlated among sites. These are called zero-knowledge proofs.
They work for other things than age too. For example, to show you are an approved investor, or have had specific healthcare or chemical safety training, or possess a certain amount of credit without revealing how much, or are citizen with voting rights, or are a shareholder with voting rights, without revealing anything else about who you are.
Do you mean that I can get a permanent age-verification key from the third-party authority, then never have to contact the authority again (unless I want a new key)? If so (and assuming that zero knowledge proofs, which I'm not very familiar with, work), then my privacy concerns are resolved. (Well, I don't want the authority to keep a copy of my verification key, but FOSS code and client-side key generation should be feasible.)
An example of the kind of token transformation I'm thinking of follows.
Assume RSA signatures from the site that looks at your ID having public key (e,m) where e is the exponent and m is the modules, and private key d. The signature s of a blob of data, b, that you give them is b^d mod m.
To verify the signature one computes s^e mod m and checks if that matches b.
Here's the transformation. You generate a random r from 1 to m-1 such that r is relatively prime to m. Compute r' such that r r' = 1 mod m.
Instead of sending b to be signed, send b r^e mod m.
The signature s of b r^e is (b r^e)^d mod m = b^d r mod m.
You take that signature and multiply by r'. That gives you b^d mod m. Note that this is the signature you would have gotten had you sent them b to sign instead of b r^e.
Net result: you've obtained the signature of b, but the signing site never saw b. They just saw b r^e mod m.
That gives them no useful information about b, due to r being a random number that you picked (assuming you used a good random number generator!).
For any possible b, as long as it is relatively prime to m, there is some r that would result in b r^e having the same signature as your b, so the signing site has no way to tell which is really yours.
b is unlikely to not be relatively prime to m. If m is the product of two large primes, as is common, b is relatively prime to it unless one of those primes divides b. We can ensure that b is relatively prime to m by simply limiting b to be smaller than either of the prime factors of m. Since those factors are likely to each be over a thousand bits this is not hard. In practice b would probably be something like a random 128 bits.
> But the central authority, a third-party, will get a heads-up every time someone - whether child or adult - logs into the social media site. That's a privacy violation.
Why would you do age verification on login? It only needs to happen once on account creation.
> Why would you do age verification on login? It only needs to happen once on account creation.
Oops. That slipped my mind. For sites that require log-in, my previous comment is wrong.
I had unconsciously assumed that at least one site would implement the age verification system without requiring users to make accounts to browse the site. In this comment, I will make explicitly make that assumption. For sites without log-in walls but with government-mandated age verification, the concerns in my previous comment would apply. But sites with log-in walls have their own privacy problems independent of age verification, chief being that having to log in means letting the first party site track how often I use the site. A different problem (not necessarily privacy-related, but can be) of log-in walls is that I would be forced to create accounts. If I don't wish to deal with the burden of making accounts, then I won't browse the website. If the website made a log-in wall in response to an age verification mandate from a government, then my First Amendment right to access the speech the website wished to provide will have been chilled.
I think you’d want to also reverify now and then. People only rarely create accounts, which I think would make de-anonymizing someone from simultaneous breaches of site and verifier logs easier.
If you have to verify often enough, and age verification is required on enough sites that are widely used by the general public so that the mere fact that you are using sites that require age verification is not something you might need to hide, I think it would make it much harder to get useful information from log comparisons.
Say you have a user U who wishes to demonstrate to site S that they are at least 16, and we have a site G that already has a copy of U's government ID information.
Here's one way to do it, with an important security measure omitted for now for simplicity.
• S gives U a token.
• U gives G that token and shows G their ID.
• G verifies that U is at least 16, and then signs the token with a key that they only use for "over 16" age verifications. The signed token is given back to U.
• U gives the signed token back to S.
If G saves a list of tokens it signs and who it signed them for, and S saves a list of tokens it issues and what accounts it issued them for, then someone who gets both of those lists could look for tokens that appear on both in order to match up S accounts with real IDs.
To prevent that we have to make an adjustment. G has to sign the token using a blind signature. A blind signature is similar to a normal digital signature, except the the signer does not see the thing they are signing. All they see is an encrypted copy of the thing.
With that change a breach of G just reveals that you had your age verified and gives the encrypted token associated with that verification. These no longer match what is in the records of the sites you proved your age to since they only have the non-encrypted tokens.
Someone with both breaches might be able to match up timestamps, so even though they can't match the tokens from S directly with the encrypted tokens from G they might note that you had your age verified at time T, and so infer that you might be the owner of one of the S accounts that had a token created before T and returned after T.
This would be something people trying to stay anonymous would have to be careful with. Don't go through the full signup as fast as possible--wait a while before getting the token signed, and wait a while before returning the signed token. Then someone who is looking at a particular anonymous S account will have a much larger list of items in the G breach that have a consistent timestamp.
Also note that to G it is just being asked to sign opaque blobs. Occasionally have G sign random blobs. If your G data shows that you are getting your age verified a few times a month, then it is even more likely that if one of those verifies is at about the same time as a particular social media signup it is just a coincidence.
