Re: lack of common definition for "ZKP" in a VC context

ZKP-based credentials always disclose the identity of the issuer; as Luca
points out, a verifier will always want to know who is making the
assertions.

To be specific, ZKP-based credentials don't prove a proposition as simple
as "Alice is a college graduate"; rather they prove something like "Harvard
University says Alice is a college graduate".

This is not at odds with the principles of ZKPs. ZKPs say you must prove
exactly what is necessary, and nothing extra. If the identity of the issuer
is necessary (which I imagine to be the case ~100% of the time), then that
is part of what they prove.

On Mon, Sep 9, 2019 at 1:31 AM Luca Boldrin <luca.boldrin@infocert.it>
wrote:

> Thank you Dani­­el for this helpful explanation.
>
>
>
> From a practical perspective, there is an issue that bothers me on the
> applicability of ZKPs:
>
>
>
> In most situations I can think of I, as a verifier, will need to know *who
> is vouching* for attributes – i.e., the signature of the issuer or
> something with an equivalent informational value: I need to know that
> “Alice is graduate according to FaberUniversity”, while the proposition
> “Alice is graduate” brings me little or no value since I can establish the
> *correctness* but not the *trustworthiness* of the proposition. ­­
>
> Note that, in this view, “trustworthiness” is strictly linked to
> “liability”. If the information “Alilce is graduate according to
> FaberUniversity” proves eventually to be false, and this fact causes me a
> damage, I can sue FaberUniversity, since I can provably argument that
> FaberUniversity lied.
>
>
>
> If everything I have is “Alice is graduate”, and this information proves
> to be false, who will I sue?
>
> At least, I would need to know that “Alice is graduate according to a
> known source”. But, in this case, there is still some additional
> information associated to the proposition, and there should be a mechanism
> in place to disclose the real source when necessary.
>
>
>
> As an endline, it seems to me that liability-induced-trustworthiness
> requires additional  knowledge, which would be in contrast with ZKP
> principle.
>
>
>
> Any thoughts highly appreciated.
>
> Best,
>
>
>
> --luca
>
>
>
>
>
> *Da:* Daniel Hardman <daniel.hardman@evernym.com>
> *Inviato:* mercoledì 4 settembre 2019 22:13
> *A:* Credentials Community Group <public-credentials@w3.org>
> *Oggetto:* lack of common definition for "ZKP" in a VC context
>
>
>
> I've had several interactions recently, including one just today at RWOT,
> that lead me to believe our community has divergent definitions of "ZKP" --
> or at least we are applying "ZKP" in a credential context in fairly
> different ways.
>
>
>
> I won't argue the virtue or lack of virtue of ZKPs with credentials, and
> I'm also not trying to convince other ZKP proponents to adopt my
> definition, but I do want to at least formally share how Hyperledger/Sovrin
> uses that term, so we are not mischaracterized. If there are other ZKP
> voices in this group that want to chime in with their own definitions, that
> would be useful.
>
>
>
> In Hyperledger/Sovrin parlance, a ZKP is not a synonym for a presentation
> that involves predicates; nor is it a synonym for a presentation that uses
> CL signatures. Its defining characteristic--the "zeroness"--is how much
> extra knowledge is leaked. If you leak zero knowledge beyond what the proof
> request demands, then you have achieved zeroness. If you leak any knowledge
> other than what the proof request demands, you have not. This is in the
> spirit of the inventors of ZKPs, whose seminal paper says:
>
>
>
> Zero-knowledge proofs are defined as those proofs that convey no
> additional knowledge other than the correctness of the proposition in
> question. (S. GOLDWASSER, S. MICALI, AND C. RACKOFF, The knowledge
> complexity of interactive proof-systems, SIAM J. Comput., 18 (1989), pp.
> 186-208)
>
>
>
> Note that the wikipedia article on this topic, as well as many online
> tutorials, vary in whether they use this definition, or a narrower and more
> recently prominent one that suits their own contexts. Thus, not everything
> that you can read about ZKPs on StackOverflow or various crypto blogs is
> actually describing the same ZKP concept as Hyperledger/Sovrin. I'm not
> saying anybody is right or wrong--just pointing out differences.
>
>
>
> While it is true that Hyperledger/Sovrin implementations of ZKP
> credentials support predicates (aka "zero knowledge proof *of knowledge*"),
> I expect most ZKP-based presentations to disclose things as well ("zero
> knowledge proof of *<a value>*"). For example, if you intend to ask Alice
> to disclose her first name and city of residence, you can do this in a ZKP
> way. You don't do this via predicates; you actually say the
> machine-readable equivalent of "please prove the actual values of firstName
> and cityOfResidence".
>
>
>
> You might say, "Well, what's the difference between ZKPs and selective
> disclosure in that case? Why would you call that a ZKP?" And my answer
> would be: *the ZKP that discloses 2 attributes differs from the non-ZKP
> that discloses the same 2 attributes in whether a signature is disclosed.*
> A ZKP discloses 2 attributes and 0 signatures (even though the credential
> behind it has a signature over each individual attribute); a non-ZKP
> discloses 2 attributes and 1 signature (or 2 if it supports per-attribute
> signatures).
>
>
>
> I'm curious to know if I'm being pedantic and redundant here, or if I
> raised people's eyebrows.
>
>
>
> --Daniel
>
>
>