vc-data-model
vc-data-model copied to clipboard
w3c
Update media types to `application/vc` and `application/vp`
This PR is an attempt to address issue #1462 by setting the media types to something that would be uncontroversial from an IANA Media Types perspective. This PR changes the media type for a VC to "application/vc", and the media type for a VP to "application/vp".
The significant downside of this change is that there's no longer any obvious fallback from application/vc+ld+json to application/ld+json nor application/json, obviating all the work we did to make plain-JSON (or plain-JSON-LD) handling work.
The significant downside of this change is that there's no longer any obvious fallback from
application/vc+ld+jsontoapplication/ld+jsonnorapplication/json, obviating all the work we did to make plain-JSON (or plain-JSON-LD) handling work.
IMHO, this section exists, which makes it so this PR doesn't obviate all the work we did:
https://w3c.github.io/vc-data-model/#media-type-precision
The upside here is a client MAY request "application/json", or "application/ld+json" for a VC and the server MAY choose to serve it as such... and the section above says: "While that's not preferred, that's ok."
This PR also doesn't preclude "application/vc+ld+json" from happening in the future. If it does, we can just add it as another possibility for a "more specific type".
The issue was discussed in a meeting on 2024-04-17
- no resolutions were taken
View the transcript
3.1. Update media types to application/vc and application/vp (pr vc-data-model#1478)
See github pull request vc-data-model#1478.
Manu Sporny: there is a new PR around media types, this PR updates media types to just applications/vc and applications/vp.
… lots of stuff didn't need to change, the other language is already in the spec, so it seems simple and straightforward.
… should I kick off preliminary registration? in IETF you can do preliminary and then do final when you hit CR.
… should we do this to indicate direction?
Ivan Herman: I personally would prefer to do that if/when we merge this PR as that would signal this is really where the WG wants to go.
Brent Zundel: +1 to ivan's recommended timing.
Mahmoud Alkhraishi: +1.
Manu Sporny: will raise the IANA provisional registration early next week.
This would be a breaking change that's not warranted by the current discussions in the IETF mediaman working group. Those discussions have not yet reached a definitive conclusions. We should wait until they do before taking action.
@selfissued, you have more experience with the IETF process than I do. How long do you think it needs for IETF to say yay or nay? This has been on its agenda for years now...
Our limitations are clearer. We plan to go to Proposed Recommendation sometimes towards the end of the year. When we do, we MUST have a final version in the spec. Furthermore, the general requirements are such that when we go to Proposed Recommendation, the media types should be registered which, even with these simplified and non-controversial media types, also takes several weeks to through the process. I.e., I would think that this issue MUST be decided and documented in our specs by the end of, say, September.
Is there any reasonable expectation that IETF would decide by the end of summer? Because if the answer is yes, I agree with you that it can wait a few months. But if the answer is no, then it does not make sense to leave this issue open, we should get it over with, imho.
Furthermore, this change would break the media type usage in VC-JOSE-COSE.
Indeed. If this PR is approved, a similar PR must be raised for Jose-Cose.
Furthermore, this change would break the media type usage in VC-JOSE-COSE.
Based on the current discussion at IETF, the VC-JOSE-COSE media types are already broken and are highly unlikely to be approved by the IETF Media Types WG. We tried for 3 years and failed to get consensus in the IETF Mediaman WG.
There is no consensus for multiple suffixes, and there is growing consensus that even suffixes have been ineffective because they have not resulted in client software (browsers, clients, etc.) using them in the way they were intended to be used (full matching against the media type is the default, with no broad examples of processing suffixes by themselves).
Is there any reasonable expectation that IETF would decide by the end of summer? Because if the answer is yes, I agree with you that it can wait a few months. But if the answer is no, then it does not make sense to leave this issue open
Speaking as the Editor of the multiple suffixes specification at IETF, the answer is "no". There is no expectation that the conversation, which has been going on for years, will be complete by the end of the summer. There isn't even consensus on how we might document how suffixes are used now at IETF, or what patterns will be allowed.
The issue was discussed in a meeting on 2024-04-24
- no resolutions were taken
View the transcript
5.3. Update media types to application/vc and application/vp (pr vc-data-model#1478)
See github pull request vc-data-model#1478.
Manu Sporny: media types PR.... Should use /vp and /vc - dont' know how long this last. Should go with clear media types and continue multiple suffix's discussion in parallel.
Brent Zundel: change media types to something that we know will be approved with the intention of doing multiple structured suffixes until we know what IETF is going to do.
Michael Jones: this is a breaking change to many specs. It's a set of experts. Selfissued would like to request registration to call the question.
Manu Sporny: we tried to do this 3 years ago and it was rejected that led to the multiple suffixes draft. It's a breaking change but it's been barely implemented, and we're in CR so we can make breaking changes now.
Dmitri Zagidulin: @manu - what's the downside of just asking for registration? Stuff has changed in 3 years.
Manu Sporny: designated experts take advice from the spec which this case is the multiple suffixes spec which Manu is editor to. No timeline on getting this stuff resolved.
Manu Sporny: dmitriz -- it will be rejected, I can guarantee it. At the very least, I will object to it as the editor of the multiple suffixes draft.
Manu Sporny: I also expect the other DEs to reject it, having had this discussion with them for years.
Manu Sporny: I also expect the MEDIAMAN WG to suggest it be rejected, because it's actively used.
Ivan Herman: we have a timing issue as well. We'll need to republish the CR right after TPAC which must have the final version of the media types. To do this change to start media type registration will take 3 months and he's in favor of doing this change right now.
Michael Jones: good data that it was tried 3 years ago. Not clear that the decision 3 years ago would be be the same now. Designated experts have a 2 week response time so that's not a timing issue. Now we're basing our path forward uncertain data.
As discussed on today's call, the most straightforward way to get a definitive answer from the IETF is to call the question by requesting registration of the existing media types. The Designated Experts are required to approve or reject the registrations in a timely fashion.
the most straightforward way to get a definitive answer from the IETF is to call the question by requesting registration of the existing media types.
Then let's put both questions in front of the Designated Experts and see which one they approve and which one they reject. We'll let them know that it's one or the other.
They either allow us to register application/vc+ld+json or application/vc, and application/vp+ld+json or application/vp. Once we have the answer there, we can move on to registering the other media types based off of the base type.
I will repeat here what I have said on multiple calls now: There is no consensus at IETF on multiple suffixes for media types. I am the Editor of the multiple suffixes specification at IETF. I have fielded all of the issues/conversations about this topic at IETF, and the Designated Experts have rejected all previous registrations that contain multiple suffixes because there is no guidance on what they mean, how to use them, or how to register them. The registrations for application/vc+ld+json and application/vp+ld+json are highly likely to fail. We have already called the question 3 years ago, there is nothing different with this attempt other than we're trying to register application/vc+ld+json instead of application/did+ld+json.
@brentzundel, could we please add an item to the agenda for next week to see if we have consensus within the group on how we're going to go about registering the media type for the core data model?
The issue was discussed in a meeting on 2024-05-01
- no resolutions were taken
View the transcript
2.1. Update media types to application/vc and application/vp (pr vc-data-model#1478)
See github pull request vc-data-model#1478.
Brent Zundel: The group had a conversation about media types and the difficulty in trying to register the media types we were hoping to register which were application/vc+ld+json -- the attempt to register multiple suffixes in the DID WG the registration was denied, since then a lot more work has gone into defining what multiple suffixes mean and conversation with mediaman, the group working on those things at IETF and at IANA.
… We still don't have a clear direction from IETF on what we should do.
… The last time we discussed, we said, let's just proceed with application/vc and application/vp and then we can add the multiple suffixes stuff later once it gets sorted out.
… Mike suggested that perhaps we don't abandon our hopes and put forth both options to IANA instead and see what they say.
Michael Jones: The essence of what I had written in the comments is that I'd rather us not proceed based on informed speculation, but to try to call the question, with IANA.
… To try and register what's in our documents now.
… I volunteered to do so with the motivation that -- or explanation to the designated experts and that while discussions are ongoing, we have timelines to publish REC track docs.
… And we'll encourage that they proceed with the registrations, and we'll get a "yes" or "no" and they only have two weeks to decide so it doesn't impinge on our timelines.
David Chadwick: very sensible proposal.
Brent Zundel: Any objections to that approach -- any feedback on that?
Phil Feairheller: +1 that sounds like a viable approach. I don't see a downside.
Mahmoud Alkhraishi: +1 to proposal.
Gabe Cohen: +1.
Michael Jones: The group decided to proceed with whats in our spec, and I'm looking to proceed to make what's in our spec a reality.
Dave Longley: my comment would be that agree that doing this would be what the group decided earlier--pre-Brisbane--but I'm concerned we're headed into opposition knowingly.
… but I'd prefer we attempt both variations, to see which they prefer.
Benjamin Young: Yeah, I think what I was proposing is probably very similar to what Dave said -- I think we want to attempt multiple variations at once.
… The idea of putting these singular things up vs. multiple suffixes at the same time, it would give them a way to pick a lane.
… And I think that not doing both approaches at wouldn't give us enough information nor wrestle them in public -- we don't want to do things one at a time, we won't get new information, getting compare/contrast would be more helpful.
Michael Jones: Yeah, I was in Brisbane, my characterization of what happened in Brisbane, there was a lot of talk about a lot of parties on what we could do. Decision making hats weren't on, but more like talking about multiple possibilities. It even digressed into maybe single suffixes was a bad idea.
… That ship sailed most of a decade ago. This is one of the dysfunctions that can happen in a WG, discuss mode and not decision mode. That was in broad evidence in Brisbane.
… I think suggesting multiple things at once is bad tactics. If we give them the easy option and the one we decided on, they will pick the easy one, we will never find out what they think.
… It's not a discussion just a request to register.
Ivan Herman: +1 to selfissued.
Michael Jones: They either will or will not. If we frame it as endless discussion, then we won't get the data we need, so I won't do that.
Brent Zundel: This was attempted and failed three years ago for the DID WG. A lot has changed since then, so we'll see what happens.
Ted Thibodeau Jr.: Approximately what Mike said. If we ask for the thing that looks the most like the thing that looks most like what has been registered most recently, we won't get what we really want. If we ask for what we really want, we might get it or we might not.
… I really dislike the idea of repeating the exercise of three years ago with little difference. I don't think any of the decision maker decisions have changed. No different decision makers. I don't have high hopes of approval.
… I think given everything in the picture, I think asking for what we really want, is the way to go, then we can use the fallback.
Brent Zundel: The course of action we will take is to register application/vc+ld+json and application/vp+ld+json as written in the spec today and we'll see what happens.
Ivan Herman: Just a question -- Mike, what about the media types that are in the VC-JOSE-COSE documents?
Michael Jones: Yes, we'll do those too.
… It is a liaison request from W3C to IETF for what we've defined.
Brent Zundel: So it will be all of the media types that we have in all of our specs that we would attempt to register.
Benjamin Young: I wasn't at the IETF meeting, but I watched it. There was a lot of microphone time spent talking about letting multiple suffix stuff in so it can be weeded out as a bad idea. I'm concerned that would be an outcome -- and then our spec would be pointed at as a bad example.
Michael Jones: Maybe I'm a little too hard-nosed. But I'm not worried about the optics, it's apparently to me that different people in the mediaman group have different views and people who think it's a good idea won't change and neither will those who think it's a bad idea.
Anil John: +1 to what Mike just said.
Michael Jones: I think the outcome is inevitable either way.
Brent Zundel: If we have multiple suffixes and we succeed -- then multiple suffixes only ever means what we want it to mean.
Joe Andrieu: +1 to applying to see if our concerns are real, rather than not applying out of concern.
Brent Zundel: I haven't heard anybody say: Don't do this.
Anil John: Wanted to close the loop that I checked internally with the implementation teams that are working with us on using JOSE for securing our trade focused VCDM credentials, and they noted that they will be contributing to the relevant portions of the test suite for "W3C Securing Verifiable Credentials using JOSE and COSE".
The issue was discussed in a meeting on 2024-05-29
- no resolutions were taken
View the transcript
4.1. Update media types to application/vc and application/vp (pr vc-data-model#1478)
See github pull request vc-data-model#1478.
Manu Sporny: this is the media type discussion.
… the group decided to push ahead on registering what was in the documents.
… we were supposed to hear back in 2 weeks...we got no feedback.
… there was an ask on the mediaman list if there was new guidance...there was/is not.
Ivan Herman: now that we are working on the charter, if we take out the multiple suffixes and things change at the IETF...
… should we put something in the charter so we can deal with that...if/when it happens?
Manu Sporny: it's a good question, ivan.
… I think we've wasted enough time on this topic.
… we've talked it to death...and it's not holding up any implementations.
… we can always expand the list of media types later.
… given how this has gone so far, it's only going to take longer.
… so I think we can deal with this later.
Ivan Herman: than let's forget about it.
Brent Zundel: agreed.
The issue was discussed in a meeting on 2024-06-05
- no resolutions were taken
View the transcript
5.1. Update media types to application/vc and application/vp (pr vc-data-model#1478)
See github pull request vc-data-model#1478.
Manu Sporny: I need a determination from the WG on what media type we will use.
… talked about this a week ago, have not heard back from IETF registration on if they are accepting our media type.
… don't think reg will go through, do we want to wait until they reject registration to merge 1478 and pick media type they will accept.
Brent Zundel: that was path we agreed to last time we had this conversation, has anyone changed their mind since then.
Ivan Herman: will we at least get an explicit refusal?
Manu Sporny: can push them for explicit refusal.
Brent Zundel: mike jones pushed them, claimed that silence was acceptance.
Manu Sporny: thank you Brent for a reminder, I had forgotten we had agreed on this, waiting on them for rejection.
… doesn't sound like anyone has changed their mind.
Latest from IETF: registering application/vc+ld+json is a clear "No"
https://mailarchive.ietf.org/arch/msg/media-types/0pyhIW0ZkgfMgYE7EXoVCnRxioI/
@msporny there are conflicts, can you look at those?
@TallTed changes have been made since your request for changes, could you re-review?
@decentralgabe and @selfissued please re-review in light of rejection of registration request from IETF
The issue was discussed in a meeting on 2024-06-12
- no resolutions were taken
View the transcript
1. media types.
Brent Zundel: last time we talked about media types we were unsure the folks at IETF would register the types we wanted. for multiple suffixes, the document has much back and forth. considered pulling back and a simpler approach.
See github pull request vc-data-model#1478.
Brent Zundel: instead considering application/vp and application/vc. we finally heard back and heard "no" for multiple suffixes. may change in the future. at this point the media types we have been wanting are not able to be registered.
… we have a PR #1479 - our media types are application/vc and application/vp. it is fully approved. happy to talk about it if folks want. otherwise, let's merge it has been open a while.
@msporny there are conflicts, can you look at those?
All conflicts have been fixed.
Normative, multiple reviews, changes requested and made, no remaining objections, merging.