Sending this one again, this time to [email protected] too, to hopefully at least broaden awareness that the explicit typing with media types in RFC8725 and draft-RFC8725bis isn't necessarily well regarded.
On Tue, Mar 3, 2026 at 2:56 PM Brian Campbell <[email protected]> wrote: > Darrel, > > I probably come to it from a different perspective but share some of the > discomfort with JWT typing having hitched itself to the media type wagon. > > The "JSON Web Token Best Current Practices" document, which > largely established the JWT explict typing thing, is undergoing an update > in the OAUTH WG. > > In one review comment, I did say that I am unconvinced the use of the > 'typ' JWT header with > media types has proven to be the best or even a good vehicle for explicit > typing. I did stop short of suggesting a change > https://mailarchive.ietf.org/arch/msg/oauth/ucYiMs1mWW1MRKtSbhfBcMtLdk4/ > but your comments here make me wonder if there'd be value in pushing on > that more? > > > > On Sat, Feb 21, 2026 at 12:55 PM Darrel Miller <[email protected]> wrote: > >> Hi Mike, >> >> By “no client can actually rely on it”. I am suggesting that the >> response content-type header of " >> application/trust-mark-status-response+jwt" is not sufficient for a >> recipient to treat the payload as >> "application/trust-mark-status-response+jwt". >> The specification says that the application must confirm the typ field >> before it can be processed as a "trust-mark-status-response+jwt". >> >> Also, the specification explicitly defines that the response to POST >> /federation_trust_mark_status_endpoint MUST be >> application/trust-mark-status-response+jwt. So I don't see how this media >> type is communicating any information that is not already known or >> discoverable elsewhere. The only role it seems to play, is allowing the >> client to conform to the ceremony of saying "when you POST to this >> endpoint, this media type must be returned, and that media type must match >> the value in the typ field". >> >> I understand that this situation is challenging because at some point in >> history there was a decision made to couple JWT types to media types. >> However, my objection to this registration is because there is no value >> here being provided by the media type and these very narrow use cases are >> not particularly healthy for the ecosystem . The real value to prevent JWT >> confusion is being provided by the identifier in the typ field, which >> happens to have been hitched to the media type wagon. >> >> Unfortunately for me, I see no wording in RFC 6838 that gives grounds for >> rejecting this based on it being an unnecessary registration. >> >> So, with my noted objection, I approve this media type. >> >> Darrel >> ------------------------------ >> *From:* Michael Jones <[email protected]> >> *Sent:* Saturday, February 21, 2026 1:16 PM >> *To:* Darrel Miller <[email protected]>; [email protected] < >> [email protected]> >> *Cc:* [email protected] <[email protected]> >> *Subject:* RE: [media-types] [IANA #1443286] >> application/trust-mark-status-response+jwt registration request >> >> >> Thanks for your reply, Darrel. >> >> >> >> I don’t know that you mean by “no client can actually rely on it”. >> Clients rely on it in the protocol response defined at >> *https://openid.net/specs/openid-federation-1_0.html#name-trust-mark-status-response >> <https://openid.net/specs/openid-federation-1_0.html#name-trust-mark-status-response>* >> (and >> other responses, such as the one defined at >> *https://openid.net/specs/openid-federation-1_0.html#name-successful-explicit-client- >> <https://openid.net/specs/openid-federation-1_0.html#name-successful-explicit-client->*, >> etc.). The “typ” value of the JWT MUST use the correct media type to >> prevent cross-JWT confusion. >> >> >> >> Cross-JWT confusion is described at >> *https://www.rfc-editor.org/rfc/rfc8725.html#name-cross-jwt-confusion >> <https://www.rfc-editor.org/rfc/rfc8725.html#name-cross-jwt-confusion>* and >> is prevented by using the “typ” header parameter with a media type specific >> to the kind of JWT, as described at >> *https://www.rfc-editor.org/rfc/rfc8725.html#use-typ >> <https://www.rfc-editor.org/rfc/rfc8725.html#use-typ>*. This media type >> enables following this practice from the JWT BCP. >> >> >> >> If all the different kind of JWTs used as “typ” header parameter values >> were the same, attackers would be able to succeed in using a JWT intended >> for one purpose for another purpose – the essence of Cross-JWT Confusion. >> So everyone using “application/openid-federation+jwt” wouldn’t do the >> trick to prevent the attack – just like everyone using “application/jwt” >> wouldn’t. >> >> >> >> Therefore, given that there are security reasons for the distinct media >> types and the requests are well-formed, I request that you complete this >> registration and that in the request “[media-types] [IANA #1443287] >> application/explicit-registration-response+jwt registration request”. >> >> >> >> Thank you, >> >> -- Mike >> >> >> >> *From:* Darrel Miller <[email protected]> >> *Sent:* Saturday, February 21, 2026 9:20 AM >> *To:* Michael Jones <[email protected]>; >> [email protected] >> *Cc:* [email protected] >> *Subject:* Re: [media-types] [IANA #1443286] >> application/trust-mark-status-response+jwt registration request >> >> >> >> Hi Mike, >> >> >> >> Apologies for the slow response and missing your deadline. While >> everything in the registration is technically correct it seems like a >> redundant registration. >> >> >> >> According to 8.4.1, effectively says that when you POST to this specific >> endpoint the response MUST be exactly this JWT that has this `typ` value. >> So registering a mediatype seems to be adding no value because no client >> can actually rely on it. >> >> >> >> It is not clear to me why all 8 media types are not simply something like >> application/openid-federation+jwt >> >> >> >> What am I missing? >> >> >> >> Darrel >> >> >> ------------------------------ >> >> *From:* Michael Jones <*[email protected] >> <[email protected]>*> >> *Sent:* Friday, February 13, 2026 8:24 AM >> *To:* *[email protected] <[email protected]>* >> <*[email protected] >> <[email protected]>*> >> *Cc:* *[email protected] <[email protected]>* <*[email protected] >> <[email protected]>*>; Darrel Miller <*[email protected] >> <[email protected]>*> >> *Subject:* RE: [media-types] [IANA #1443286] >> application/trust-mark-status-response+jwt registration request >> >> >> >> Hi Darrel, >> >> >> >> The *vote to approve the final OpenID Federation specification >> <https://openid.net/foundation/members/polls/397>* ends on Tuesday >> (February 17, 2026). It would be ideal if you could approve this before >> then, or if necessary, tell us what we need to fix in the specification for >> it to be approved. >> >> >> >> Thank you, >> >> -- Mike >> >> >> >> -----Original Message----- >> From: Amanda Baber via RT <*[email protected] >> <[email protected]>*> >> Sent: Thursday, February 12, 2026 8:04 PM >> Cc: *[email protected] <[email protected]>*; *[email protected] >> <[email protected]>* >> Subject: [media-types] [IANA #1443286] >> application/trust-mark-status-response+jwt registration request >> >> >> >> Hi Darrel, >> >> >> >> Sending a reminder for this OpenID request from February 4th. #1 of 2. >> >> >> >> thanks, >> >> Amanda >> >> >> >> On Wed Feb 04 18:38:05 2026, amanda.baber wrote: >> >> > Hi Darrel, >> >> > >> >> > Can you review this request from OpenID by February 18th? This is #1 >> >> > of 2. >> >> > >> >> > thanks, >> >> > Amanda >> >> > >> >> > ===== >> >> > >> >> > Name: Michael B Jones >> >> > >> >> > Email: *[email protected] <[email protected]>* >> >> > >> >> > Media type name: application >> >> > >> >> > Media subtype name: trust-mark-status-response+jwt >> >> > >> >> > Required parameters: n/a >> >> > >> >> > Optional parameters: n/a >> >> > >> >> > Encoding considerations: binary >> >> > >> >> > A Trust Mark Status Response is a signed JWT; JWT values are encoded >> >> > as a series of base64url-encoded values (some of which may be the >> >> > empty string) separated by period ('.') characters. >> >> > >> >> > Security considerations: See Section 18 of >> >> > *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopeni >> <https://openi/>* >> >> > d.net%2Fspecs%2Fopenid-federation-1_0.html&data=05%7C02%7C%7Ca74ce836b >> >> > 0cb432a99bf08de6a698e13%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 >> >> > 39065198778322115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi >> >> > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >> >> > C%7C%7C&sdata=6TOXHoSo0udO%2BuCsJb1IOrN%2FlMSd2gsMxdqDdEznOfA%3D&reser >> >> > ved=0 >> >> > >> >> > Interoperability considerations: n/a >> >> > >> >> > Published specification: Section 15.7 of >> >> > *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopeni >> <https://openi/>* >> >> > d.net%2Fspecs%2Fopenid-federation-1_0.html&data=05%7C02%7C%7Ca74ce836b >> >> > 0cb432a99bf08de6a698e13%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 >> >> > 39065198778360842%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi >> >> > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >> >> > C%7C%7C&sdata=Ior6JHJi%2BozTMpZJH0Y%2FMLzJ%2BjTksAYvypohrGIhlhM%3D&res >> >> > erved=0 >> >> > >> >> > Applications which use this media: Applications that use >> >> > *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopeni >> <https://openi/>* >> >> > d.net%2Fspecs%2Fopenid-federation-1_0.html&data=05%7C02%7C%7Ca74ce836b >> >> > 0cb432a99bf08de6a698e13%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 >> >> > 39065198778391345%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi >> >> > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >> >> > C%7C%7C&sdata=MoU7zwKJaaY1%2B9iaBeYVsxd6whw%2FlcaL17e3gQ9juZs%3D&reser >> >> > ved=0 >> >> > >> >> > Fragment identifier considerations: n/a >> >> > >> >> > Restrictions on usage: none >> >> > >> >> > Provisional registration? (standards tree only): No >> >> > >> >> > Additional information: >> >> > >> >> > 1. Deprecated alias names for this type: N/A 2. Magic number(s): N/A >> >> > 3. File extension(s): N/A 4. Macintosh file type code: N/A 5. Object >> >> > Identifiers: N/A >> >> > >> >> > General Comments: The OpenID Federation 1.0 specification is in the >> >> > 14-day OpenID Foundation-wide voting period for approval as an OpenID >> >> > Final Specification. It would be ideal for the registration to occur >> >> > before the specification becomes final on February 17, 2026. >> >> > >> >> > Person to contact for further information: >> >> > >> >> > 1. Name: Michael B Jones >> >> > 2. Email: *[email protected] <[email protected]>* >> >> > >> >> > Intended usage: COMMON >> >> > >> >> > Author/Change controller: OpenID Foundation Artifact Binding Working >> >> > Group - *[email protected] >> <[email protected]>* >> >> >> >> _______________________________________________ >> >> media-types mailing list -- *[email protected] <[email protected]>* To >> unsubscribe send an email to *[email protected] >> <[email protected]>* >> _______________________________________________ >> media-types mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
