Remove requests for multiple suffixes #186
Conversation
| @@ -222,7 +214,7 @@ <h2>Securing the VC Data Model</h2> | |||
| <p> | |||
| The most specific media type (or subtype) available SHOULD be used, instead of | |||
| more generic media types (or supertypes). For example, rather than the general | |||
| <code>application/sd-jwt</code>, <code>application/vc+ld+json+sd-jwt</code> | |||
| <code>application/sd-jwt</code>, <code>application/vc2+sd-jwt</code> | |||
There was a problem hiding this comment.
| <code>application/sd-jwt</code>, <code>application/vc2+sd-jwt</code> | |
| <code>application/sd-jwt</code>, <code>application/vc+sd-jwt</code> |
There was a problem hiding this comment.
This was actually intentional... see w3c/vc-data-model#1363 (comment)
we don't know if application/vc will expose media type parameters, so we have no idea if sd-jwt will need a way to signal new version of application/vc... hence the need to make a "new subtype".
There was a problem hiding this comment.
The vc2 thing seems like a hack to work around something. I'd rather that we decide what the right thing to do is and do that, rather than incorporate workarounds.
There was a problem hiding this comment.
its an example, not a recommendation
There was a problem hiding this comment.
The multiple suffixes issue was already discussed in the closely-related issue #179 (comment). As concluded there, the path of least resistance is to leave the present registration requests in place. Then one of two things could happen:
- Structured suffixes are approved in the IETF. In that case, no changes will be required in this specification.
- Structured suffixes are rejected by the IETF. In that case, we will change our registration requests, which could require a second CR.
I am fine marking these registrations as being "at risk", as discussed on today's special topic call. Let's update this PR to do that or create a different one to do that.
W3C WG editors are supposed to implement decisions made by the WG as a whole, not the other way around. I can think of numerous instances of "paths of least resistance" which would have been bad for interoperation, web users on both sides (servers and browsers), and the Internet writ large. I do not think that such "paths of least resistance" are a good basis for most technological decisions, especially where that "least resistance" essentially ignores or negates existing specifications, and may impact many implementations and deployments which are not generally known to spec authors/editors because implementers and deployers are not required to announce their activities and have (and should have) a reasonable expectation that such existing specifications will not be changed out from under them. |
| @@ -222,7 +214,7 @@ <h2>Securing the VC Data Model</h2> | |||
| <p> | |||
| The most specific media type (or subtype) available SHOULD be used, instead of | |||
| more generic media types (or supertypes). For example, rather than the general | |||
| <code>application/sd-jwt</code>, <code>application/vc+ld+json+sd-jwt</code> | |||
| <code>application/sd-jwt</code>, <code>application/vc2+sd-jwt</code> | |||
There was a problem hiding this comment.
| <code>application/sd-jwt</code>, <code>application/vc2+sd-jwt</code> | |
| <code>application/sd-jwt</code>, <code>application/vc+...+sd-jwt</code> |
There was a problem hiding this comment.
@selfissued would this address your concern? I would like to have a PR that leaves the door open to removing the reference to multiple suffixes entirely.
There was a problem hiding this comment.
What does the ... mean?
There was a problem hiding this comment.
it means, not relevant to understanding the paragraph.
There was a problem hiding this comment.
I agree with @selfissued, we don't need to remove multiple suffixes yet. It would be good for the WG to discuss this in more depth (the use of media types) since there seems to be an attempt to go the "path of least resistance" which is not going to address the fundamental issue here... which has to do w/ how JOSE/COSE encapsulates other media types.
Speaking as the Editor of the multiple suffixes draft, it seems to be on the path to go through, so it's premature to remove multiple suffixes at this point in time
|
@msporny the intention with this PR is to give the working group an option to advance the document, in the case that there is no consensus on how to use the suffixes draft, its not to prevent people from using multiple suffixes. After this PR is merged it would still be legal to create specific subtypes that use multiple suffixes, this PR just removes potential procedural barriers, and can capture working group consensus, which does not seem to clearly endorse using multiple suffixes. |
|
The issue was discussed in a meeting on 2023-12-20
View the transcript3.2. Remove requests for multiple suffixes (pr vc-jose-cose#186)See github pull request vc-jose-cose#186. Michael Jones: PR 186. Objections from me and Manu. It wants to pull out media types. Chose these as a working group. Could they be changed in future. Manu Sporny: +1 to what Mike said. Michael Jones: two related issues from this PR. Will mark as post CR. Brent Zundel: In light of those issues do we need to keep this PR open. Michael Jones: Very good. |
|
We decided on the 20-Dec-23 working group call to address this post-CR, if it appears that we need to do so. We decided to close this on the call. The discussion is being tracked at the referenced issues. |
|
|
This PR removes all requests for multiple suffixes (all commentary on
+ld+json+sd-jwt) which applies to both Verifiable Credential and Verifiable Presentations.It says that
typSHOULD be used, but it does not say what value it should have, only that issuers and verifiers should understand itPreview | Diff