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 validation section regarding holder #1199

Merged
merged 39 commits into from
Sep 14, 2023
Merged

Add validation section regarding holder #1199

Changes from 8 commits
Commits
Show all changes
39 commits
Select commit Hold shift + click to select a range
e905e13
Add validation section regarding holder
OR13 Jul 12, 2023
2f53093
Update index.html
OR13 Jul 13, 2023
44428d1
Update index.html
OR13 Jul 13, 2023
3b49311
Update index.html
OR13 Jul 13, 2023
c136795
Update index.html
OR13 Jul 13, 2023
c5da4cb
Update index.html
OR13 Jul 13, 2023
0ab19a2
Update index.html
OR13 Jul 13, 2023
5ecdfa8
Update index.html
OR13 Jul 13, 2023
9dbd12e
Update index.html
OR13 Jul 14, 2023
8369c55
Update index.html
OR13 Jul 14, 2023
634e403
Update index.html
OR13 Jul 14, 2023
225ead3
Update index.html
OR13 Jul 14, 2023
8dcf3a8
Update index.html
OR13 Jul 14, 2023
32b6254
Update index.html
OR13 Jul 14, 2023
3d2c7a6
Update index.html
OR13 Jul 17, 2023
1243884
Update index.html
OR13 Jul 17, 2023
ae5104a
Update index.html
OR13 Jul 17, 2023
9515253
Update index.html
OR13 Jul 17, 2023
5e5bc52
Update index.html
OR13 Jul 17, 2023
0233e2e
Update index.html
OR13 Jul 20, 2023
223064c
Update index.html
OR13 Jul 20, 2023
98c156b
Update index.html
OR13 Jul 20, 2023
567bfac
Update index.html
OR13 Jul 23, 2023
260568e
Update index.html
OR13 Jul 23, 2023
8433dbf
Update index.html
OR13 Jul 23, 2023
dbfaa37
Update index.html
OR13 Jul 23, 2023
bbb41b0
Update index.html
OR13 Jul 23, 2023
32c8e84
Update index.html
OR13 Aug 1, 2023
422caa2
Update index.html
OR13 Aug 1, 2023
f91ccbf
Update index.html
OR13 Aug 3, 2023
5d44e0e
Update index.html
OR13 Aug 3, 2023
291402b
Update index.html
OR13 Aug 22, 2023
ff5913d
Update index.html
OR13 Aug 25, 2023
466fa50
Update index.html
OR13 Aug 26, 2023
7d87d3a
Update index.html
OR13 Aug 30, 2023
9203268
Update index.html
OR13 Aug 31, 2023
a1d0c32
Update index.html
OR13 Aug 31, 2023
159855f
Update index.html
OR13 Aug 31, 2023
de684ba
Update index.html
OR13 Sep 1, 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
61 changes: 61 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4853,6 +4853,67 @@ <h3>Issuer</h3>
</p>
</section>

<section class="informative">
<h4>Holder</h4>
<p>
The value associated with the <code>holder</code> <a>property</a> is expected
to identify the <a>holder</a> to the verifier.
<a>verifier</a>.
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</p>
<p>
Relevant metadata about the <code>holder</code> <a>property</a> is expected
to be available to the <a>verifier</a>. For example, a <a>holder</a> can
OR13 marked this conversation as resolved.
Show resolved Hide resolved
publish information containing the verification material used to secure
<a>verifiable presentations</a>. This metadata is relevant when
checking proofs on <a>verifiable presentations</a>.
Copy link
Contributor

Choose a reason for hiding this comment

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

This section presumes far too much on behalf of the verifier.

VCs are most useful when, in fact, the verifier knows nothing about holder except what is presented by VCs and VPs.

It may be that you are thinking in terms of a specific securing mechanism, but to be clear, if I have a DID from a method I'm willing to accept, there is no meta-data required to verify. The DID provides the data I need.

Copy link
Member

