Closed jyasskin closed 8 months ago
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.
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.
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.
@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:
[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?
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
.
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.
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.)
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:
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").
The issue was discussed in a meeting on 2023-12-06
The issue was discussed in a meeting on 2023-12-13
closing per discussion during last call
Right now, the VC media types are
application/vc+ld+json
andapplication/vc+ld+json+sd-jwt
. This relies on https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-06.html to define what it means to have multiple+
s in a media type, and it sounds like that draft is having trouble getting to consensus over in the IETF.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. Back in VC 1.1, they might have been useful to distinguishapplication/vc+json
fromapplication/vc+ld+json
, but that's no longer relevant for VC 2.Might it speed things up to use the
application/vc
andapplication/vc+sd-jwt
media types instead, and avoid waiting for the MEDIAMAN WG to figure out multiple suffixes?