With many jurisdictions introducing age verification laws for various things on the internet, a lot of questions have come up about implementation and privacy. I haven’t seen anyone come up with a real working example of how to implement it technically/cryptographically that don’t have any major flaws.

Setting aside the ethics of age verification and whether or not it’s a good idea - is it technically possible to accurately verify someone’s age while respecting their privacy and if so how?

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
  • Not let a government or age verification authority know whenever a user is accessing 18+ content
  • Make it difficult or impossible for a child to fake a proof of adulthood, eg. By downloading an already verified anonymous signing key shared by an adult, etc.
  • Be simple enough to implement that non-technical people can do it without difficulty and without purchasing bespoke hardware
  • Ideally not requiring any long term storage of personal information by a government or verification authority that could be compromised in a data breach

I think the first two points are fairly simple (lots of possible implementations with zero-knowledge proofs and anonymous signing keys, credentials with partial disclosure, authenticating with a trusted age verification system, etc. etc.)

The rest of the points are the difficult ones. Some children will circumvent any system (eg. By getting an adult to log in for them) but a working system should deter most children and require more than a quick download or a web search for instructions on how to circumvent.

The last point might already be a lost cause depending on your government, so unfortunately it’s probably not as important.

  • Zagorath@aussie.zoneEnglish
    3·
    12 hours ago

    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.