[nailer]

> We can take a digital identity card and prove that we are over 18 years old > Without revealing anything else, like your full name or address

If you are in this articles audience you would simply state the producer of the ID card signs a statement that the person is over 18. No ZKP needed.

The article like many others would be improved with a better example.

[tzs]

I don't think a simple signature is sufficient if you want to maintain privacy with both the party you are trying to convince that you are over 18 and the party that signs the statement saying you are over 18.

If the signer keeps a copy of the signature and who they made it for, someone who gets a hold of that and the records of party you used the signature at they can find out who you are.

There are ZKP based protocols that allow for age verification where even if the party that attests to you age keeps records they do not find out where you are using that attestation, and the party you use the attesting with only finds out that you are above their age threshold and what attesting party you used.

I think that this can be done without ZKP if instead of simple signatures we use blind signatures.

[nailer]

The party that attests to your age would still not know where you were using that attestation using regular digital signatures.

And yes, as previously mentioned the party you are testing to does not know your birthdate or any other information.

There is zero need for zkp with either of these

[JanisErdmanis]

I am also puzzled by this example of utility. It would be easy for the identity provider to separately sign all properties, assign each a unique identifier, and then return them to the users to use the signed identity properties as needed.

[eru]

Yes, though with ZKP you could prove arbitrary logic on the properties, even those that the provider didn't think of nor wants to support.

Eg you could prove that 'either your age is a prime number or that you have green eyes and live in New York'.

[A1kmm]

So the problem could be expressed as:

* The actors are: Individuals I_1, ..., I_n, businesses B_1, ..., B_m, and a central authority A.

* An individual I_j wants to prove to business B_k that A attests that DateOfBirth(I_j) >= 20060902, and that I_j is in possession of a private key, where A attests that it has verified the linkage of the corresponding public key to I_j.

* I_j doesn't want to provide any information about I_j's identity except for the DateOfBirth(I_j) >= 20060902 to B_k. That means, for example, I_j doesn't want to reveal to B_k their ordinal j, nor a single public key that is used everywhere. This means, for example, B_k shouldn't be able to collude with B_{k+1} to combine facts separately provided to the two businesses and build a profile of I_j.

* I_j also doesn't want A to be able to collect information about the fact they provided information to B_k specifically.

With a ZKP, it is possible for a solution like:

* I_j generates a keypair P_1 (private) / p_1 (public) and proves their identity out-of-band to A. A gives them a certificate C_1 typing p_1 to their ordinal j and their date of birth.

* I_j generates a new keypair P_2/p_2 just for dealing with B_k.

* I_j generates a signed certificate C_2 using P_1, tying p_2 to their ordinal j.

* I_j generates a ZKP that there exists a (private input) certificate C_1 signed by A's public key, and that certificate meets the constraint DateOfBirth(I_j) >= 20060902, and there exists a (private input) public key p_1 which is referenced in C_1, and there exists a (private input) certificate C_2 signed by p_1, and that certificate references (public input) public key p_2, and sends the ZKP to B_k.

Now instead you could imagine a solution where A generates certificates for I_j, but that has some downsides:

* The properties to be signed might vary over time. The date of birth cutoff certainly would, and different businesses might want different properties.

* Just one certificate per property isn't enough, because the certificate identifies which public key it relates to. That allows B_k and B_{k+1} to work out they have the same customer I_j. With the ZKP solution, the customer gives a different public key to each. You could work around this by having A provide lots of certificates upfront (inefficient), or by generating certificates on demand (but the A is needed to be involved online in the transaction, and it risks leaking information to A).

So the ZKP solution is, in many ways, simpler in that it removes a lot of constraints while implementing the desired properties, but there are other workarounds if you don't have it.

[TimJRobinson]

A more complex way they are currently used is for proving arbitrary computation.

One of the most obvious flaws of blockchains is that every node needs to re-run every transaction to know that the block is valid, leading to the same computation being run thousands of times.

Instead of having to do this there are new Layer2 chains like Polygon zkEVM or zkSync that post a compressed blob of transaction data and a ZK proof that all transactions in that data are valid according to the rules of the EVM. This makes the chain 1000x more efficient as the computation only needs to be run once and verified 999 times.

The proving is still slow and expensive which is why this isn't fully rolled out, but it's getting faster very quickly with both software improvements and custom ASICs for proving.

[eru]

