Re: [jose] [EXT] Re: [COSE] Multiple Suffixes with JOSE and COSE media types

[Orie Steele <[e-mail]>]

Inline:

On Thu, Jul 20, 2023 at 11:42 AM Manu Sporny <[e-mail]>
wrote:

> On Thu, Jul 20, 2023 at 12:07 PM Brent Zundel
> <[e-mail]> wrote:
> > So you don't need to register weird and useless stuff like +ld+jwt, or
> +json+jwt if you don't have a need to use them by themselves... If that
> changes in the future and someone really needs +ld+jwt... They can claim
> it, by writing a specification and getting it to RFC.
> >
> > If the draft says this explicitly the problem with suffixes seems solved.
> >
> > Is it possible to get this language in?
>
> Yes, as long as the various WGs agree with the change.
>
> I'll note that "application/vc+ld+jwt" would set a bad precedent as
> both "application/vc" and "application/vc+ld" don't exist -- and
> shouldn't exist as both are abstract data models (not
> serializations)... they are only realized when serialized to
> "application/vc+ld+json". Anyone attempting to register them needs to
> involve all of the communities that that particular discussion
> impacts.
>
>
Yes, grateful for the feedback we have gotten from COSE and JOSE on this
topic.


> Suggestions to register "application/vc+ld+jwt" are problematic
>

I agree they are problematic...
but the problem is in the multiple suffixes draft, not the RFCs that
registered `+jwt`...
because of how time flows in one direction sadly.


> because they seem to presume that a downstream processor might know
> that when processing "application/vc+ld+jwt" as "+jwt", that handing
> off "application/vc+ld" further down the processing chain doesn't make
> sense and that they'd have to "fix up" the media type to
> "application/vc+ld+json" before sending it on for further
> processing...


I agree with this, additional language will clarify for any suffix that
includes assumptions regarding other media types:

`+jwt` secures `application/json` (already a registered structured suffix)

`+cwt` secures `application/cbor` ( registration requests exist...
https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-02.html#section-6.1
 )

`+cose` secures an envelope that is `application/cbor` and a payload of
type `content_type` (
https://github.com/anima-wg/constrained-voucher/issues/264 )

`+jose` secures an envelope that is `application/json` and a payload of
type `cty` (AFAIK, nobody is planning to register this as of right now).

You might consider these last 2 special cases of multipart content types...
when their headers include `content_type` or `cty`.

https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.6

which they'd need special knowledge to do (and anything
> just processing as a +jwt wouldn't have that specialized knowledge, in
> many cases).
>
That said, we should leave that discussion up to the WG that's
> registering the media type as long as it doesn't have a negative
> impact on the rest of the media type ecosystem (as long as it isn't
> setting a bad/dangerous precedent). We should probably ask them to
> explain why it's safe to do what they're doing and how systems just
> looking at the media type would be able to determine how to do
> structured suffix processing by just looking at the media type.


That's what we are doing right now?

COSE and JOSE lists are on this thread.


> In the
> end, it might just end up negatively impacting the community that
> chose the media type (that presumes a particular encoding associated
> with another registered media) in the first place.
>
>
Yes this is my concern for +jwt... it presumes +json.


> I suggest that the right thing to do here is probably require
> "+json+jwt"... but understand that is probably not going to be
> acceptable to the JWT community given that they've already registered
> a number of media types that don't fit that pattern.


Yes, I agree that this is the concern that needs clarification.


> They might need
> to include language on "equivalent processing" when it comes to the
> end product of "+jwt" structured suffix processing... which could be
> "treat it as application/json even though +json doesn't exist anywhere
> in the media type" or "you can safely assume a +json at the end of the
> decoded media type and process accordingly if you want to process
> using the structured suffix rules".
>

Yes exactly this... but with a few extra issues:

1. header and payload are potentially both relevant to +jwt considering
them both to be +json implicitly (so not just payload).
2. Same issues apply to +cwt
3. Is decoding the expected processing for a JWT? or is "verifying" the
expected processing?... does this interact with 1 and 2 consistently.



>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>