Inline: On Thu, Jul 20, 2023 at 11:42 AM Manu Sporny <[email protected]> wrote:
> On Thu, Jul 20, 2023 at 12:07 PM Brent Zundel > <[email protected]> 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>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
