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.

Sign up for GitHub

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

Jump to bottom

update normative statements in ZKP section #818

Merged
merged 13 commits into from
Sep 29, 2021
Merged

update normative statements in ZKP section #818

Changes from 12 commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
f397abb
update normative statements in ZKP section
kdenhartog Sep 10, 2021
3b126be
editorial update
kdenhartog Sep 11, 2021
301d284
editorial update
kdenhartog Sep 11, 2021
741b9d5
editorial update
kdenhartog Sep 11, 2021
a35df85
editorial update
kdenhartog Sep 11, 2021
064e389
editorial update
kdenhartog Sep 11, 2021
4120582
editorial update
kdenhartog Sep 11, 2021
bd99a7b
editorial update
kdenhartog Sep 11, 2021
557649b
address review comments from @brentzundel and @dlongley
kdenhartog Sep 13, 2021
d6bc9e4
update text to align with holder binding considerations
kdenhartog Sep 29, 2021
96a8c06
change non normative text to reduce confusion
kdenhartog Sep 29, 2021
f5b3945
Update index.html
kdenhartog Sep 29, 2021
c750517
Change credential to lowercase.
msporny Sep 29, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 36 additions & 31 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2942,8 +2942,8 @@ <h3>Zero-Knowledge Proofs</h3>
<p>
A zero-knowledge proof is a cryptographic method where an entity can prove to
another entity that they know a certain value without disclosing the actual
value. A real-world example is proving that an accredited university has granted
a degree to you without revealing your identity or any other personally
value. A real-world example is proving that an accredited university has
granted a degree to you without revealing your identity or any other personally
identifiable information contained on the degree.
</p>
<p>
Expand Down Expand Up @@ -2975,45 +2975,50 @@ <h3>Zero-Knowledge Proofs</h3>
</ul>

<p>
This specification describes a data model that supports zero-knowledge proof
mechanisms. The examples below highlight how the data model can be used to
issue, present, and verify zero-knowledge <a>verifiable credentials</a>.
This specification describes a data model that supports selective disclosure
with the use of zero-knowledge proof mechanisms. The examples below highlight
how the data model can be used to issue, present, and verify zero-knowledge
<a>verifiable credentials</a>.
</p>

<p>
To use zero-knowledge <a>verifiable credentials</a> the <a>issuer</a> must
issue a <a>verifiable credential</a> in a manner that enables the <a>holder</a>
to present the information to a <a>verifier</a> in a privacy-enhancing manner.
For a <a>holder</a> to use a zero-knowledge <a>verifiable presentation</a>,
they need an <a>issuer</a> to have issued a <a>verifiable credential</a> in a manner
that enables the <a>holder</a> to derive a proof from the originally issued
<a>verifiable credential</a>, so that the <a>holder</a> can present the
information to a <a>verifier</a> in a privacy-enhancing manner.
This implies that the <a>holder</a> can prove the validity of the
<a>issuer's</a> signature without revealing the values that were signed, or when
only revealing certain selected values. The standard practice is to do so by
proving knowledge of the signature, without revealing the signature itself.
There are two requirements for <a>verifiable credentials</a> when they are to be
used in zero-knowledge proof systems. The <a>verifiable credential</a> MUST
contain a:
used in zero-knowledge proof systems.
</p>

<ul>
<li>
<a>Credential</a> definition, using the <code>credentialSchema</code>
<a>property</a>, that can be used by all parties to perform various
cryptographic operations in zero-knowledge.
kdenhartog marked this conversation as resolved.
Show resolved Hide resolved
The <a>verifiable credential</a> MUST contain a Proof, using the
<code>proof</code> <a>property</a>, so that the <a>holder</a> can derive a
<a>verifiable presentation</a> that reveals only the information than the
<a>holder</a> intends to reveal.
</li>
<li>
Proof, using the <code>proof</code> <a>property</a>, that can be used to derive
<a>verifiable presentations</a> that present information contained in the
original <a>verifiable credential</a> in zero-knowledge. The zero-knowledge
<a>verifiable presentation</a> must not reveal any information not intended to
be revealed by the <a>holder</a>.
If a <a>Credential</a> definition is being used, the <a>Credential</a>
msporny marked this conversation as resolved.
Show resolved Hide resolved
definition MUST be defined in the <code>credentialSchema</code> <a>property</a>,
so that it can be used by all parties to perform various cryptographic
operations in zero-knowledge.
</li>
</ul>

<p>
The following example shows one method of using <a>verifiable credentials</a> in
zero-knowledge. It makes use of a CL Signature, which allows the presentation of
the <a>verifiable credential</a> in a way that supports the privacy of the
zero-knowledge. It makes use of a Camenisch-Lysyanskaya Signature
[[?CL-SIGNATURES]], which allows the presentation of the <a>verifiable
credential</a> in a way that supports the privacy of the
<a>holder</a> and <a>subject</a> through the use of selective disclosure of the
<a>verifiable credential</a> values.
<a>verifiable credential</a> values. Some other cryptographic systems which rely
upon zero-knowledge proofs to selectively disclose attributes can be found in the
[[?LDP-REGISTRY]] as well.
</p>

<pre class="example nohighlight" title="A verifiable credential that supports CL Signatures">
Expand Down Expand Up @@ -3046,7 +3051,6 @@ <h3>Zero-Knowledge Proofs</h3>
}</span>
}
</pre>

