Spec should be more specific about implementation details

[kdenhartog]

from https://github.com/w3cping/privacy-request/issues/125#issuecomment-1849123834

I think that was fairly clear. I'm pretty sure the WG means that an issuer MUST secure each VC (from the core data model spec), and one of the ways it MAY secure them is COSE. If the issuer does that, it SHOULD identify that fact using content types.

Ok, that's good to hear. Yeah I could definitely see someone going "Hey I don't want to use COSE here for X, Y, and Z reason, but CBOR looks nice. I'll just use this unspecified content type that I made up and isn't defined anywhere and call it conformant with the VC-JOSE-COSE spec". Based on the usage of MAY and SHOULD here, they'd technically still be conformant even though it's wildly divergent from what's defined and I wanted to make sure that was called out to spec authors. This one should be as simple as just making the spec language a bit stronger. One example would be:

"If an implementer wishes to use CBOR as a serialization format they MUST USE RFC9052 and MUST specify the content type as...".

My language might still face tradeoffs here, but it at least remains narrowly defined to make it easy for someone to implement later. I'll open an issue on the spec to make sure people are aware of this concern.

[selfissued]

I find this fairly confusing. What specific text do you want added to the spec and where?

[kdenhartog]

The normative text is currently too broad to be testable is the issue. It allows for the option to utilize a different proof mechanism to signing the data because it's too broad. For example, an implementer could use the media-type as an HTTP header where the unsigned credential is the JSON payload and use HTTP signatures to secure it. In this scenario, They've opted to ignore RFC7515 as the securing mechanism for the media type, but still are technically compliant because they're using the media type defined here. However, I think we'd all agree this isn't the intention of the spec.

So here's the proposed text changes. The spec currently says:

JOSE section changes

In section 3.1.1 and 3.1.2:

[RFC7515] MAY be used to secure this media type. The typ header parameter SHOULD be vp+ld+json+sd-jwt.

This should be modified to say:

[RFC7515] MUST be used to secure this media type. The typ header parameter MUST be vp+ld+json+sd-jwt.

---

COSE section changes

In section 3.2.1 and 3.2.2:

[RFC9052] MAY be used to secure this media type. The typ header parameter SHOULD be application/vc+ld+json+cose.

This should be modifed to say:

[RFC9052] MUST be used to secure this media type. The typ header parameter MUST be application/vc+ld+json+cose.

[selfissued]

I at first thought that MUSTs should be in place where you site, as you do, but that would mean that the spec is contradicting itself. We can't both say that JWS MUST be used to secure a media type and also say that COSE_Sign1 MUST be used to secure the same media type. That's why the MAYs are there.

If you have a different suggestion that wouldn't cause the spec to be self-contradictory, I'd be glad to hear it and apply it.

[kdenhartog]

If you have a different suggestion that wouldn't cause the spec to be self-contradictory, I'd be glad to hear it and apply it.

Would it make sense to differentiate the media types in these scenarios then?

Alternatively branch the statement on the serialization format used was the idea I was thinking about when I originally opened it so the text could become something like this:

If using a JSON serialization of verifiable credentials conforming to [VC-DATA-MODEL-2.0] [RFC7515] MUST be used to secure this media type. The typ header parameter MUST be vc+ld+json+sd-jwt. When present, the cty header parameter SHOULD be vc+ld+json. See Registered Header Parameter Names for additional details regarding usage of typ and cty.

Similarly we could say the same where it goes If using a CBOR serialization of verifiable credentials conforming to...

[selfissued]

When we describe conformance profiles for COSE, SD-JWT, and maybe JOSE, per #202 , we can then change the language to a form of "When using the X conformance profile, the payload MUST be secured with Y."

[kdenhartog]

When we describe conformance profiles for COSE, SD-JWT, and maybe JOSE, per #202 , we can then change the language to a form of "When using the X conformance profile, the payload MUST be secured with Y."

SGTM - that would be perfect

[iherman]

The issue was discussed in a meeting on 2024-01-09

• no resolutions were taken

View the transcript

#### 1.3. Horizontal Review Tracking (issue vc-jose-cose#195) _See github issue [vc-jose-cose#195](https://github.com/w3c/vc-jose-cose/issues/195)._ _See github issue [vc-jose-cose#192](https://github.com/w3c/vc-jose-cose/issues/192)._ **Michael Jones:** This is related to issue 192. … kyle didn't like language in the spec around securing with sd-jwt and JOSE. Neither result in a testable conformant statement. … manu raised an issue around conformance classes. … can satisfy Kyle by using conformance profiles to create testable statements. **Manu Sporny:** +1 I agree this would address mine and kyles concerns. … on issue 195, the TAG isn't in the HR tracking, may want to add. … We need to get a response from security before we close the issue. … Don't need it to go into CR, but don't close issues on other groups trackers. **Brent Zundel:** I know review request was submitted in May 2023. > *Manu Sporny:* -> [https://github.com/w3ctag/design-reviews/issues/899](https://github.com/w3ctag/design-reviews/issues/899). **Brent Zundel:** TAG has an issue that is design review, that is closed on orie's request because of text changes. … new one has been opened. Issue 899 in September 23. … Looks like they are planning to discuss in the f2f in London this month. **Michael Jones:** can you add this to Horizontal Review issue 195. … another progress report - issue 206.