Add validation section regarding holder #1199
Conversation
OR13
requested review from
msporny,
selfissued,
decentralgabe and
awoie
as code owners
There was a problem hiding this comment.
+1 overall to the concept of this PR. I've been wanting to have stronger statements around how to verify subject == holder. We haven't put that text in to date because people insisted that had to do with protocol, but this PR demonstrates that we can describe expectations w/o getting into protocol. I'll do a full review of this after the text has settled a bit... just noting preliminary support for "saying something" about this topic in the spec. My preference is we get normative about the statements so it's clear how one can do DIDAuth (or something equivalent) with the data in the VP and VCs (which reflects reality today).
index.html
Outdated
| 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 |
There was a problem hiding this comment.
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:
- 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.
- why is this even important in the definition of the holder property?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
holderis 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?
- 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.
- 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
holderproperty 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
IMO, if we would commit my latest suggestion below, this would address my concern: #1199 (comment)
There was a problem hiding this comment.
direction looks good, pls address comments. i'm also curious how this relates to https://w3c.github.io/vc-jwt, or is this something that the jose/cose-specific media types need to take care of which might be also fine.
index.html
Outdated
| 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 |
There was a problem hiding this comment.
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?
Co-authored-by: Gabe <[email protected]>
Co-authored-by: Gabe <[email protected]>
Co-authored-by: Oliver Terbu <[email protected]>
Co-authored-by: Oliver Terbu <[email protected]>
Co-authored-by: Oliver Terbu <[email protected]>
I don't think holder or issuer are restricted to specific media types in the core data model. Some securing mechanisms (like JWT) already have registered claims that support existing verification systems. See #1149 for more details |
We put proof verification material discovery in data integrity and vc-jwt... does that mean we only validate proofs from "issuers" and never "holders"? ... but yes, I had the same thought when copy pasting from issuer validation section.
I am in favor of "getting normative" in the core spec, as long as that doesn't mean normative for only 1 securing mechanism. The other option is to keep normative validation out of the core spec, and refer to informative section of the core spec fro context, while relying on the securing spec to handle securing specific details for issuer and holder.... I think that might end up being more flexible, but it reintroduces the "did method problem" to VCs... now you need to read a billion VC specs in order to get claims... whereas you need to read a billion DID specs to get public keys or verification material. |
Co-authored-by: Brent Zundel <[email protected]>
Co-authored-by: Dave Longley <[email protected]>
|
This PR is hugely problematic. I need to give it a close re-read, including all the prior comments, but just touching on a snippet of one comment --
There may be use cases where this is so, but an anonymous holder (presenter) is entirely plausible in many cases. Example: I present a VC coupon to the cashier at my local supermarket. If that coupon is not restricted to one use per customer — such as when it is instead restricted to one use per transaction, or to one use per matching item purchased, etc. — then there is no need to identify myself (as is true for most paper coupons, today) — so there is no need for the verifier to understand nor process any identifier used to refer to me. |
|
The issue was discussed in a meeting on 2023-08-09
View the transcript2.2. Add validation section regarding holder (pr vc-data-model#1199)See github pull request vc-data-model#1199. Manu Sporny: PR 1199, about validation section on "holder", waiting on JoeAndrieu feedback. Joe Andrieu: not sure where I'm at, "validation" versus "verification", no new comments from 3 weeks ago. Orie Steele: Agree "validation/verification", can file an issue, Joe agrees. |
|
As noted above and elsewhere, I refer all and sundry to RDF Concepts, Introduction, where resource are clearly stated to be synonymous with entity, and both/either may be anything, and may be the subject of a VC. In order to perform a role, the given entity/resource must be capable of such actions as are required for that role; for instance, a document probably cannot be an issuer or verifier. The ranges of |
|
The issue was discussed in a meeting on 2023-08-15
View the transcript1.2. Add validation section regarding holder (pr vc-data-model#1199)See github pull request vc-data-model#1199. Brent Zundel: next 1199 add validation section regarding holder; a few approvals. outstanding change requests from Joe. believe they've been addressed. please re-review. Joe Andrieu: I have reviewed recently. Brent Zundel: moving in a direction where consensus is still possible. |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Brent Zundel <[email protected]>
|
AFAIK, this is still waiting on a re-review from @jandrieu . |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Joe Andrieu <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Dave Longley <[email protected]>
|
The issue was discussed in a meeting on 2023-08-29
View the transcript1.1. Add validation section regarding holder (pr vc-data-model#1199)See github pull request vc-data-model#1199. Manu Sporny: waiting on JoeAndrieu re-review. Joe Andrieu: will look at again. |
|
The issue was discussed in a meeting on 2023-09-05
View the transcript3.1. Add validation section regarding holder (pr vc-data-model#1199)See github pull request vc-data-model#1199. Manu Sporny: +1199 joe said he would review. Joe Andrieu: there has been some discussions on this already. |
|
The issue was discussed in a meeting on 2023-09-14
View the transcript1.1. (pr vc-data-model#1199)See github pull request vc-data-model#1199. Brent Zundel: Raised by orie. Good review and a number of comments. 1 open request for changes from TallTed. Are you're changes unaddressed? Ted Thibodeau Jr.: Haven't had the chance to review. Brent Zundel: If it meets your approval, we can merge. |
Addresses #959
Preview | Diff