I agree with Mike. This exercise seems to add confusion rather than clarity.
thx ..Tom (mobile) On Tue, Nov 28, 2023, 10:05 AM Michael Jones <[email protected]> wrote: > Orie, you wrote: > > > > TLDR; TallTed believes that the convention in the JWT BCP is not correct: > > https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing > > So instead of seeing: > > application/secevent+jwt > > We should be seeing: > > application/jwt; profile=secevent > > > > For what it's worth, the authors of the JWT BCP believed that the use of > application/*subtype*+jwt works well for explicit typing, and so put it > into the specification. The IETF-wide review and the IESG review supported > this decision. I don’t see grounds to revise it. > > > > I personally believe that adding media type parameters when using media > type names reduces interoperability. Code gets the string comparison for > media type names right and tends to screw up on media type parameters in > various ways because they’re largely unexpected. Rather than adding the > use of media type parameters, I would prefer that the registrations be > updated to prohibit their use. > > > > -- Mike > > > > -----Original Message----- > From: OAuth <[email protected]> On Behalf Of Carsten Bormann > Sent: Monday, November 27, 2023 7:32 AM > To: Orie Steele <[email protected]> > Cc: oauth <[email protected]>; IETF Media Types <[email protected]> > Subject: Re: [OAUTH-WG] Request to add a profile parameter to +jwt and > +sd-jwt > > > > On 2023-11-27, at 15:55, Orie Steele <[email protected]> wrote: > > > > > > application/jwt; profile=secevent > > > > > > This is a general form of the challenges associated with using multiple > structured suffixes with JWTs. > > > > Anything that reduces our need to extract semantics from complex nested > structured suffixes is good. > > > > Independent of which form is being used here, I’d like to raise the > specter of ossification: > > > > Will we be able to evolve the profile name (nested media type subtype) > once a subtype/profile is in wide use? > > (I think in the end we will exactly do that TLS 1.3 did: send fake TLS 1.2 > identification and do the recognition of TLS 1.3 on a higher level.) > > > > Grüße, Carsten > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7C%7C7dbe85583aa74167f5b608dbef5e1c2a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638366959703680014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FMVqVsRxxd7Y4hxEC2T5iSUB0wV84ASM5FQW8TYqRkY%3D&reserved=0 > <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
