Re: [OAUTH-WG] Request to add a profile parameter to +jwt and +sd-jwt

[David Waite]

Media type parameters are useful for subtypes that add a multitude of expansion options, such as multimedia formats with a multitude of codecs, encoding options, and profiles to define feature sets.  The best usages of them I’ve seen is supplemental.  A baseline JWT isn’t really able to be customized in that way; even though it has defined claim names and meanings there conventions and considerations expected to be defined by a particular application of JWT Secevents or a JWT credential might define parameterization. For example, a credential might describe itself as having particular types/profiles of claims about a subject, such as being usable as a driving license and as a primary government-issued identification.  -DW On Nov 28, 2023, at 1:24 PM, Tom Jones <thomasclinganjo...@gmail.com> wrote:  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 <michael_b_jo...@hotmail.com> 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="">   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 <oauth-boun...@ietf.org> On Behalf Of Carsten Bormann Sent: Monday, November 27, 2023 7:32 AM To: Orie Steele <orie@transmute.industries> Cc: oauth <oauth@ietf.org>; IETF Media Types <media-ty...@ietf.org> Subject: Re: [OAUTH-WG] Request to add a profile parameter to +jwt and +sd-jwt   On 2023-11-27, at 15:55, Orie Steele <orie@transmute.industries> wrote: > > application/jwt; profile=""> > > 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 OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=""> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth