Hi Roman, We are unable to verify this erratum that the submitter marked as editorial, so we changed the Type to “Technical”. As Stream Approver, please review and set the Status and Type accordingly (see the definitions at https://www.rfc-editor.org/errata-definitions/).
You may review the report at: https://www.rfc-editor.org/errata/eid7823 Information on how to verify errata reports can be found at: https://www.rfc-editor.org/how-to-verify/ Further information on errata can be found at: https://www.rfc-editor.org/errata.php Thank you. RFC Editor/rv > On Feb 26, 2024, at 6:13 PM, RFC Errata System <rfc-edi...@rfc-editor.org> > wrote: > > 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 <r...@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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
