passing along some feedback from an engineer working on product in this area
---------- Forwarded message --------- From: Jamshid Khosravian <[email protected]> Date: Wed, Nov 19, 2025 at 12:24 PM Subject: Re: WG Last Call: draft-ietf-oauth-rfc7523bis-03 (Ends 2025-12-01) To: Brian Campbell <[email protected]> ... here we go (these are very minor): 1) In the Acknowledgements section, a "," is missing between "Brock Allen" and "John Bradley" 2) Regarding the `typ` header: Section 4 (Updates to RFC 7523) mentions the following: > Client authentication JWTs SHOULD be explicitly typed by using the typ > header parameter value client-authentication+jwt or another more specific > explicit type value defined by a specification profiling this specification. Section 5 (Updates to RFC 9126) mentions the following: > The introduction of strong typing for JWTs (using explicit typ values) > serves as a signal to distinguish between tokens produced in accordance > with specifications published prior to these updates and those > incorporating them. However, the primary security protection comes from the > tightened audience requirements. Since strong typing alone does not prevent > the attacks described in [private_key_jwt.Disclosure] and > [Audience.Injection], the use of explicit typing is suggestion for clients > enabling them to signal their intention of sending a JWT conforming to the > requirements herein. This approach balances security signaling with > practical deployment considerations, avoiding disruption to client > deployments that already conform to the tightened audience requirements but > have not yet adopted explicit typing. I was thinking that both sections of the doc should have both of the above statements, like: > Client authentication JWTs SHOULD be explicitly typed by using the typ > header parameter value client-authentication+jwt or another more specific > explicit type value defined by a specification profiling this specification. The introduction of strong typing for JWTs (using explicit typ values) > serves as a signal to distinguish between tokens produced in accordance > with specifications published prior to these updates and those > incorporating them. However, the primary security protection comes from the > tightened audience requirements. Since strong typing alone does not prevent > the attacks described in [private_key_jwt.Disclosure] and > [Audience.Injection], the use of explicit typing is suggestion for clients > enabling them to signal their intention of sending a JWT conforming to the > requirements herein. This approach balances security signaling with > practical deployment considerations, avoiding disruption to client > deployments that already conform to the tightened audience requirements but > have not yet adopted explicit typing. I might be totally off here. Jim On Wed, Nov 19, 2025 at 10:01 AM Brian Campbell <[email protected]> wrote: > ---------- Forwarded message --------- >>> From: Rifaat Shekh-Yusef via Datatracker <[email protected]> >>> Date: Mon, Nov 17, 2025 at 1:07 PM >>> Subject: WG Last Call: draft-ietf-oauth-rfc7523bis-03 (Ends 2025-12-01) >>> To: <[email protected]>, <[email protected]>, < >>> [email protected]> >>> >>> >>> >>> Subject: WG Last Call: draft-ietf-oauth-rfc7523bis-03 (Ends 2025-12-01) >>> >>> This message starts a 2-week WG Last Call for this document. >>> >>> Abstract: >>> This specification updates the requirements for audience values in >>> OAuth 2.0 Client Assertion Authentication and Assertion-based >>> Authorization Grants to address a security vulnerability identified >>> in the previous requirements for those audience values in multiple >>> OAuth 2.0 specifications. >>> >>> File can be retrieved from: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/ >>> >>> Please review and indicate your support or objection to proceed with the >>> publication of this document by replying to this email keeping >>> [email protected] >>> in copy. Objections should be motivated and suggestions to resolve them >>> are >>> highly appreciated. >>> >>> Authors, and WG participants in general, are reminded again of the >>> Intellectual Property Rights (IPR) disclosure obligations described in >>> BCP 79 >>> [1]. Appropriate IPR disclosures required for full conformance with the >>> provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware >>> of >>> any. Sanctions available for application to violators of IETF IPR Policy >>> can >>> be found at [3]. >>> >>> Thank you. >>> >>> [1] https://datatracker.ietf.org/doc/bcp78/ >>> [2] https://datatracker.ietf.org/doc/bcp79/ >>> [3] https://datatracker.ietf.org/doc/rfc6701/ >>> >>> -- _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]
