Add "Media Type Extensions" category.

[msporny]

This PR adds a "Media Type Extensions" section, and an example of it's usage by adding the application/vc+jwt media type to the section. The result is a section that looks like this in the vc-specs-dir:

This is an attempt to partially implement the resolution made at the 2023 Miami VCWG F2F Meeting and the tracking issue in vc-data-model: w3c/vc-data-model#1048

---

Preview | Diff

[TallTed]

How does someone know that they need to add a "Media Type Extension"?

How does one go about doing this?

If added to this section/document or a W3C Registry or something else, do they also need to request to be registered with IANA?

How does the draft section satisfy the requirements that will be described by the answers to the questions above?

[msporny]

How does someone know that they need to add a "Media Type Extension"?

They feel it... in their bones. :P

Maybe we should say something about this in this section?

https://w3c.github.io/vc-data-model/#media-types

How does one go about doing this?

Same way they add any other specification entry to the vc-specs-dir:

https://github.com/w3c/vc-specs-dir#adding-new-entries-to-the-directory

If added to this section/document or a W3C Registry or something else, do they also need to request to be registered with IANA?

While it's not required, it would be a good idea to do so.

How does the draft section satisfy the requirements that will be described by the answers to the questions above?

We could add some guidance at the top of that section... or we could point to the media types section in vc-data-model. I don't have any strong preferences here and would like others reviewing the PR to weigh in w/ some stronger opinions to indicate a desired direction.

[awoie]

lgtm

[OR13]

It would be good to include the base media type here as well.

[m00sey]

Can we add a "tranformationDirectionality" field to capture the uni/bidirectional nature of the media type transformation?

[msporny]

I was thinking that people would note that in the description, though, you're right -- if specifying the directionality is a requirement for VC-associated media types, then perhaps it should be a field.

I'd prefer if we got to consensus on exactly what these "transformation rules" need to do/say about directionality before adding that field to the registration requirements.

[OR13]

Let us not add another property, let us use the convention of commenting on this in the description.

The spec that is referenced should do the work.

[OR13]

The less we say about "transformation rules" the better.

The important part is that the output conform to application/vc+ld+json... how you get there is the business of the spec that is registered here. The VCWG's business is in ensuring that the output matches the expected media type.

Also, as I have said elsewhere, there can be more than 1 mapping... this is not our change to make 3 rings for the elves.

I also don't want the working group dragged into "reviewing mappings"... that is the entire point of the day 3 resolution, to shift that burden to the implementer, and give them a clear way to tell if they did a good job (does the output of your mapping look like application/vc+ld+json).

[OR13]

This PR is so stale it no longer reflects the working group documents, I have suggested changes to correct it.

[m00sey]

I think it is worth relating this to w3c/vc-data-model#1048 and having the media types section direct people to here as well, I'll be opening a pr with hopefully text doing that.

[OR13]

This PR seems premature, given the requirements for mappings floating around:

• Media types other than vc+ld+json vc-data-model#1048

I suggest we get consensus on requirements before proceeding.

[TallTed]

I am more than a little concerned that this feels like a competitor to IANA registration, with little to no gatekeeping, especially as compared to IANA.

[iherman]

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

• no resolutions were taken

View the transcript

