Define one or more media types for VCs

[dhh1128]

I know that the current spec is only about a data model. However, it does discuss how credentials can be "realized" in the JSON and JSON-LD syntaxes, and it suggests others like CBOR.

I would like a sentence or two in the spec that says something like, "The MIME type of verifiable credentials is application/verifiable-credential+json." Obviously, the + part would have to be adjusted for each syntax. And we would need a separate but related MIME type for presentations.

I don't think a mime type of "application/ld+json" is appropriate for the JSON-LD rendering; while it would be true that the doc is JSON-LD, that would be the minor point; the major point would be its status as a credential. Credentials have so much specialized semantic meaning over and above the raw structural possibilities of JSON or even JSON-LD that describing them only in terms of their low-level serialization is a serious loss of meaning. We want people to be able to double-click the files and have the correct handler load.

[David-Chadwick]

I support the standardisation of (one or more) MIME types for VCs. One can argue that this is needed as it relates to all documents that conform to the VC data model and is independent of the transfer protocol, so it is not a protocol issue (which is out of scope of the current WG). I also prefer application/verifiable-credential+json or application/vc+json to "application/ld+json". Whether these definitions go in the main body of the spec, or in a normative annex, or in a separate registration document is less of a concern to me.

[brentzundel]

+1

[TallTed]

There's a bit more to it than saying "this is our MIME type!" https://www.iana.org/assignments/media-types/media-types.xhtml

[stonematt]

@brentzundel volunteered

[brentzundel]

If we can come to agreement about what we'd like the MIME type to be, I will start the registration process.

[David-Chadwick]

I vote for application/vc+json

[msporny]

I vote for application/vc+json

Unfortunately, if you guys want MIME Types, we won't be able to do just one, we will have to do four to six (due to the position certain organizations are taking in the group):

application/vc+json
application/vc+ld+json
application/vp+json
application/vp+ld+json
application/vc+json+jwt
application/vp+ld+json+jwt

We could cut out half of these if folks could just agree between application/vc+json and application/vc+ld+json (the latter being preferred)... and this is why I haven't raised this issue yet. We can always do this later if double-clicking on a file on a desktop ends up being a thing when it comes to Verifiable Credentials / Verifiable Presentations. With respect to protocols that pass this data around, the protocol is most likely going to expect a particular thing and won't need a MIME Type beyond application/json or application/ld+json.

[msporny]

If we can come to agreement about what we'd like the MIME type to be, I will start the registration process.

Also, please don't start the registration process until the WG decides we want a MIME Type. The typical process is you put in a section wrt. IANA Registration in the W3C spec and the registration is kicked off when we go to PR/REC:

https://www.w3.org/TR/json-ld11/#iana-considerations

You also need to type up quite a bit... need to understand and define MIME Type parameters. For example, here's the registration for JSON-LD:

https://www.iana.org/assignments/media-types/application/ld+json

[jonnycrunch]

application/json would be preferred.

[dmitrizagidulin]

@jonnycrunch

application/json would be preferred.

Can I ask - why preferred?

[brentzundel]

Decision at Barcelona F2F: This is a CR-blocker (open topic)

[pmcb55]

I think this blog entry offers fantastic guidance on this question: https://ruben.verborgh.org/articles/fine-grained-content-negotiation/ My suggestion: kept the existing standard MIME type of 'application/ld+json', and propose a single profile link relation type (https://tools.ietf.org/rfc/rfc6906) to mark resources as being 'verifiable credentials'.

[dmitrizagidulin]

To clarify, the reason we would like a MIME type are the following use cases:

• Content negotiation help during HTTP requests
• Application binding ON THE DESKTOP. A user wants to double-click on a VC and have it open in the right application in the OS. Requires mapping of MIME Type to file extension.
• Application binding IN BROWSER or mobile OS: User clicks on a link, and the browser opens it in the right application or extension.
• Email client UI: A user sends a VC as an email attachment, and have the email client display it in the right way.

[brentzundel]

Decision at F2F in Barcelona: This would be really nice, but must be deferred. Requiring it before CR may be hazardous.

[jonnycrunch]

@dmitrizagidulin

Can I ask - why preferred?

as we discussed in Barcelona the application/vc+json would imply JSON-LD as the current vc-data-model clearly states MUST use an @context attribute and that value MUST be an array of URI. And the way that it is realized implies JSON-LD and would thus nullify other approaches (mine and JWTs) for the reasons stated in our face2face. At present, I think that it is premature to unnecessarily and/or unknowingly constrain the implementers to one JSON data model and one specific approach towards semantic interoperability. I really really like JSON-LD, but have reservations for how it is applied in VCs. JWTs and my IPLD approach to VCs are compatible with application/json. As we discussed, there IS a heavy lift for the test-suite and/or implementors to validate the JSON with some elaborate transforms (JWT to JSON to JSON and/or my IPLD approach, etc). As this spec matures we can better split hairs. Myself, I'm skating towards application/vc+ipld+cbor as our solution which is why I suggested IPLD should be a first class citizen to JSON and JWTs (see the body of my PR: https://github.com/w3c/vc-data-model/pull/261 not just the comments).

