[jorvi]

Already happening in the EU. Give your phone number, credit card number, or government ID number if you want to watch age-gated YouTube.

The best solution would be a government or banking API that emits a one-time token. No logging, and it self-destructs upon verification.

But aside from the user, no other party has detriment from the current situation.

[s1artibartfast]

That's a really interesting idea. I was just wondering how any of this could be prevented in a way that preserves user choice.

[g_p]

While there's some complexity in the details of how you'd implement the protocol and avoid replay "attacks", there are potentially ways to use Chaumian blind signatures so that an age verifying authority can (blindly) sign a token you present after verifying your age (through some means that likely won't be anonymous), in an unlinkable way

As an overly simple thought experiment, you could generate a random ed25519 ephemeral public key, hash it, then send it (blinded, and thus unreadable) to an age verification service (with some long term age verification credential or similar).

The age verification provider does a blind signature on your (blinded) public key hash, and sends it back to you. You un-blind that signature (meaning that provider can't identify which identifiable request led to it, but now it bears the hash of your public key), and you can now authenticate to a service by signing a challenge with your ephemeral ed25519 private key.

The service only knows your ephemeral public key, and that it has been "vouched" (signed) by the age verification provider.

The age verification provider knows "you" asked for a token , but doesn't know what public key you used.

Clearly there are challenges with replaying (authorised user could share the private key every day with a group of others), and revocation of a credential whose private key gets shared among a group is hard (beyond providers blocking a public key).

The risk is that this becomes a race towards "DRM" and platform attestation/authentication to try and prevent private keys being exported.

[mamonster]

Maybe someone could chime in (cryptography is not my strong mathematical field), but isn't the entire point of ZK proofs(which are the hot buzzword in crypto) that you should be able to be verify certain information (i.e that you are of a certain age) without leaking any other information(which is similar to what you are proposing)?

Surely this is a better application of that rather than proposing another L2 to scale Ethereum?

[g_p]

Good question.

By my understanding , in principle yes you could use ZK proofs - you can imagine it as a way to prove a certain assertion (age >= 18) in a way that isn't directly linked to other data. You sometimes see this in conceptual ID card specifications - using keys on a smart card to give a signed attestation about a single attribute without sharing other ones.

Ultimately though, when you need to actually implement it, you'll end up needing the same core concept as the thought experiment above - you'll need one or more "trusted central authorities" whose word is trusted on a given asserted attribute (age, etc).

They'll need a way to prove that they vouched for a user (as there's no digital way to validate their age as that's an unverifiable claim). You'll then need a way for the "bearer" of a ZK proof to tie themselves to that trusted central authority's attestation, and you'll need a way to prevent the information needed to generate that ZK proof being shared with others for replay.

A ZK proof will still need that external trusted authority for an attribute like age, because age isn't something you can root some kind of cryptographic trust from.

I'm not an expert in the ZK crypto either, but it doesn't deliver a magical ability to prove a (biological analog world claim) without chaining back to a trusted verifier of said claim, and effectively delivering that sort of "thought experiment" protocol.

Sometimes though, the complex solutions tend towards the simple - you could issue people "age verification" smart cards (if you have enough confidence in CC EAL6 or similar cards, and their side channel resistance) which are "group keyed" with common attestation signing keys for every million (or another suitable anonymity threshold) users, and share the public keys used (to allow verification you haven't been given a special unique public key), and then allow signed card-issued anonymous attestations. That would work for as long as you can keep the smartcard-backed key secure against side channel/ key extraction attacks.

The user adoption challenge in all this is getting users onboard and demonstrating it's a private solution rather than an excuse to oversee their online activities more, but I do believe you could do this in a manner that's going to make it easier to just identify them from IP address and adtech trackers or similar external means.

[lotsofpulp]

There are so many inefficiencies and security risks that individuals have to put up with simply because the US federal government (or any other federal government) have not provided an identity verification API.

From banking to buying concert tickets, a way to prove one is human could be invaluable to ridding the system of the myriad proxies we currently use that inevitably result in discrimination.

The crazy thing is it would be dead simple, the hardest part, having physical infrastructure all over the country is already done. The US Postal Service already verifies people's identity for US passports.

Combine this with a constitutional inalienable right to receiving and transferring money to an electronic money account operated by the federal government, and we could get rid of so many inefficiencies.