Closed kdenhartog closed 6 months ago
I find this fairly confusing. What specific text do you want added to the spec and where?
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:
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.
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.
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.
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...
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."
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
The issue was discussed in a meeting on 2024-01-09
from https://github.com/w3cping/privacy-request/issues/125#issuecomment-1849123834