Do VCs still need Media Types with Multiple Suffixes? about vc-data-model

[TallTed]

I maintain my position that application/sd-jwt should be considered akin to application/zip, and application/vc+ld+json should be a result (not the result; an application/sd-jwt may contain various other subtypes of application/json) of extracting the content of an application/sd-jwt just as text/plain or image/png or example/example might be the result of unzipping an application/zip.

ZIPs don't get subtyped based on their content; neither should SD-JWTs.

[selfissued]

As I wrote at https://mailarchive.ietf.org/arch/msg/oauth/vDitVdgDfL4ZXzPdvquoCj_fYbY/, I believe it would be better to update our registrations to prohibit the use of media type parameters, to increase the likelihood of interoperability.

[dlongley]

My understanding is that media type [multiple-]suffixes are for signalling subclasses (more restricted expressions of a flexible syntax) that do not have to be used or understood by more general consumers of the flexible syntax. By way of example:

For the media type: application/square+rectangle+shape, each of the following consumers could expect to parse / use data associated with it:

1. Square consumers
2. Rectangle consumers
3. Shape consumers

This is fundamentally different from a media type such as this (which I consider erroneous usage):

application/note+envelope+mailtruck

Whereby "Note consumers" and "Envelope consumers" would be unable to consume this payload -- and only "Mailtruck consumers" could.

In my view, using media type [multiple-]suffixes is not for use cases that involve wrapping a data format in another wrapper that changes its syntax / general structure, etc. (aka "an envelope").

[OR13]

Nothing needs multiple suffixes, they are hints for specific processors (such as browsers) to provide a better experience than downloading a file... that makes them a nice to have imo.

https://www.w3.org/TR/activitystreams-core/#media-type

application/activity+json; profile="https://www.w3.org/ns/activitystreams"
application/ld+json; profile="https://www.w3.org/ns/activitystreams"

application/vc this would be a media type for conformant documents? (compact JSON-LD).

application/vc+sd-jwt this would be a media type for a specific form of conformant document (SD-JWT secured JSON-LD payload.

[msporny]

I agree with @selfissued.

Implementers ignore media type parameters a non-trivial amount of the time. They are mauled by middle-boxes in unexpected ways (usually removed). We used them for JSON-LD, which was (IMHO) a mistake that optimized on the belief that implementers would get it right most of the time (they didn't). Use of media type parameters is always well intentioned by specification authors, and then botched by a non-trivial number of implementers.

I might be ok with saying that people can use them (but cringe at the possibility), and suggesting how to use them, but we shouldn't specify algorithms and write software that counts on their proper usage.

[msporny]

@jyasskin wrote:

multiple suffixes ... it sounds like that draft is having trouble getting to consensus over in the IETF.

I'm the (reluctant) Editor of that specification. It's taking longer than any of us would like, but we're down to one issue: whether or not all suffixes in a chain of structured suffixes need to be registered (via concrete specs), needs to be registered (but some can be a no-op), or not be registered (which received objections during IETF 118). The IETF MEDIAMAN Chair would like to take it to IETF WGLC before/during IETF 119.

Might it speed things up to use the application/vc and application/vc+sd-jwt media types instead, and avoid waiting for the MEDIAMAN WG to figure out multiple suffixes?

We don't have to wait for MEDIAMAN to figure out multiple suffixes. DID Core went to REC w/ this note: https://www.w3.org/TR/did-core/#application-did-ld-json ... we can do the same here. BUT, I expect we won't have to this time based on all of the effort that's gone into suffixes since DID Core v1.1.

The +ld+json bit of those media types isn't doing much work. It could tell a generic JSON or JSON-LD processor that they could give better debugging output by rendering in those formats, but they won't be able to parse the VC.

It's doing important work, namely:

1. Signalling to JSON environments that the format can be parsed, linted, highlighted, stored, retrieved, and utilized using general JSON tooling.
2. Signalling that RDF toolchains that understand JSON-LD can merge the information into knowledge graphs and other forms of RDF databases.
3. Providing the pathway for [application/vc+ld+cbor](https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jul/att-0004/Introduction_to_CBOR-LD.pdf), which is deployed in production today and expected to be standardized over the coming years at W3C.

All that said, I do acknowledge that we have a problem w/ application/vc+ld+json+sd-jwt ... namely that it seems like we're going to have to register +json+sd-jwt and +ld+json+sd-jwt to avoid objections from at least one of the Media Type maintainers. Exactly what we say for those registrations is still a bit up in the air... or we might just say "forget it!" and register application/vc+sd-jwt as an expression of the data model in VCDM that is secured using SD-JWT and not take advantage of structured suffixes (because we couldn't get consensus at IETF to do the easier thing and not have to register every structured suffix variation under the sun).

Do you find any of the arguments above compelling @jyasskin?

[jyasskin]

I don't mean to take a strong stance here; just wanted to make sure the WG still wants them.

On application/vc+ld+json+sd-jwt, does the +sd-jwt part imply the +json part, or could you have +somethingelse+sd-jwt? Reading https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html, I think the content does always have to be JSON. So maybe the media type should be application/vc+ld+sd-jwt.

[jyasskin]

Note that application/zip can contain multiple resources, while I believe application/sd-jwt can only contain one. application/gzip/+gzip or application/zstd/+zstd would be a better comparison (even though gzip can also technically also contain multiple subfiles; nobody uses it that way). I'm not taking a position on whether +gzip and +zstd were good ideas.

(+zip is also a registered structured suffix, but as far as I can tell, that suffix doesn't mean "a zip is extractable to get the format named before it"; it's "this format also happens to be usable as a .zip", like +json, +der, etc.)

[iherman]

The issue was discussed in a meeting on 2023-12-06

• no resolutions were taken

View the transcript

2.7. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)

See github issue vc-data-model#1364.

Orie Steele: I would suggest keeping this issue open. We need to know if our registration will be accepted or not.

Brent Zundel: I'm interpreting that as before CR.

Ted Thibodeau Jr.: There's nothing prohibiting making registrations with multiple suffixes. The question is about how those are going to be interpreted.

[iherman]

The issue was discussed in a meeting on 2023-12-13

• no resolutions were taken

View the transcript

2.5. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)

See github issue vc-data-model#1364.

Brent Zundel: do VCs still need media types with multiple suffixes.
… short answer is yes.
… comments on this? seems we are ready to close this issue.

Manu Sporny: I think we still need media types with multiple suffixes.
… the only thing that is in question now are the media types for the securing formats such as jose-cose.
… I think I agree with the existing media type registration requests.

Ted Thibodeau Jr.: yes, pretty strongly, application/sd-jwt.

Manu Sporny: this group will need to decide what media types to request.
… ted, please open your PR before the next IETF meeting.
… if we fail to get into last call again, everything will be very sad.

Dave Longley: +1 to Manu's position, I think Ted is right but relying on Ted.

Ted Thibodeau Jr.: doing my best to get it done this week.

Brent Zundel: any other IETF PRs we want to discuss?
… labeling pending close, we think we need what we currently request.