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

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

Merged
merged 18 commits into from
Jul 23, 2023
Merged

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

Changes from 17 commits
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
7490cfb
add section on holder-derived creds in VP
brentzundel Jul 5, 2023
e85b745
Apply suggestions from code review
brentzundel Jul 10, 2023
93696db
Update index.html
brentzundel Jul 10, 2023
5bf51b2
soften requirement for 'type', clarify two methods for VC.
brentzundel Jul 10, 2023
37c32cb
Apply suggestions from code review
brentzundel Jul 10, 2023
47a67ef
Update index.html
brentzundel Jul 10, 2023
14fb906
add paragraph clarifying subjects of self-asserted VCs
brentzundel Jul 12, 2023
9446c62
Apply suggestions from code review
brentzundel Jul 14, 2023
bef11ba
re-phrase normative considerations, add example
brentzundel Jul 14, 2023
56965c2
Merge branch 'issue-860' of github.com:brentzundel/vc-data-model into…
brentzundel Jul 14, 2023
8eca073
Update title for holder-asserted example.
msporny Jul 14, 2023
b4e16a6
remove controversial recommended 'type'
brentzundel Jul 17, 2023
6d943aa
Update index.html
brentzundel Jul 17, 2023
8590bc1
change example title
brentzundel Jul 17, 2023
31dc79c
Merge branch 'issue-860' of github.com:brentzundel/vc-data-model into…
brentzundel Jul 17, 2023
3c308a4
Apply suggestions from code review
brentzundel Jul 17, 2023
9dec2f3
Apply suggestions from code review
brentzundel Jul 17, 2023
9559c36
modify example 2 with Joe's language
brentzundel Jul 19, 2023
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
View file
Open in desktop
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 •
edited
Loading

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 •
edited
Loading

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 •
edited
Loading

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", "ExampleTimeLimitCredential"],
"issuer": "did:example:12345678",
"credentialSubject": {
<span class="highlight">"id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b"</span>,
"validUntil": "2024-01-01T19:23:24Z"
Copy link
Member

@msporny msporny Jul 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
"validUntil": "2024-01-01T19:23:24Z"
"validUntil": "2024-01-01T19:23:24Z"

Huh... this is valid, and proposes the question: Why not just put validUntil on the presentation itself? We might want to have an example of someone putting a self-asserted claim on the VP itself... possibly in another PR, we don't want to complicate this one further.

IOW, do we want to enable validFrom and validUntil onto the Presentation too? I think we do want to enable that. At present, it's only allowed on a VerifiableCredential. Historically, this was because presentations were expected to always be short lived... but the short-lived-ness being determined by the verifier and the created/iat date on the proof, not explicitly stated by the holder.

This comment is non-blocking.

Copy link
Member Author

Choose a reason for hiding this comment

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

@msporny I think you're probably right, but I don't want that conversation to derail this PR. I think a better example is probably be what's needed here.

This example came out of my attempt to address @jandrieu 's desire for a normative way for a holder to make claims about the VP. As I constructed the self-asserted VC, I had a hard time coming up with a claim the holder would want to make about the VP.
This is just to say that there is probably a better example of the sort of claims a holder would want to make about the VP, but I couldn't think one up. Looking to @jandrieu for suggestions.

Copy link
Member

@msporny msporny Jul 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Agreed, we don't want to derail this PR with trying to find the perfect example. I defer to @jandrieu to suggest a use case. I'll try to think of a use case (with markup) as well (for a future PR).

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've updated the example based on Joe's comment here: https://github.com/w3c/vc-data-model/pull/1186/files#r1268305835

},
{ <span class="comment">...</span> }
}],
"proof": [{ <span class="comment">...</span> }]</span>
}
</pre>
</section>
</section>
</section>

Expand Down