[media-types] Re: [IANA #1443286] application/trust-ma rk-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]