Choose a reason for hiding this comment

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

if I have a DID from a method I'm willing to accept, there is no meta-data required to verify. The DID provides the data I need.

...which implies that there is no relevant metadata to be available, which satisfies the first sentence.

What would you change?

Copy link
Contributor

Choose a reason for hiding this comment

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

If there is no metadata, then I would not expect it to be available.

Perhaps more importantly, this notion that a holder is going to publish anything is confusing. Holders don't "publish".

I think this is trying to explain that if the holder property is not a DID, you can do magic, but if it's not, you need a bunch of extra metadata. But its trying to say this without mentioning DIDs.

However, this is not correct. It could be a simple URL with a type someone knows how to use to do the verification.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is copy pasted from the issuer section on security... IMO it either applies to issuers and holders consistently (meta data related to keys is required to check proofs), or holders don't have keys / presentations don't have security.

Copy link
Member

Choose a reason for hiding this comment

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

[@jandrieu] if the holder property is not a DID, you can do magic, but if it's not, you need a bunch of extra metadata

I'm confused by if ... not, but if ... not. It seems that one of these should not have the not.

[@OR13] This is copy pasted from the issuer section on security

Why is anything being said identically in two sections?

[@OR13] applies to issuers and holders consistently

I think issuers (who will be issuing MANY VCs) are expected to have substantially more VC-related infrastructure than holders (who will be issuing relatively small numbers of VCs/VPs, probably via wallets in most if not all cases), so I don't think much will [apply] consistently between them. I'm not yet convinced that this should be one of those things that [apply] consistently.

</p>
<p>
See the <a href="https://www.w3.org/TR/vc-data-model/#subject-holder-relationships">Subject-Holder Relationships</a> and
OR13 marked this conversation as resolved.
Show resolved Hide resolved
OR13 marked this conversation as resolved.
Show resolved Hide resolved
<a data-cite="VC-USE-CASES#user-tasks"></a> for additional examples related to <a>subject</a> and <a>holder</a>.
</p>

<p class="note">
`issuer`, `subject` and `holder` are graph nodes, which support multiple representations,
OR13 marked this conversation as resolved.
Show resolved Hide resolved
making validating that these roles are performed by the same entity potentially complex.
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</p>
<ul>
<li>
<a href="#issuer">Issuer</a> defines expressions of `issuer` in <a>credentials</a>
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</li>
<li>
<a href="#presentations-0">Presentations</a> defines expressions of `holder` in <a>presentations</a>
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</li>
<li>
<a href="#credential-subject">credential subject</a> defines expressions of `credentialSubject` in <a>credentials</a>
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</li>
</ul>
<p>
A <a>verifier</a> might believe that a <a>verifiable presentation</a> <a>holder</a>
OR13 marked this conversation as resolved.
Show resolved Hide resolved
OR13 marked this conversation as resolved.
Show resolved Hide resolved
is the same entity as a <a>verifiable credential</a> <a>subject</a>, when the following conditions apply:
</p>
<ul>
<li>
The <a>verifiable presentation</a> is secured,
using a mechanism the <a>verifier</a> trusts to protect the integrity of <code>vp+ld+json</code>.
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</li>
<li>
The <a>verifiable presentation</a> includes one or more <a>verifiable credentials</a> that are secured,
using a mechanism the <a>verifier</a> trusts to protect the integrity of `vc+ld+json`.
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</li>
<li>
<p>
When the identifiers for `holder` and `subject` are the same.
awoie marked this conversation as resolved.
Show resolved Hide resolved
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</p>
</li>
<li>
<p>
When the verification material used to secure a <a>verifiable presentation</a>,
OR13 marked this conversation as resolved.
Show resolved Hide resolved
is also present in the claims about the credential <a>subject</a>, either by value or by reference.
</p>
</li>
</ul>
</section>

<section class="informative">
<h3>Issuance Date</h3>

Expand Down