<p>
The example above provides the <a>verifiable credential</a> definition by using
the <code>credentialSchema</code> <a>property</a> and a specific proof that is
Expand All @@ -3057,26 +3061,27 @@ <h3>Zero-Knowledge Proofs</h3>
The next example utilizes the <a>verifiable credential</a> above to generate a
new derived <a>verifiable credential</a> with a privacy-preserving proof. The
derived <a>verifiable credential</a> is then placed in a
<a>verifiable presentation</a>, which further proves that the entire assertion
is valid. There are three requirements of most <a>verifiable presentations</a>
when they are to be used in zero-knowledge systems:
<a>verifiable presentation</a>, so that the <a>verifiable credential</a>
discloses only the <a>claims</a> and additional credential metadata that the
<a>holder</a> intended. To do this, all of the following requirements are
expected to be met:
</p>

<ul>
<li>
Each derived <a>verifiable credential</a> within a
<a>verifiable presentation</a> MUST have a <code>credentialSchema</code>
<a>property</a>. This allows the derived <a>verifiable credential</a> to
reference the credential definition used to generate the derived proof.
Each derived <a>verifiable credential</a> within a <a>verifiable
presentation</a> MUST contain all information necessary to verify the
<a>verifiable credential</a>, either by including it directly within the
credential, or by referencing the necessary information.
</li>
<li>
A <a>verifiable presentation</a> MUST NOT leak information that would enable
the <a>verifier</a> to correlate the <a>holder</a> across multiple
<a>verifiable presentations</a>.
</li>
<li>
The <a>verifiable presentation</a> MUST contain a <code>proof</code>
<a>property</a> to enable the <a>verifier</a> to ascertain that all derived
The <a>verifiable presentation</a> SHOULD contain a <code>proof</code>
<a>property</a> to enable the <a>verifier</a> to check that all derived
<a>verifiable credentials</a> in the <a>verifiable presentation</a> were issued
to the same <a>holder</a> without leaking personally identifiable information
Comment on lines 3085 to 3086
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<a>verifiable credentials</a> in the <a>verifiable presentation</a> were issued
to the same <a>holder</a> without leaking personally identifiable information
<a>verifiable credentials</a> in the <a>verifiable presentation</a> were issued
to the same <a>holder</a> without leaking personally identifiable information

Somehow I missed this in previous reviews.

  • Why do the derived <a>verifiable credentials</a> have to have been issued to the same <a>holder</a>?
  • Are derived <a>verifiable credentials</a> issued at all?
  • Why are we checking whether the current holder was the original holder of any <a>verifiable credentials</a>?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indy anoncreds zkp-credentials, which were used as the exemplar for much of the material in this section, require that issued credentials be bound to a holder. One reason for this is that anoncreds aren't bound to a subject, but are rather issued to the subject, so binding to the holder is a way to accomplish connection of the credential to the subject. Another is to give verifiers more confidence that credentials are linked even when the disclosed claims are kept to a minimum. Binding to a holder also makes sharing credentials more detectable and unwieldy, which is seen as valuable in the anoncreds ecosystem.

That said, there are more zkp-credential schemes now than there were when the section was written, and not all of them require holder binding, even though many still consider that best practice. This is why the MUST is being changed to a SHOULD.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggestion appears to be the same as the current text in there. I presume this review comment was more about raising the questions which I think @brentzundel addressed. Please let me know if there's any additional changes that I missed to resolve this comment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this review comment was more about raising the questions

Correct. However, I do not think that the answers provided by @brentzundel remove my concerns with this section.

I am mostly concerned about the "bound"/"binding" terminology in use here, which I think is a significantly stronger relationship than is actually present between these VCs and their Subjects or Holders. I think it would be better to say that xyz property/ies in the Credentials under specific discussion are (or SHOULD be or MUST be) set to strings or URIs which identify the Holder who is expected to Present the VC to any Verifiers downstream. Then, the Verifier is expected to check that either some other qrs property/ies were (or SHOULD have been or MUST have been) set to strings or URIs which identify the Subject, OR the Subject is always the same as the Holder identified by the values of xyz property/ies, ... Or something along those lines.

I think that "anoncreds aren't bound to a subject, but are rather issued to the subject, so binding to the holder is a way to accomplish connection of the credential to the subject" translates roughly to "anoncreds are Issued to their Subject, which is defined as a sapient being, and which is not identified as the Subject within the VC. Identifying the Holder is an indirect way to accomplish association of the VC with its Subject," which Subject is not really obscured by this method, since the identified Holder is always the Subject and anyone who can access the value of the field identifying the Holder is thereby able to access to identifier of the Subject. Leading to another concern with this section, since it seems that the Subject anonymity desired to be delivered through ZKP, at least in part by identifying one Holder who must be the Subject, instead of identifying the Subject, isn't actually delivered.

I'm sure I'm missing something exceedingly clever, and I hope someone can explain it in terms I can understand and that we can swiftly adopt (and/or edit slighly to adopt) for this section.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am mostly concerned about the "bound"/"binding" terminology in use here, which I think is a significantly stronger relationship than is actually present between these VCs and their Subjects or Holders. I think it would be better to say that xyz property/ies in the Credentials under specific discussion are (or SHOULD be or MUST be) set to strings or URIs which identify the Holder who is expected to Present the VC to any Verifiers downstream.

+1. And if there are cases where there aren't actually any properties in the VC itself with this information because some mechanisms include it via secrets and/or proof data, then that can be stated as an option as well. I think it's important that we indicate that we're talking about setting expectations -- and not assert a level of control that isn't possible. It's also fine to say that there are mechanisms that attempt to impede adversaries that try to subvert these expectations, but such statements should include a friendly warning that they all have limitations that need to be well understood by implementers (and readers should consult external documentation for that).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This thread continues in #821.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to action this within this PR - if so can you propose some suggested changes based on the discussions so far.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kdenhartog -- There are no changes to make here in this PR based on this comment.

that the <a>holder</a> did not intend to share.
Expand Down