[OAUTH-WG] Mohamed Boucadair's No Objection on draft-ietf-oauth-rfc7523bis-10: (with COMMENT)

Mohamed Boucadair via Datatracker <noreply@ietf.org> Mon, 27 April 2026 07:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@mail2.ietf.org
Received: from [10.244.6.0] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id B78B6E3BEA42; Mon, 27 Apr 2026 00:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777274384; bh=EhvHBqDuxdc8hgRZ2Kr3bFYxzF6Ws1f3ytMHn6B6HQE=; h=From:To:Cc:Subject:Reply-To:Date; b=ymGwXkHCWVpdQ1AB1hffg3SI361TVMTA8vbqXY+3CJ76H9ftF/IEZtfNWGgJzc43q RcJMYiyKGe8RPZ9WS4rMXf/iCWenalbmjYHcoam/FvaFaZ9ikWxeGQshz7ySnnGopD jbbVfHuAIuFZb7LVLw4ief2EhkLtkRUE9eg1qpqA=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mohamed Boucadair via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <177727438465.2004908.5851198794186580255@dt-datatracker-b45949c58-5szpr>
Date: Mon, 27 Apr 2026 00:19:44 -0700
Message-ID-Hash: J7HA6D27IVZCCELZYNNNZ7TST237VP7W
X-Message-ID-Hash: J7HA6D27IVZCCELZYNNNZ7TST237VP7W
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-oauth-rfc7523bis@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Mohamed Boucadair <mohamed.boucadair@orange.com>
Subject: [OAUTH-WG] Mohamed Boucadair's No Objection on draft-ietf-oauth-rfc7523bis-10: (with COMMENT)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SjAn38U6bLhVKNxRLm2KKrZRQUM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Mohamed Boucadair has entered the following ballot position for
draft-ietf-oauth-rfc7523bis-10: 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:
----------------------------------------------------------------------

Hi Mike, Brian, Chuck, and Filip,

Thank you for the effort put into this document and working out these fixes.

Thanks to Luigi Iannone for the OPSDIR review and to the authors for the
changes made in -08 to address Luigi’s feedback.

# OLD/NEW Pattern

This may be a matter of taste, but I would prefer if we have an OLD/NEW pattern
through the document to explicitly identify the updates we are making, more
convenient for readers/reviewers to avoid ping-ping between various documents,
and also ease identifying the changes.

For example, Section 5 would be updated to say:

OLD:

| Audience
|      A value that identifies the party or parties intended to process
|      the assertion.  The URL of the token endpoint, as defined in
|      Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate that
|      the authorization server is a valid intended audience of the
|      assertion.  In the absence of an application profile specifying
|      otherwise, compliant applications MUST compare the Audience values
|      using the Simple String Comparison method defined in Section 6.2.1
|      of RFC 3986 [RFC3986].

NEW:

  Audience
     A value that identifies the party intended to process the
     assertion.  The issuer identifier of the authorization server, as
     defined in [RFC8414], can be used to indicate that the
     authorization server is a valid intended audience of the
     assertion.

## Having the text back to back, highlights that the NEW text does not have
“parties” and does not include last part.

## The last sentence of the OLD is in the NEW update to 7523.

## Having some commentary text to explain the changes would help.

Cheers,
Med