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.
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.
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
Eg you could prove that 'either your age is a prime number or that you have green eyes and live in New York'.
* 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.
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.
> 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.
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?
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'.
crypto people need to learn crypto.
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.
What did you implement VCs and ZK for?
It was a crypto/blockchain/decentralized ID thing.
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)?
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.
"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)
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...