Re: [OAUTH-WG] [media-types] A Discussion of Multiple Suffixes

Hi,

To respond to one of the comments, registration of +sd-jwt is being requested in SD-JWT specification [1].

One comment, based on what I read above, I question the need for +ld and +ld+json, especially if +ld alone is not useful as Alexey pointed out. Instead, why registering one +ld-json media type is not sufficient?

Best,
Kristina

[1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#name-media-type-registration

________________________________
From: OAuth <oauth-bounces@ietf.org> on behalf of Alexey Melnikov <alexey.melnikov@isode.com>
Sent: Wednesday, November 22, 2023 3:33:43 AM
To: Orie Steele <orie@transmute.industries>; IETF Media Types <media-types@ietf.org>
Cc: W3C VC Working Group <public-vc-wg@w3.org>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [media-types] A Discussion of Multiple Suffixes

You don't often get email from alexey.melnikov@isode.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Hi Orie,

Thank you for the summary. Small corrections/clarifications below.

On 17/11/2023 18:03, Orie Steele wrote:
Alexey Melnikov and I had a chat about https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes<https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/>

I am sharing a summary of our discussion for the benefit of the list,
obviously this was just a discussion, and the media types working group will need to decide if or how to address any of these topics.

Regarding media type parameters, there should be no automatic inheritance.

There can be parameters that come from the top level, the subtype, the first structured suffix, or the last structured suffix.

An interesting parameter to consider would be "profile" which is common.

To clarify this a bit: At the moment only top level media types can specify parameters that apply to all subtypes (for example, text/* defines "charset").

So far there is no precedent for structured suffixes defining any parameters. If they do, this might create a conflict between top level media types and suffixes. So this needs a bit more thought.

There should be commentary on media type parameters, especially regarding cases where:

application/ld+json and application/json might both have chosen to register a common parameter name, such as "charset" or "profile".

+ld+json seems to be fine.

+jwt is confusing, since it's ambiguous which part, the header, payload, or signature will be passed along.

The validation rules here, are also problematic, in that they don't directly address this case:

https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-suffixes-06#section-2.5.1

We think the ambiguity here could be resolved, for JWT or CWT, the payload is the natural part that is relevant, and this aligns with the current intended use case within W3C.

For example, W3C specs current request registration of:

typ: application/vc+ld+json+sd-jwt
cty: application/vc+ld+json

Where decoding the payload produces application/vc+ld+json.

We should comment on this explicitly and warn implementers planning to use multiple suffixes with:

+jwt
+cwt
+sd-jwt
+jose
+cose

 ... or future similar structured suffixes...

To do their best to conform to this behavior, or explain why they deviated clearly, in their registration request.

An alternative recommendation might be to flatten the suffixes, when pairing with envelope content types, for example:

application/vc-ld-json+sd-jwt

This would also reduce unnecessary registrations, and simplify the guidance to designated experts regarding subtypes
with multiple structured suffixes that are each envelope formats (for example, +cwt  / +jwt)

When flattening is not an option, we recommend registering all suffixes, to ensure consistency, safety checks, and to be explicit over implicit.

For application/vc+ld+json+jwt and application/vc+ld+json+sd-jwt this would mean registering:

for application/vc:

- +ld
This doesn't need registering, because it is not meaningful by itself (only +ld+json is).

- +ld+json
This will need registering if application/vc+ld+json is to be allowed as a registration.

- +ld+json+jwt
- +json+jwt

- +ld+json+sd-jwt
- +json+sd-jwt
If +sd-jwt is not registered, it should also be registered, together with +json+sd-jwt.

Some of these registrations could be made with a warning, saying, do not use at this time.

On the section regarding adjudication of registrations on the same subtype, for the case where:

application/vc+ld+json is registered and the change controller is W3C.

https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-suffixes-06#section-2.3

We feel that the designated expert should have the ability to overrule the change controller, but that their decision should be appealable to IESG.

We should reach out to IESG regarding this proposal in case they have comments.

We think the common case will be that the designated expert will consult the change controller, and agree with their position,
in the case the designated expert feels there is some unreasonable position being taken by the change controller,
they should be allowed to overrule the change controller, and that decision should be appealable.
In the case of W3C, this would likely involve working with W3C Liaisons and the IAB as well.

In the case of other organizations, it might be helpful to be able to consult the IESG on the best course of action.

In the case that the designated expert agrees with the change controller, the registrant should seek a non conflicting subtype,
for example vc2, or a flattened subtype, for example vc-ld-json

We discussed content formats, and we don't think there are any issues with that registry, and the approach taken by multiple suffixes.

In summary, I think the main item remaining is the guidance on "skipping registrations" or "flattening" or "registering and recommending against use".

This was also the last comment on the topic during the session at IETF 118.

My personal preference would be to recommend the following to the group, regarding intermediate suffixes:

1. flatten whenever possible.
2. register and recommend against using.
3. skip registration and deploy without considering interpretation of intermediate suffixes.

Alexey, please correct anything I miscommunicated.

Regards,

OS

--


ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries/>

Best Regards,

Alexey