[OAUTH-WG] Re: Mahesh Jethanandani's Discuss on draft-ietf-oauth-rfc7523bis-10: (with DISCUSS and COMMENT)

[Brian Campbell <[e-mail]>]

Thank you Mahesh, the -11 update was just posted.

On Tue, Apr 28, 2026 at 2:43 PM Mahesh Jethanandani <[e-mail]>
wrote:

> Hi Brian,
>
> Thanks for addressing my DISCUSS. I am good with the change and will clear
> the DISCUSS when the update is posted.
>
> Just one follow-up comment.
>
> On Apr 28, 2026, at 1:31 PM, Brian Campbell <[e-mail]>
> wrote:
>
> Thanks Mahesh for the sharp review.
>
> The contradiction you point out in the DISCUSS is a result of a mistake
> on my part when making recent changes to some but not all of that text.
> Your guess and suggestion for the resolution are spot on. That change is in
> flight with change d03c7a2
> <https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/35/changes/d03c7a297d2fb45b61110d2213bd0a8cc9b84d0f>
> as part of this PR -11 for IESG evaluation feedback
> <https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/35>.
>
> Regarding the COMMENT, the actual risk with the authorization grant
> differs significantly in its manifestation, which is much less likely, and
> its mitigation, which the client covers by ensuring the audience of an
> assertion authorization grant (SAML or JWT) makes sense with respect to
> where it’s being sent. Minimizing breaking changes was just one part of the
> rational.  I've changed the wording in the Security Considerations a little
> bit with 3e9b69e
> <https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/35/changes/3e9b69ed26dfc5500651fea3da865b0cc3722ebf> as
> part of that same PR to try and avoid misstatements there.
>
>
> I still feel that the Security Consideration could go a little further to
> make apparent the residual risk. But it is a non-blocking comment, and I
> will let you and the authors decide whether you chose to make that change.
>
> Cheers.
>
>
> On Tue, Apr 28, 2026 at 11:58 AM Mahesh Jethanandani via Datatracker <
> [e-mail]> wrote:
>
>> Mahesh Jethanandani has entered the following ballot position for
>> draft-ietf-oauth-rfc7523bis-10: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I have but one DISCUSS and one COMMENT that I would like some discussion
>> around, and something that seems easy to fix.
>>
>> Section 4, paragraph 8
>> >       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.  The
>> >       use of explicit typing is REQUIRED for clients, enabling them to
>> >       signal their intention of sending a JWT conforming to the
>> >       requirements herein.  However, since strong typing alone does not
>> >       prevent the attacks described in [private_key_jwt.Disclosure] and
>> >       [Audience.Injection], it is NOT RECOMMENDED for servers to reject
>> >       JWTs that do not have explicit types.  Such rejection would cause
>> >       interoperability issues with clients that already conform to the
>> >       tightened audience requirements but have not yet adopted explicit
>> >       typing.  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.
>>
>> In this section, which updates Section 3.2 of RFC 7523, the following
>> two statements appear:
>>
>> - "Client authentication JWTs SHOULD be explicitly typed by using the typ
>>  header parameter value client-authentication+jwt..."
>>
>> - "The use of explicit typing is REQUIRED for clients, enabling them
>> to signal their intention of sending a JWT conforming to the requirements
>> herein."
>>
>> Per BCP 14 (RFC 2119/RFC 8174), SHOULD and REQUIRED (which is a synonym
>> for MUST) carry different normative weights. SHOULD means implementation
>> is recommended, but deviations are permissible for valid reasons;
>> REQUIRED/MUST means the implementation has no discretion. A client reading
>> this paragraph cannot determine whether it must include explicit typing or
>> merely should.
>>
>> The same contradiction appears identically in Section 5 (updating RFC
>> 9126).
>>
>> The resolution is straightforward: if the intent is SHOULD (recommended
>> but
>> not mandatory), remove the word "REQUIRED" from the explanatory prose and
>> replace it with language like "The use of explicit typing enables clients
>> to
>> signal their compliance with the requirements herein." If the intent is
>> MUST,
>> change SHOULD to MUST throughout.
>>
>> Given the -03 history of deliberately relaxing this requirement, the
>> former
>> seems correct, but the authors must confirm and fix the text explicitly.
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Section 7, paragraph 1
>> >    This specification tightens token audience requirements to prevent
>> >    attacks that could result from exploiting audience ambiguities
>> >    previously allowed by [RFC7521], [RFC7522], [RFC7523], and [RFC9126].
>> >    These attacks are described in [private_key_jwt.Disclosure] and
>> >    [Audience.Injection].
>>
>> Section 4a of this document updates the authorization grant audience
>> requirement to:
>>
>> "An authorization server MAY be identified by either its issuer
>> identifier or its token endpoint URL."
>>
>> The document history notes that this flexibility was retained to minimize
>> breaking changes. By allowing the token endpoint URL as a valid audience
>> for
>> authorization grants, a subset of the attack surface described in the
>> referenced paper remains.
>>
>> The document does not acknowledge this residual risk. This section
>> says that "This specification tightens token audience requirements
>> to prevent attacks" — a statement that is not fully accurate for
>> the authorization grant case. The Security Considerations should
>> state explicitly that: (a) the tighter restriction applies only
>> to client authentication JWTs; (b) authorization grant audience
>> requirements were relaxed relative to what full security would
>> require, for deployment compatibility reasons, and (c) implementers
>> seeking maximum security for authorization grants SHOULD prefer
>> the issuer identifier over the token endpoint URL.
>>
>> The ARTART reviewer (Jim Fenton, thanks, Jim) touched on this
>> concern about strong typing, but the underlying grant case
>> residual risk deserves direct acknowledgment.
>>
>> No reference entries found for these items, which were mentioned in the
>> text:
>> [draft-jones-oauth-rfc7523bis-00].
>>
>>
>>
>>
> *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.*
>
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>
>

-- 
_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._