After more thought, my pull request attempts to show IPLD as being serializable to JSON and thus compatible with JSON-LD as you can layer JSON-LD on top of IPLD, however, under the hood it is CBOR. So, I really should make the case that CBOR should be a valid syntax for VCs to better make my point. (I will be updating my PR to reflect this)

Therefore, If application/vc implies JSON-LD, as defined in the spec, then we have a disconnect and have covertly forced implementor into using JSON-LD and other syntaxes are potentially not compatible. But these are early days and need to build my case for CBOR, for reasons that application/ipld is not an official MIME type, etc. Under the hood, my IPID DID spec using CBOR (as in dag-cbor) and the signatures (aka proofs) are on the CBOR byte array, not the JSON (which is non-deterministic on the order unlike CBOR). However, when requested from the IPFS gateway an IPLD object serializes to an application/json interpretation of the CBOR. I think these nuances will become more obvious when we get to validating the signatures generated from our different approaches.

For this reason, I can work with application/json for now.

In the future we can have different clearly defined solutions based on the syntaxes.

For instance,

We agreed that @context is required. Different MIME types can handle this with different approaches. When using JSON-LD you have application/vc+ld+json and would have an array of URL as the value. When using IPLD you have application/vc+ipld+cbor and would have an IPLD object that defines the semantics:

for example:

{ "@context" : 
    { "/" : "zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq" }
}

and for JWT you would have application/vc+jwt and default implied mappings of the attributes are clearly defined during the encodings and decoding as specified in the vc-data-model.

[jonnycrunch]

more thoughts on the IPLD MIME types:

https://github.com/ipfs/ipfs/issues/36

