search

w3c / vc-jose-cose

Verifiable Credentials Working Group — VC JSON Web Tokens specification
https://w3c.github.io/vc-jose-cose/
Other
31 stars 9 forks source link

Detached payloads MUST NOT be supported #278

Open msporny opened 3 weeks ago

msporny commented 3 weeks ago

This issue came up in https://github.com/w3c/respec-vc/issues/31 where the examples it generates for application/vc+cose do not contain the Verifiable Credential in the signed data (a detached payload). Based on the language in the specification, it doesn't seem like detached payloads are supported at all:

A conforming COSE issuer implementation MUST use COSE_Sign1 as specified in [RFC9052] to secure this media type. The unsecured verifiable credential is the unencoded COSE_Sign1 payload.

We should explicitly disallow detached payloads as it's not clear how an application would convey a detached payload (there is no guidance anywhere on how to do that AFAICT). The examples in the specification should align w/ the examples for application/vc+jwt and application/vc+sd-jwt and contain the enveloped payload.

decentralgabe commented 2 weeks ago

Discussed on the VC-JOSE-COSE editors call today.

We believe that we should support both attached and detached payloads. The data structures currently convey whether a payload is detached or not (a nil value) and processing is determined based on that property.

@selfissued will address this.

msporny commented 2 weeks ago

I'm having difficulty understanding the use case for a detached payload. Isn't that just a COSE structure where we don't need a new media type? That is, the media type doesn't envelope the data, it's not self contained, it's not self describing, etc. Where is this expected to be used?