[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7823)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 26 February 2024 23:13 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52755C151981 for <oauth@ietfa.amsl.com>; Mon, 26 Feb 2024 15:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.959
X-Spam-Level:
X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulfFQ7M6kMf0 for <oauth@ietfa.amsl.com>; Mon, 26 Feb 2024 15:13:54 -0800 (PST)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5D2C151556 for <oauth@ietf.org>; Mon, 26 Feb 2024 15:13:54 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 820FAEF28C; Mon, 26 Feb 2024 15:13:54 -0800 (PST)
To: rfc-editor@rfc-editor.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rfc@AlexStumpf.de, dick.hardt@gmail.com, oauth@ietf.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240226231354.820FAEF28C@rfcpa.amsl.com>
Date: Mon, 26 Feb 2024 15:13:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Ocxfz1dZYNvHahvZT6N3ADmmu1o>
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7823)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2024 23:13:59 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7823

--------------------------------------
Type: Editorial
Reported by: Alexander Stumpf <rfc@AlexStumpf.de>

Section: 3.2.1

Original Text
-------------
   Confidential clients or other clients issued client credentials MUST
   authenticate with the authorization server as described in
   Section 2.3 when making requests to the token endpoint.  Client
   authentication is used for:

   o  Enforcing the binding of refresh tokens and authorization codes to
      the client they were issued to.  Client authentication is critical
      when an authorization code is transmitted to the redirection
      endpoint over an insecure channel or when the redirection URI has
      not been registered in full.

Corrected Text
--------------
   Confidential clients or other clients issued client credentials MUST
   authenticate with the authorization server as described in
   Section 2.3 when making requests to the token endpoint.  Client
   authentication is used for:

   o  Enforcing the binding of refresh tokens, authorization codes, and
      (in the case of the Client Credentials Grant as described in
      Section 4.4) the access token to the client they were issued to.
      Client authentication is critical when an authorization code is
      transmitted to the redirection endpoint over an insecure channel
      or when the redirection URI has not been registered in full.

Notes
-----
Section 4.4.2 requires for the "client_credentials" grant type that the client is authenticated to the authorization server according to section 3.2.1. The reason for this authentication is (or so I assume) that the to-be-issued access token shall be bound to the correct (authenticated) client. Otherwise, the client could authenticate with valid credentials as "client A" and request a token for "client B", and would still be in accordance with the RFC, which is probably not intended.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG