search

w3c / vc-jose-cose

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

Detached payloads MUST NOT be supported #278

Closed msporny closed 1 month ago

msporny commented 5 months 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 5 months 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 5 months 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?

selfissued commented 3 months ago

Allowing detached payloads is not a normative change since the underlying specifications (JWS, COSE), already define their use. Prohibiting detached payloads would be a normative change.

msporny commented 3 months ago

selfissued added has-pr and removed CR1 normative labels 1 hour ago

If you are removing these labels, how are the VC JOSE COSE Editor's tracking class 1-4 changes during CR1 in order to construct the list of substantive changes: https://www.w3.org/policies/process/#publishing-crud

The "normative" label on this issue is signalling that the issue would result in a normative change to the specification if pursued, which it would. The "CR1" label on this issue is signalling that the issue was taken and processed during the first Candidate Recommendation phase.

The Editor's don't seem to be labeling issues received during CR, nor do you seem to be labeling which class PRs fall into (class 1-4).

selfissued commented 3 months ago

I removed the CR1 label because we're past the first CR, so this PR can't be targeted at it, by definition. You seem to have a different meaning in mind for CR1 other than the work being targeted at the first CR, but I'm not sure what that is.

Let's talk about the change tracking you're referring to on the next editors' call that we can all attend. (I already let Brent know that I have a one-time conflict for tomorrow's editors' call.)

decentralgabe commented 1 month ago

As per the TPAC discussion, we are closing this as 'won't fix'. Detached payloads are possible, and we do not need language around them.