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

Add interoperable way for holder-asserted claims in a VP #1186

Merged
merged 18 commits into from
Jul 23, 2023
Merged
Changes from all commits
Commits
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
95 changes: 95 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -2030,6 +2030,101 @@ <h4>Presentations Using Derived Credentials</h4>
</figcaption>
</figure>
</section>
<section>
<h4>Presentations Including Holder Claims</h4>
<p>
A <a>holder</a> MAY use the <code>verifiableCredential</code> <a>property</a> in
a <a>verifiable presentation</a> to include <a>verifiable credentials</a> from
any <a>issuer</a>, including themselves. When the <a>issuer</a> of a
<a>verifiable credential</a> is the <a>holder</a>, the <a>claims</a> in that
<a>verifiable credential</a> are considered to be <em>self-asserted</em>.
Such self-asserted claims can be secured by the same mechanism that secures
the <a>verifiable presentation</a> in which they are included or by any
mechanism usable for other <a>verifiable credentials</a>.
</p>
<p>
The <a>subject(s)</a> of these self-asserted <a>claims</a> are not limited, so
brentzundel marked this conversation as resolved.
Show resolved Hide resolved
these <a>claims</a> can include statements about the <a>holder</a>, one of the
other included <a>verifiable credentials</a>, or even the <a>verifiable
presentation</a> in which the self-asserted <a>verifiable credential</a> is
included. In each case, the <code>id</code> <a>property</a>
is used to identify the specific <a>subject</a>, in the object where the
<a>claims</a> about it are made, just as it is done in
<a>verifiable credentials</a> that are not self-asserted.
</p>
<p>
A <a>verifiable presentation</a> that includes a self-asserted
<a>verifiable credential</a> that is only secured using the same mechanism as
the <a>verifiable presentation</a> MUST include a <code>holder</code>
<a>property</a>.
</p>
<p>
All of the normative requirements defined for <a>verifiable credentials</a>
apply to self-asserted <a>verifiable credentials</a>.
</p>
<p>
When a self-asserted <a>verifiable credential</a> is secured using the same
mechanism as the <a>verifiable presentation</a>, the value of the
<code>issuer</code> <a>property</a> of the <a>verifiable credential</a>
MUST be identical to the <code>holder</code> <a>property</a> of the
<a>verifiable presentation</a>.
Comment on lines +2067 to +2070
Copy link
Contributor

@dlongley dlongley Jul 18, 2023

Choose a reason for hiding this comment

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

I noticed that we could have a situation where the VC uses an issuer property that expresses an object with the issuer's identifier in the id property (typically to express other properties about the issuer) -- and a VP uses a holder property that directly expresses the identifier of the holder. To account for this, I think we should indicate that it's the identifiers that must match and just reference those sections for how they could be expressed:

Suggested change
mechanism as the <a>verifiable presentation</a>, the value of the
<code>issuer</code> <a>property</a> of the <a>verifiable credential</a>
MUST be identical to the <code>holder</code> <a>property</a> of the
<a>verifiable presentation</a>.
mechanism as the <a>verifiable presentation</a>, the identifier of the
<a>issuer</a> of the <a>verifiable credential</a> (expressed according
to Section <a href="#issuer"></a>) MUST be identical to the identifier of
the <a>holder</a> of the <a>verifiable presentation</a> (expressed
according to Section <a href="#presentations-0"></a>).

Copy link
Contributor

Choose a reason for hiding this comment

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

@jandrieu ^ this was the intention of citing the normative definitions related to graph objects, in the "holder" validation section PR, can you review here as well?

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like we can perhaps remove that text from validation, if this section repeats it.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think that the language already present is simpler and is sufficient.
The holder is the entity constructing both the VP and the self-asserted VC, so they can make sure those values are identical, whether they choose to use an object with an id or just a URL.

Plus, we already have this line above, which was introduced specifically to avoid pointing back to each normative section of the spec that also applies: "All of the normative requirements defined for verifiable credentials apply to self-asserted verifiable credentials."

I would prefer to not make this change.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not going to block this PR if the change isn't made either.

Copy link
Contributor

@jandrieu jandrieu Jul 19, 2023

Choose a reason for hiding this comment

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

Interesting.

This doesn't say anything about how the holder makes a VC about the current presentation.

I was expecting something like

It is possible for the holder to express statements about a Verifiable Presentation in that presentation itself, e.g., documenting that "the this presentation was submitted by the subject as evidence of their legal right to drive." In this situation, the holder simply creates a Verifiable Credential with claims with a subject id that matches the "id" of the Verifiable Presentation. Those claims are understood to be about the presentation.

Copy link
Contributor

Choose a reason for hiding this comment

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

as an aside, presentations and credentials don't require id, but when one is present, the claims are bound to the id.

Copy link
Contributor

@OR13 OR13 Jul 19, 2023

Choose a reason for hiding this comment

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

IMO this suggestion should be applied, we can clean up when the dust settles.

</p>
<p>
The example below shows a <a>verifiable presentation</a> that embeds a
self-asserted <a>verifiable credential</a> that is secured using the same
mechanism as the <a>verifiable presentation</a>.
</p>

<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded proof, with a self-asserted verifiable credential">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiablePresentation", "ExamplePresentation"],
"holder": "did:example:12345678",
"verifiableCredential": [{
"@context": "https://www.w3.org/ns/credentials/v2",
"type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],
"issuer": "did:example:12345678",
"credentialSubject": {
"favoriteCheese": "Gouda"
},
{ <span class="comment">...</span> }
}],
"proof": [{ <span class="comment">...</span> }]</span>
OR13 marked this conversation as resolved.
Show resolved Hide resolved
}
</pre>
<p>
The example below shows a <a>verifiable presentation</a> that embeds a
self-asserted <a>verifiable credential</a> that holds <a>claims</a> about the
<a>verifiable presentation</a>. It is secured using the same mechanism as the
<a>verifiable presentation</a>.
</p>

<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded proof, with a self-asserted verifiable credential about the verifiable presentation">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiablePresentation", "ExamplePresentation"],
<span class="highlight">"id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b"</span>,
"holder": "did:example:12345678",
"verifiableCredential": [{
"@context": "https://www.w3.org/ns/credentials/v2",
"type": ["VerifiableCredential", "ExampleAssertCredential"],
"issuer": "did:example:12345678",
"credentialSubject": {
<span class="highlight">"id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b"</span>,
"assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
},
{ <span class="comment">...</span> }
}],
"proof": [{ <span class="comment">...</span> }]</span>
}
</pre>
</section>
</section>
</section>

Expand Down