Thanks Aaron. I agree with your assessment. On Mon, May 8, 2023 at 10:00 AM Aaron Parecki <aaron= 40parecki....@dmarc.ietf.org> wrote:
> This errata is incorrect and should be rejected. RFC7523 defines two > separate uses of JWTs, one is client authentication and the other is an > authorization grant. When using RFC7523 as client authentication, you can > use any type of authorization grant, including the token exchange grant. > See https://datatracker.ietf.org/doc/html/rfc7523#section-2.2 > > Aaron > > On Mon, May 8, 2023 at 8:57 AM RFC Errata System < > rfc-edi...@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC8693, >> "OAuth 2.0 Token Exchange". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7511 >> >> -------------------------------------- >> Type: Technical >> Reported by: Jesse Estum <jesse.es...@gmail.com> >> >> Section: 2.1 >> >> Original Text >> ------------- >> Client authentication to the authorization server is done using the >> normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] >> defines password-based authentication of the client, however, client >> authentication is extensible and other mechanisms are possible. For >> example, [RFC7523] defines client authentication using bearer JSON Web >> Tokens (JWTs) [JWT]. The supported methods of client authentication and >> whether or not to allow unauthenticated or unidentified clients are >> deployment decisions that are at the discretion of the authorization >> server. >> >> Corrected Text >> -------------- >> Client authentication to the authorization server is done using the >> normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] >> defines password-based authentication of the client, however, client >> authentication is extensible and other mechanisms are possible. The >> supported methods of client authentication and whether or not to allow >> unauthenticated or unidentified clients are deployment decisions that >> are at the discretion of the authorization server. >> >> Notes >> ----- >> The specific example of authentication with RFC7523 would require >> "grant_type" value of "urn:ietf:params:oauth:grant-type:jwt-bearer", >> however this directly conflicts with RFC8693 as it requires "grant_type" >> value of "urn:ietf:params:oauth:grant-type:token-exchange". >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8693 (draft-ietf-oauth-token-exchange-19) >> -------------------------------------- >> Title : OAuth 2.0 Token Exchange >> Publication Date : January 2020 >> Author(s) : M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, >> C. Mortimore >> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