> If you are in this articles audience you would simply state the producer of the ID card signs a statement that the person is over 18. No ZKP needed.

> The article like many others would be improved with a better example.

It's easy to make this example better:

Assume there are 50 different providers of ID cards, and Alice wants to convince Bob that she's over 18 years old.

Bob trusts all 50 issuers, but Alice doesn't want to reveal who her issuer is.

So here Alice could indeed get the supplier of her ID card to sign such a statement (and perhaps already have one prepared). For ZKP, you can also assume that the ID card issuers are not co-operating (nor do they care about each other), and that different Bobs might trust different sets of providers, and that the sets of trusted providers might change over time.

[BHSPitMonkey]

> Bob trusts all 50 issuers, but Alice doesn't want to reveal who her issuer is.

So, just a form of certificate chaining? With the same old challenges that come up if Bob learns that one of the issuers was compromised for some period of time?

[eru]

Sorry, what is certificate chaining in this context?

ZKP allows you to run arbitrary logic, without the id providers having to anticipate what you are trying to do nor having to cooperate. Eg you could prove that 'either your age is a prime number or that you have green eyes and live in New York'.

[nailer]

> Sorry, what is certificate chaining in this context?

crypto people need to learn crypto.

[eru]

Let me be more blunt: I don't think certificate chaining is a useful concept in this context, but I wanted to be more polite about my objection and give you a chance to explain your idea. Better?

[gchaincl]

I think the goal of this is that you can prove, so that your counter party does not need to rely on trust

[rvrs]

there are standards for "verifiable credentials" and "verifiable presentations" so that digital IDs can be issued and displayed (using a model analogous to web pki/SSL certs), done in a decentralized and privacy-preserving way without ZKPs

[nl]

Actually this is only partially true (have implemented verifiable credientials and ZK on top).

VCs will allow you to verifiably specify your date of birth or maybe your passport number.

What ZK does is allows a third party to ask questions like "is the date of birth of this person prior to 2-Sep-2006" (ie, are they over 18) or "is this person a passport holder for country X" and the ZKP system can say yes or no without disclosing the actual birthdate or the passport number.

It's is a real improvement in privacy, although I'm unconvinced it is worth the incredible inconvenience of implementing it.

[LegionMammal978]

> without disclosing the actual birthdate

What prevents the birthdate from being gleaned through a simple binary search? Or, if it's specifically an "over 18 today?" query based on some decentralized timestamp source, what prevents the query from just being repeated every day until the result changes (assuming it returns "under 18" at first)?

[Jerrrrrrry]

Just because someone asks, doesn't mean one must answer.

"Be liberal in what you receive, and strict in what you send."

The protocol would have to specify an authorized inquiry field or use validity by time, using a global consensus (current bitcoin block + challenges that take bitcoin_blocks block production rate on average to solve)

[rvrs]

The holder of the credential would have to present it log(N) times. If someone asks to scan your id a bunch of times, wouldn't you find it suspicious?

[LegionMammal978]

Different 'someone's could conceivably collude to whittle down the result of the search, fingerprinting users via separate means to align the results. Or, less conspiratorially, one could present an apparently-poorly-designed interface where the credential is only valid for the current login session, then wait for a few cycles of the user clearing their browser cookies.

Perhaps a very explicit prompt "This service wants to know if you're > X years old!" might give up the trick, but then users would have to be trained not to click through it within milliseconds, which is never the most viable solution.

[rvrs]

Neat, thanks! IIUC some credential standards like ISO 18013-5 (mDL) hack around this by allowing you to expose `is_over_X` claims for age gating

What did you implement VCs and ZK for?

[nl]

> What did you implement VCs and ZK for?

It was a crypto/blockchain/decentralized ID thing.

[piotr93]

A signature is a zkp. So your example is also a good example :)

[somezero]

A signature is a PoK, but not ZK.

[piotr93]

I was not clear enough, thanks. Whether it is a pok or zk depends on the chosen signature scheme. In any case, zk signature schemes exist and are implied by the existence of one way functions and publicly verifiable nizk

[somezero]

> zk signature schemes exist and are implied by the existence of one way functions and publicly verifiable nizk.

Almost. The result is from CRYPTO89 paper of Bellare and Goldwasser. They derive a signature scheme from a nizk. It is not known whether you can get a nizk from a signature scheme. Moreover, no signature scheme can be a ZK: https://crypto.stackexchange.com/questions/35177/is-using-di...