in essence, JSON-LD is completely compatible on top of IPLD, but IPLD is not completely backwards compatible with JSON-LD. What is missing for backwards compatibility is to register ipld: as a valid scheme for `{ "/" : "<cid>" }'. see: https://github.com/ipld/specs/issues/98

[jonnycrunch]

also, I can image we will support a application/vc+ipld+json format that serializes the cbor to deterministic JSON string representation and thus my point that application/vc which implies JSON-LD still holds given the spec constrains the implements to JSON-LD which is not your intention for other JSON sub-types. I think that it is fine to constrain application/vc+ld+json to use an array of URLs, but mappings for application/json+jwt can be spelled out in the spec and the @context can be dropped in the JWT.

Then application/vc+ipld+json will allow for:

{ "@context" : 
    { "/" : "zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq" }
}

When transforming between the different MIME types to a common format (i.e. application/json) then the encodings are fetched and attached with valid full URL using http: or ipld: schemes.

so the above transformed from application/vc+ipld+json to application/json would be:

{ "@context" : "ipld:zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq"

or an array of ipld object:

{ "@context" : [

    { "/" : "zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq" }, 
    { "/" : "zdpuAt4xfAPaH8nx2qcZyFeXmYmHQFS4xYyHEBsAam9dggJ44" }
 ]
}

or application/vc+json when we are there.

[BigBlueHat]

MIME media type declaration concerns could be considered as "solved" for the data model spec--which signals it's using existing processing models (perhaps profiled) for JSON-LD and JSON. Consequently, it seems like a protocol concern.

We want people to be able to double-click the files and have the correct handler load.

Creation of a protocol (even an "open file" protocol/process) would be the moment to introduce a new media type.

Given that this is a data model is currently serialize-able into two existing media types, the most I can see this specification providing is a profile parameter for one or both of the base media types (application/ld+json and application/json). There's a registry for those if that is the approach taken: https://www.iana.org/assignments/profile-uris/profile-uris.xhtml

[pmcb55]

Hi @jonnycrunch (and @dmitrizagidulin @msporny) - can I ask if you guys got to read the article I mentioned above (https://ruben.verborgh.org/articles/fine-grained-content-negotiation/)? The ideas there (i.e. that trying to encode multiple dimensions into a single MIME type, like application/vc+ipld+json for instance, is a bad idea!) contain a far better alternative that is being formally standardized by the W3C: https://www.w3.org/TR/dx-prof-conneg/ I'd love to hear the groups thoughts on this alternative (and in my opinion much cleaner and sustainable) approach.

[TallTed]

Many good points in Ruben's article, @pmcb55, all of which should be considered when the protocol discussion @BigBlueHat alludes to commences, and, I think, not before.

[pmcb55]

@TallTed @BigBlueHat Yep - totally agree with you both. I just hope this specific Github issue can be referenced if/when MIME types come up in that protocol discussion (just to prevent the above thoughts being lost, or needing to be 'rediscovered').

[msporny]

Conversation around this happening here: https://mailarchive.ietf.org/arch/msg/media-types/L0YVPU1zUIlECS8_4ScB5H62GNI/

[kdenhartog]

We discussed this on the maintenance call. Because this is a registration item it would need to be handled in V2.

[iherman]

The issue was discussed in a meeting on 2021-08-11

• no resolutions were taken

View the transcript

4.4. need MIME type guidance (issue vc-data-model#421)

See github issue #421.

Wayne Chang: this issue asks for mime types to be better described in the data model

Manu Sporny: this is V2 because it is a formal registration that would require a full group

[Sakurann]

Now that we are moving representations out of the core data model, it makes less sense to have a MIME type for a core data model. Suggest we leave this to each representation deliverable

[msporny]

Now that we are moving representations out of the core data model, it makes less sense to have a MIME type for a core data model. Suggest we leave this to each representation deliverable

We're moving the way VCs are secured out of the core data model, not the representations (I expect the latter to be a point of debate in the group). At the very least, we have two media types now: "application/vc+ld+json" and "application/vc+json" with the possibility for more, such as "application/vc+json+jwt" defined in the VC-JWT specification.

Fundamentally, we'll still need MIME type guidance in the specification, which is being driven by this work: https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/01/

[Sakurann]

what is the use case when only VC(VP) is returned in HTTP Response, so that these content-types will be used?

Why current content types express how VC is serialized as opposed to how VC is signed? Won't we need something like "application/vc+ld+json+ldp" and "application/vc+ld+json+jwt" too? (not sure ldp is a suitable abbreviation anymore)

[msporny]

what is the use case when only VC(VP) is returned in HTTP Response, so that these content-types will be used?

The VC API is one that delivers bare VPs, media types for files on disk (VCs/VPs) is another use case.

Why current content types express how VC is serialized as opposed to how VC is signed?

At present, there are no content types for VCs (we didn't define them in v1.0 because of the structured mediatypes problem, which we are now resolving in IETF).

Won't we need something like "application/vc+ld+json+ldp" and "application/vc+ld+json+jwt" too? (not sure ldp is a suitable abbreviation anymore)

We won't need a separate media type for Data Integrity protected VCs, it'll just be "application/vc+ld+json", or "application/vc+json" would work there as well (though it's arguable if it /should/ work).

Since JWTs are an opaque data format and have no typing mechanism, we'll probably need "application/vc+json+jwt" (again, maybe... it's debatable).

Hope that helps.

[msporny]

This work is affected by the IETF Media Types with Multiple Suffixes specification: https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/

[iherman]

The issue was discussed in a meeting on 2022-08-10

• no resolutions were taken

View the transcript

4.10. Define v2 context (issue vc-data-model#421)

See github issue vc-data-model#421.

Kristina Yasuda: Recent comments seem to make it clear we want to keep the issue open..
… This is about MIME types.

Manu Sporny: We kicked off an IETF work item to address this issue. This was kicked off by DID WG. There is active work here..
… This group should review if this meets this group's requirements.

Ivan Herman: See the relevant IETF work item.

Kristina Yasuda: Let's keep this issue scoped to the IETF discussion, then let's create another issue to discuss what MIME types we need?.

Manu Sporny: Maybe this issue is "define a MIME type for VC syntaxes", and the "media type conversation" is a separate issue. We could do this either way.
… Maybe we edit this issue to say "define 1 or more media types for VCs". So we keep it as one issue and make this one concrete. The WG needs to define media type(s).

Orie Steele: +1 to defining media types..

Manu Sporny: And we link to the work happening in IETF.

Ivan Herman: When you have a W3C spec, then you can include the necessary MIME type document in the specification itself. It doesn't need a separate work submitted to the usual channels..

Kristina Yasuda: Removing the relevant tag.

Ted Thibodeau Jr.: I'm concerned about the agreement. W3C will create a lot of media types and not list them on the definitive IANA page. That's where you're supposed to list them..
… If you create a VC, then you find it in the W3C spec. But it should also be on the IANA page, since if you don't work with VCs per se, you want to look up the media type and learn about it. If it's not listed in IANA, that's problematic..

Ivan Herman: You misunderstood, it will be listed there..
… Normally you have to create a separate document with its own syntax and style, that is more work. Instead, that text has to be included in a specification. It still goes through the usual review and the list, but it's a shortcut for editors..

Kristina Yasuda: Brent should we go through issues labeled "discuss"?.

Brent Zundel: Agree.