[OAUTH-WG] Mahesh Jethanandani's No Objection on draft-ietf-oauth-rfc7523bis-11: (with COMMENT)

[Mahesh Jethanandani via Datatracker <[e-mail]>]

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-oauth-rfc7523bis-11: No Objection

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/



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