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
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 STEELEChief Technology Officerwww.transmute.industries
Best Regards,
Alexey
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