3.2. Add "Media Type Extensions" category. (pr vc-specs-dir#14)

See github pull request vc-specs-dir#14.

Manu Sporny: VC Specifications dir. PR for media extension vocab, and has had much conversation. An attemp to figure out ADCD, JWT and Gordian etc.
… the VC Spec Dir needs guidance. Should it be a note or registry thing or what for another 3 months and publish to PR space. Guidance requested.

Brent Zundel: so noted and will be brought up.

[iherman]

The issue was discussed in a meeting on 2023-04-19

• no resolutions were taken

View the transcript

3.1. Add "Media Type Extensions" category. (pr vc-specs-dir#14)

See github pull request vc-specs-dir#14.

Manu Sporny: Sure, the others are moving along, aren't super important. There's one -- let me call that out. There's a media types extension.
… The VC specs dir has this media types category based on the resolution from the F2F and there's discussion on this PR and issues linked to it. There's discussion on the transformation rules, what they should be, where they are specified, how are they testable, should we use JSON schema, etc. lots of discussion happening there.
… If you care about different media types that can be translated into the base media type you should look at that.

Orie Steele: I think it would be nice to specify normative guidance all registrations in the vc specs dir, in the core data model TR, and that guidance would be relevant to the reserved property table and the media types debate.

Manu Sporny: That's the only one that really jumps out at me.
… Then the thing that mentions me -- the VC-JWT spec and taking a look at it before it goes out to FPWD in a non-blocking way.
… It's on its way but people should take a look at it.

[OR13]

I suggest the PR be closed

[iherman]

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

• no resolutions were taken

View the transcript

1.7. Add "Media Type Extensions" category. (pr vc-specs-dir#14)

See github pull request vc-specs-dir#14.

Manu Sporny: there is 1 pr to add a media types extensions category.
… we don't plan on merging this, or closing it, until we discuss other media types.
… and transformations.

joe: i think the notion of the directory, is that any related specs can go there... don't understand why its blocked.

Manu Sporny: you are correct, the vc specs dir can have anything you want.
… we were contemplating adding a media type section, for other people to register transformations...
… we could put transformations in this vc specs dir.
… media types are not RDF predicates or types, so we don't understand how to support them.

joe: seems like we will have media types to related to vcs and schema.

Kristina Yasuda: no open PRs for https://github.com/w3c/vc-di-eddsa/pulls.

joe: there are 4 open PRs for status lists.

[Sakurann]

w3c/vc-jose-cose#88 removes vc+jwt from the JWT-VC spec, so it does not have to be registered.

[msporny]

@Sakurann wrote:

w3c/vc-jwt#88 removes vc+jwt from the JWT-VC spec, so it does not have to be registered.

I changed the PR to register application/vc+ld+json to demonstrate the feature, which is less controversial.

[Sakurann]

you do not need to register application/vc+ld+json, it's in VCDM and the only one usable with data integrity of JWT-VC specs. we do not need media types registry itself

[OR13]

This PR is now blocking our ability to create clarity around :

vc+ld+jwt vs vc+jwt.

This PR should be merged, but expect the entry for vc-jwt to change to IETF.

[OR13]

@msporny please apply the changes suggested.

@Sakurann please review the PR again.

[msporny]

@msporny please apply the changes suggested.

Done.

[Sakurann]

application/vc+ld+json+jwt is not used anywhere in VCDM 2.0 nor vc-jose-cose, which uses application/vc+ld+json and application/vc+ld+jwt.

[TallTed]

@Sakurann -- Multiple threads of discussion about media types have split things. Conclusion in one of those other threads was that application/vc+ld+json+jwt is more in keeping with current and proposed future media type construction than application/vc+ld+jwt, so the former is currently meant to replace all instances of the latter, here and elsewhere.

[OR13]

@Sakurann you are correct that there is a lot of cleanup that would need to be done, after this PR is merged.

application/vc+ld+json is used in the core data model... the proposal is to have vc-jose-cose use application/vc+ld+json+jwt and probably do something similar for sd-jwt, like application/vc+ld+json+sd-jwt and of course, should we register a JSON serialization for JWT or SD-JWT, you would also see:

application/vc+ld+json+jwt+json and / or application/vc+ld+json+sd-jwt+json ...

We would also expect application/vc+ld+json+cose for COSE Sign1 secured payloads.

[Sakurann]

there already seems to be reluctance towards two structured suffixes in IETF and using three seems to make it acceptable even harder (also for the implementers who are mostly used to one structured suffixes).

having said that, there seems to be an agreement on vc+ld+jwt+json.... so not blocking this. (I won't explicitly approve, but feel free to dismiss my request for changes).

.......application/vc+ld+json+jwt+json and / or application/vc+ld+json+sd-jwt+json does not make much sense to me......

[iherman]

The issue was discussed in a meeting on 2023-08-09

• no resolutions were taken

View the transcript

2.5. Refer to VC-SPECS-DIR for proof types. (pr vc-data-model#1212)

See github pull request vc-data-model#1212.

Manu Sporny: PR 1212 examples of securing mechanisms in spec. Point to specifications or directory? Need PR about media types?

Orie Steele: VCs with some securing mechanisms, with DI proofs; two specs; or media types; This or that language in DM spec.
… merge media types, refer to them consistently.

Joe Andrieu: this establishes related specs into a privileged position...

Orie Steele: +1 on should to MAY.

Manu Sporny: +1 on SHOULD to MAY conversion.

Ivan Herman: +1 to MAY.

Manu Sporny: securing mechanisms we have vetted here and those not. Anyone can add to specs dir. No review...

Michael Jones: I want XML DSIG.

Manu Sporny: very dangerous thing; any mechanism...

Orie Steele: +1 JoeAndrieu.

Joe Andrieu: I think anything does go; people can come up with new crypto; a directory is okay; our mechanisms are published as recs.

Sebastian Crane: be careful, don't devalue our (WG) opinion.

Kristina Yasuda: safely change to MAY...

Manu Sporny: we don't say what has/hasn't been vetted in registry? The VC DM doesn't say what has been vetted.
… how should we refer to securing mechanisms we have been working on?

Orie Steele: I suggested a concrete change here: https://github.com/w3c/vc-data-model/pull/1212/files#r1279836059.

Manu Sporny: what sections/where to put?

Orie Steele: if media types is merge is will be obvious;.

See github pull request vc-specs-dir#14.

Orie Steele: +1 manu.

Manu Sporny: blocking on Kristina PR 14; create media type in specs dir; then merge.

Orie Steele: I can edit "register to list".

Gabe Cohen: directister.

Joe Andrieu: avoid that directory is a registry.

Ted Thibodeau Jr.: Sorry, I'm slow, I have to re-review most recent changes in #14.

See github issue vc-specs-dir#27.

[msporny]

Noting that @Sakurann unblocked this PR over here in this comment: w3c/vc-data-model#1212 (comment)

[msporny]

Substantive, multiple reviews, changes requested and made, no remaining objections, merging.