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]<mailto:[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]<mailto:[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
