[media-types] Re: [IANA #1443286] application/trust-ma rk-status-response+jwt registration request

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 (and other responses, such as the one defined at 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 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.  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]<mailto:[email protected]>>
Sent: Friday, February 13, 2026 8:24 AM
To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Darrel Miller <[email protected]<mailto:[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]<mailto:[email protected]>>
Sent: Thursday, February 12, 2026 8:04 PM
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>

>

> Intended usage: COMMON

>

> Author/Change controller: OpenID Foundation Artifact Binding Working

> Group - [email protected]<mailto:[email protected]>



_______________________________________________

media-types mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]