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

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

Merged
merged 18 commits into from
Jul 23, 2023
+95 −0
Merged

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

Changes from 1 commit
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
59 changes: 59 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,65 @@ <h4>Presentations Using Derived Credentials</h4>
</figcaption>
</figure>
</section>
<section>
<h4>Presentations Including Holder Claims</h4>
<p>
In addition to <a>claims</a> from an <a>issuer</a> in the form of
<a>verifiable credentials</a>, a <a>verifiable presentation</a> MAY include
<a>claims</a> directly from the <a>holder</a>. These <a>holder</a> <a>claims</a>
are considered to be self-asserted. If present, these self-asserted
<a>claims</a> MUST be formatted as a <a>verifiable credential</a> and included
in the value of the <code>verifiableCredential</code> <a>property</a> of the
<a>verifiable presentation</a>. These self-asserted claims are considered to be
secured by the same mechanism that secures the <a>verifiable presentation</a> in
which they are included.
brentzundel marked this conversation as resolved.
Show resolved Hide resolved
</p>
<p>
A self-asserted <a>verifiable credential</a> that has been included in the value
of the <code>verifiableCredential</code> <a>property</a> of a
<a>verifiable presentation</a> MUST include the following properties:
</p>

<dl>
<dt><var>type</var></dt>
<dd>
The <code>type</code> <a>property</a> is required. The value MUST be
<code>VerifiableCredential</code> and <code>SelfAssertedCredential</code>.For
example,<br>
<code>"type": ["VerifiableCredential", "SelfAssertedCredential"]</code>
Copy link
Member

@msporny msporny Jul 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

I think I agree with @andresuribe87 here -- it /could/ be SelfAssertedCredential, or it could be just about any other type of VC. IOW, the thing that makes a VC "self-asserted" is that it's issued by the holder.

So, there is probably some sort of interplay here with VP.holder and the issuer for the self-asserted VC.

EDIT: I now see that there is a documented interplay below; good.

brentzundel marked this conversation as resolved.
Show resolved Hide resolved
</dd>
<dt><var>issuer</var></dt>
<dd>
The <code>issuer</code> <a>property</a> is required. The value MUST be identical
to the <code>holder</code> <a>property</a> of the <a>verifiable presentation</a>.
Copy link
Member

Choose a reason for hiding this comment

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

Yes to this.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to this as well.

</dd>
</dl>
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
A self-asserted <a>verifiable credential</a> that has been included in the value
of the <code>verifiableCredential</code> <a>property</a> of a
<a>verifiable presentation</a> MUST include the following properties:
</p>
<dl>
<dt><var>type</var></dt>
<dd>
The <code>type</code> <a>property</a> is required. The value MUST be
<code>VerifiableCredential</code> and <code>SelfAssertedCredential</code>.For
example,<br>
<code>"type": ["VerifiableCredential", "SelfAssertedCredential"]</code>
</dd>
<dt><var>issuer</var></dt>
<dd>
The <code>issuer</code> <a>property</a> is required. The value MUST be identical
to the <code>holder</code> <a>property</a> of the <a>verifiable presentation</a>.
</dd>
</dl>
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>. The value of the <code>holder</code> <a>property</a>
MUST be identical to the value of the <code>issuer</code> <a>property</a>
for every such self-asserted <a>verifiable credential</a>.
</p>

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 did not accept this suggestion because, in addition to clarifying requirements for a self-asserted VC that is secured using the VP mechanism, it removes the type requirements. I believe that there is real value in having a unified type for self-asserted credentials, so rather than removing it entirely have changed the requirement from a MUST to RECOMMENDED.

<p>
The example below shows a <a>verifiable presentation</a> that embeds a
self-asserted <a>verifiable credential</a>.
</p>

<pre class="example nohighlight" title="Verifiable presentation with a self-asserted verifiable credential">
msporny marked this conversation as resolved.
Show resolved Hide resolved
{
"@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", "SelfAssertedCredential"],
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
"type": ["VerifiableCredential", "SelfAssertedCredential"],
"type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],

I'm unsure about this suggestion. I think it's the required type of SelfAssertedCredential that's throwing me off.

Given that we want to create a level playing field (anyone can issue VCs about anything, holders included), it feels like we shouldn't create a distinction between "self-asserted" vs. "officially-asserted". These are all just VCs and you either trust the issuer to make statements, or you don't. One of those issuers that you choose to trust might be the holder, like when you ask them about their favorite cheese... and you need to have them on record that they (the holder) expressed what their favorite cheese was to you... perhaps due to some sort of really important cheese census taking effort (which I expect they take seriously in countries where a significant portion of their commerce is related to cheese).

So, in this case, they'd probably be issuing a VC with a type of FoodPreferenceCredential, not SelfAssertedCredential.

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 have modified the example to include FoodPreferenceCredential, but I am not yet convinced that removing SelfAssertedCredential is the best path forward.

brentzundel marked this conversation as resolved.
Show resolved Hide resolved
"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>
</section>
</section>
</section>

Expand Down