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 1 commit
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 an <a>holder</a> that is known to and trusted by the
OR13 marked this conversation as resolved.
Show resolved Hide resolved
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 having issues with the statement that the holder is supposed to be known and trusted by the verifier`. It is certainly a possibility but two questions:

  1. why do you assume such a strong statement about the holder/verifier relationship? The PR suggests that this statement is universal an does not explain why. I also want to say that the securing mechanisms have nothing to do with whether a holder is trusted or known by the verifier. They just protect the integrity of the payload.
  2. why is this even important in the definition of the holder property?

Copy link
Contributor

@awoie awoie Jul 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

My suggestion would be to remove that sentence entirely, or are you saying that the holder property should only be used if all of the conditions below apply?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I copy pasted the issuer validation section, I referred to the 3 roles in their graph structure, and I described in the abstract what validating that these roles are the same looks like.

I'm having issues with the statement that the holder is supposed to be known and trusted by the verifier`.

So am I, but its unavoidable, since the verifier needs to resolve keys that represent them... and those keys might be in a country the verifier does not trust, or or a blockchain they don't trust, or from an identifier who has previously lied, been convicted, or sanctioned...

Maybe the word trust is the problem here, any suggestions?

  1. I also want to say that the securing mechanisms have nothing to do with whether a holder is trusted or known by the verifier.

This can't be true, since an unsecured presentation that be used to do anything but send secured (possibly stolen) credentials... we also have language thanks to @brentzundel regarding claims the holder makes in a presentation and how they are secured... verifier needs to understand that securing mechanism to rely on holder claims.. like they understand credential securing mechanism to issuer claims.

  1. They just protect the integrity of the payload.

I wish this were true, but data integrity defines retrieve verification method, and OIDC has its own ways of discovering keys... a verifier needs to trust those systems in order to understand that the payload is secure.

2. why is this even important in the definition of the holder property?

Why is it important in the issuer property?

IMO, its for the same reasons, but interested if folks think holders have less security / trust / autonomy than issuers... we should document that better if its true.

My suggestion would be to remove that sentence entirely, or are you saying that the holder property should only be used if all of the conditions below apply?

Similar to the issuer property not being trust worthy when there is no security on the credential.

holder property can be on unsecured presentations, a good use case for this, is when you have previously authenticated a client, and you are relying on channel authentication for messages from the holder.

This is completely legal in the current VCDM... if it seems like a bug we can correct that.

Copy link
Contributor

@dlongley dlongley Jul 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

So am I, but its unavoidable, since the verifier needs to resolve keys that represent them... and those keys might be in a country the verifier does not trust, or or a blockchain they don't trust, or from an identifier who has previously lied, been convicted, or sanctioned...

Maybe the word trust is the problem here, any suggestions?

Hmm, the trouble here perhaps stems from a conflation of the holder's identity with its identifier. I agree that the verifier must be able to understand and process the identifier used to refer to the holder. This, however, does not mean that the verifier has a pre-existing relationship or a trust relationship with the holder itself or that the verifier recognizes the holder's "identity" in any way (other than by an identifier that references 'the same holder').

I think this is what is troubling @awoie and I agree.

It's worth noting (since it was mentioned above) that the issuer is fundamentally different in this respect -- issuer claims cannot be accepted (assumed) "as true" without some kind of external understanding or relationship around who the issuer is (the issuer's actual identity), which is more than just what identifier is being used to refer to the issuer. Of course, a verifier similarly needs to also be able to understand, process, and have confidence that an identifier does, in fact, refer to the issuer they think it does, but that's not the same thing.

I'm not sure yet how we resolve this, but the problem seems to stem from what I read as @OR13's desire to clearly indicate that the holder identifier (the "value" of the holder property) needs to be of a sort that the verifier can understand and process (this is certainly true or it won't be accepted) and @awoie's desire to make clear that that doesn't mean the verifier necessarily has any other knowledge about the identity of who the identifier refers to. In fact, a completely new relationship (or "introduction") could be getting established at the very moment.

Copy link
Contributor

Choose a reason for hiding this comment

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

IMO, if we would commit my latest suggestion below, this would address my concern: #1199 (comment)

<a>verifier</a>.
</p>
<p>
Relevant metadata about the <code>holder</code> <a>property</a> is expected
to be available to the <a>verifier</a>. For example, an <a>holder</a> can
publish information containing the verification material used to secure
<a>verifiable presentations</a>. This metadata is relevant when
checking the proofs on the <a>verifiable presentations</a>.
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</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 happens:
OR13 marked this conversation as resolved.
Show resolved Hide resolved
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</p>
<ul>
<li>
The <a>verifiable presentation</a> is secured,
using a mechanism the <a>verifier</a> trusts to protect the integrity of `vp+ld+json`.
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 provide a `proof` on a <a>verifiable presentation</a>,
is also present in the claims about the credential <a>subject</a>, either by value or by reference.
OR13 marked this conversation as resolved.
Show resolved Hide resolved
</p>
</li>
</ul>
</section>

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

Expand Down