Closed jceb closed 7 months ago
My current understanding is that Verifiable Presentations can't be represented in the JWT format. The VC Data Model spec gives no JWT example for presentations (https://w3c.github.io/vc-data-model/#presentations-0). One VC that references just one subject can be represented as JWT as seen here, multiple subjects aren't supported either: https://w3c.github.io/vc-data-model/#credential-subject
The reason for this lack of support seems to be the 1:1 relationship between JWT's iss
and VC's issuer
properties and JWT's sub
and VC's credentialSubject.id
properties. When there are multiple issuers, e.g. a presentation with multiple VCs, or multiple subjects, e.g. a VC with multiple subjects, the 1:1 relationship can't be expressed unambiguously anymore. Therefore, the mechanisms for verifying JWTs won't work and my impression is that this is the reason for not supporting VPs and certain types of VCs.
Conclusion:
At the moment, I lean towards not supporting JWTs in this spec explicitly and sticking to JSON-LD-VPs. If the above mentioned example is added to the VC spec, VPs with JWT-VCs will become possible and hopefully supported by multiple libraries.
@brianorwhatever and @peacekeeper I'd very much appreciate your input on this topic.
Here is the relevant section of VCDM 2.0 that was just merged https://www.w3.org/TR/vc-data-model-2.0/#enveloped-verifiable-credentials And you can secure this VP using either Data Integrity or JWT
Okay, I think I'm gradually forming in my mind how it could work. The Verifiable Presentation as a JSON/JSON-LD document is embedded into the JWT via the reserved vp
property (https://www.w3.org/TR/vc-jose-cose/#jose-header-parameters-and-jwt-claims). Credentials in the presentation are either standard JSON/JSON-LD documents with an attached data integrity LD-proof or they are JOSE/COSE secured credentials of type EnvelopedVerifiableCredential
. This will also provide support for selective disclosure.
So full JWT support is possible alongside LD-proofs.
Don't use the vp property, and I would recommend not using data integrity proofs.
@OR13 do I understand you correctly that instead of hiding the VP inside the vp
property, I should
{"@context": [..], "verifiableCredential": [..], "holder": .., "type": [..]}
iss
, sub
, ... that are copies of the properties in the VP: {"@context": [..], "verifiableCredential": [..], "holder": .., "type": [..], "iss": .., "sub": ..}
You don't need to add any additional properties, unless you want to use selective disclosure.
This specification should not define anything at all it should allow any conformant Verifiable Presentation and refer to the VCDM spec(s) for that.
I'm fully with you. I want to make sure that the spec supports the various formats.
I updated the examples to include only JWT presentations and credentials. However, I don't yet understand whether it's a good idea to use the vp
and vc
properties in the payload. @OR13 says we shouldn't, however at least in the VC Data Model spec explicitly states the vc
property, see https://w3c.github.io/vc-data-model/#credential-subject.
Not sure how to continue.
The examples you are looking at are from v1. Nobody has bothered to update them.
@OR13 thanks, that's helpful. I'll update the examples to v2.
In addition to JSON-LD, this spec should incorporate support for JWT as the other big ecosystem of DIDs and credentials.