Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another example (or a clarification) needed for example given for Predicate Proofs #59

Open
david-bakker opened this issue Mar 2, 2021 · 2 comments

Comments

@david-bakker
Copy link

david-bakker commented Mar 2, 2021

In the section on Predicate Proofs in chapter 11, this document states:
"Using zero-knowledge methods, predicate proofs can be generated by the holder at the time of presentation without issuer involvement. For example, a verifiable credential with the claim birthdate can be used in a verifiable presentation to prove age-over-18. The same credential could then be used in another presentation to prove age-over-25, all without revealing the holder's birthdate."

I understand that a zero knowledge proving system allows a holder to demonstrate that she knows a claim (which is authenticated by an issuer) and that she used that claim inside a defined and known computation to derive some other value. She will moreover be able to prove to a verifier that the new value was indeed correctly derived from the claim, without revealing the claim itself.

However, I think that this does not justify the given example of proving age-over-25 based on proven knowledge of birthdate. The problem I see that for this particular calculation, the holder needs to use the current date (or at least the date on which the age-over-25 claim is to have value TRUE). That current date cannot be included in the claim that she received from the issuer, because we assume no involvement of the issuer. Therefore, the current date must originate from the holder itself. But that means that in order to accept the age-over-25 claim, the verifier must trust the holder. And this obviously defeats the purpose of the claim.

Perhaps my thinking above is wrong. In that case, I think that a clarification would be helpful also for other readers. Please note that the same example is used at other places as well, for example section 12.3. Figure 11 in the VC Data Model suggests the same example.

If I am right, however, we need to find another example to demonstrate the power of ZKPs for real-life applications of VCs.

@brentzundel
Copy link
Member

In all ZKP predicate solutions that I am aware of, the Holder receives the test value (in this example, the current date) from the Verifier, or from a source the Verifier trusts.
That said, age verification predicate examples are not the best examples and I wouldn't be opposed to seeing a new one.

@david-bakker
Copy link
Author

david-bakker commented Mar 8, 2021

Hi Brent, thanks for your response and especially for pointing out that the prove system does not need to be non-interactive and so the verifier can sent the current date to the holder.

To be honest, I do not understand ZKPs or the cryptography behind them well enough to be able to say anything useful about whether or not this can really be done in practice. All I can say is that the Implementation Guide repeatedly makes this claim (and the Data Model seems to do as well), and that I would love to understand better how this works. I tried to find this out for C-L signatures, since they are the only concrete ZKP that is mentioned in these documents, but I got stuck. In the explanations I found, I do not see any challenge from the verifier being included in the prove protocol. Moreover, they do not seem to give the prover the possibility to do calculations using the attributes signed by the issuer.

I also looked into zkSNARKs, which do allow a prover to prove that they did some calculation on the secret inputs. But zkSNARKs are definitely non-interactive, so it seems they do not fit the bill either.

An Implementation Guide should give readers practical hints on how to implement a specification. I think it would be very useful to include some references that explainhow a holder may actually prove age-over-25 from birthday, and how the current date obtained from the verifier is included in that calculation. Just claiming that it is possible is not good enough, in my opinion.

As I said, unfortunately I cannot contribute anything to this myself. I hope someone else is able and willing to do so!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants