Clarify sentence about derived credentials and presentations #1167
Conversation
Signed-off-by: Brent Zundel <[email protected]>
Signed-off-by: Brent Zundel <[email protected]>
brentzundel
requested review from
msporny,
OR13,
selfissued,
decentralgabe and
awoie
as code owners
brentzundel
changed the title
There was a problem hiding this comment.
I have slight trepidation with this language as one interpretation of it could be: "You can transform a W3C VC into /anything/ and call it a verifiable presentation." -- which starts us down a slippery slope. I'm only ok w/ this language because it's not normative.
There are at least five use cases that this text probably covers:
- I have a VC that's secured, here you go, you should interpret it as a VP.
- I have a VC that's secured, I have wrapped it in a VP that's not secured, here you go, you should interpret that as a VP.
- I have a selectively disclosable VC that's secured, I have derived it into another VC w/ a different proof where you can determine if it's valid, I have not wrapped it in a VP, here you go, you should interpret it as a VP.
- I have a selectively disclosable VC that's secured, I have derived it into another VC w/ a different proof where you can determine if it's valid, I have wrapped it in a VP that's not secured, you should interpret all of this as a VP.
- I have a set of selectively disclosable VC that are secured, I have derived them into other VCs with different proofs where you can determine all of the proofs are valid, I have also wrapped the VP that adds additional information to bind all the selectively disclosable things together into an interactive presentation (for example, added domain and challenge to the presentation), this is definitely a VP.
There might be a sixth one in there. All that to say, I don't know if spelling out all of the above would help more than harm. Fundamentally, the original text is trying to say: "Bearer VCs are ok, you can interpret them as a form of verifiable presentation." ... but the addition of notes on selective disclosure are good too.
There was a problem hiding this comment.
All those different "things" can be put into the verfiableCredentials property in a verifiable presentation but they are not verifiable presentations themselves. IMO, nothing is a verifiable presentation that does not follow the data model defined in 4.10 Presentations
| formats derived from <a>verifiable credentials</a> that are cryptographically | ||
| <a>verifiable</a>, but do not of themselves contain | ||
| <a>verifiable credentials</a>, might also be <a>verifiable presentations</a>. | ||
| are presented directly, they become <a>verifiable presentations</a>. |
There was a problem hiding this comment.
IMO, that sentence is in contradiction to 4.10 Presentations.
There was a problem hiding this comment.
Can you say more? I'm not seeing the contradiction.
There was a problem hiding this comment.
Can we just strike the sentence about VCs "becoming" VPs here? What does it do for us? I think the language here was trying to be helpful or inclusive about something that was fuzzily defined in the past that's no longer needed now.
| To support selective disclosure capabilities, data formats derived from | ||
| <a>verifiable credentials</a>, that are cryptographically <a>verifiable</a> but | ||
| are not themselves <a>verifiable credentials</a>, might also be | ||
| <a>verifiable presentations</a>. |
There was a problem hiding this comment.
That also interferes with 6.10 Presentations.
There was a problem hiding this comment.
I think you meant 4.10 here. Can you point out more explicitly what contradiction you see?
There was a problem hiding this comment.
My apologies, I meant 4.10, correct.
The problem or confusion is the following. According to 4.10, a presentation typically has the following members:
type
The type property is required and expresses the type of presentation, such as VerifiablePresentation. For details related to the use of this property, see Section 4.4 Types.verifiableCredential
If present, the value of the verifiableCredential property MUST be constructed from one or more verifiable credentials, or of data derived from verifiable credentials in a cryptographically verifiable format.
I know that neither type nor verifiableCredential are mandatory as per VCDM. But if VCs and derived VCs are verifiable presentations, then the definitions above lead to confusion. The definitions above suggest that VCs and derived VCs would be in the verifiableCredential array. If this is no longer the case and a derived VC is itself a VP, then we suddenly have two ways to encode a derived VC (or plain VC) in a VP.
There was a problem hiding this comment.
In general, I'm not sure if we want to have that polymorphism where we would allow VCs and derived VCs to be VPs which could lead to some interesting side effects and potentially semantic confusion where suddenly verifiers cannot disambiguate any longer whether fields such as id, proof, type etc. are VC metadata or related to the presentation.
There was a problem hiding this comment.
I find what @awoie is saying to make a lot of sense. It also fits in well with the transformation concept we have expressed elsewhere. My understanding is that this text was originally meant to help cover some bases around, for example, CL-protected / AnonCred style presentations, but based on recent demonstrations, I'm pretty sure it's no longer needed.
We should probably simplify the language to just talk about VPs (as they appear in the spec itself) and simplify the verifiableCredential property to just talk about VCs instead of "data derived from" them. People should be able to transform to / from VCs (or VPs) as needed or they should use another property in an extended VP to express other formats. It has been suggested elsewhere that we could add one or more other properties for other data to travel in VPs (such as VCs encrypted as JWEs); that seems the right way to go to avoid confusion.
There was a problem hiding this comment.
We should probably strike this whole paragraph as well. I don't think it means anything to say some undefined thing "might be a verifiable presentation". Not saying it doesn't prohibit anyone from doing selective disclosure or using other formats to present or transfer information that are derived from VCs that aren't VPs. Those other formats aren't VPs unless they comply with the data model requirements for VPs -- that's what interop is about. I think that's fine; either you can transform from those other things to VPs and present that way or you can't.
There was a problem hiding this comment.
I suggest removing the text, if it does not make sense and lacks consensus.
|
Sounds like we need to have a bigger conversation about VPs. Currently, according to the spec, a VP is anything that is presented:
VPs are fuzzy, they always have been. This PR was an attempt to add a bit of clarity to the existing definition of VPs, without changing that definition. Feedback suggests that there is broader interest in modifying that definition. I will close this PR as it is clear that it doesn't not address Issue 996 |
This PR attempts to clarify a sentence identified in issue #996 as confusing.
If merged, this PR fixes #996
Preview | Diff