ya know - there was a time when a standard could have a conformance test and then the implementations worked together. Now standards are just wishful thinking. Something MIGHT work, or might not. interop was a feature of a standard. Now the standard is wishful thinking and interop profile comes after the std is published. (maybe) ..tom
On Tue, Nov 28, 2023 at 11:15 AM David Waite <[email protected]> wrote: > 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 <[email protected]> > 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 <[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 > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
