While the use of "application/x-www-form-urlencoded" on the username (client_id) and password (client_secret) values before the base64 encoding for the HTTP Basic token is rather ugly and less than ideal, I don't believe that using/referencing RFC7617 would actually address all the reasons for which form-urlencoding was used. That a client_id value ( https://tools.ietf.org/html/rfc6749?#appendix-A.1) might contain a colon character ":" being a key reason. Not doing the "application/x-www-form-urlencoded" encoding/decoding step in OAuth for the client secret basic would also be a breaking change for working implementations, which is beyond what an errata can/should do. As such, I think this erratum should be rejected
On Sun, Mar 15, 2020 at 3:57 PM RFC Errata System <[email protected]> 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/eid6017 > > -------------------------------------- > Type: Technical > Reported by: Michael Osipov <[email protected]> > > Section: 2.3.1 > > Original Text > ------------- > Clients in possession of a client password MAY use the HTTP Basic > authentication scheme as defined in [RFC2617] to authenticate with > the authorization server. The client identifier is encoded using the > "application/x-www-form-urlencoded" encoding algorithm per > Appendix B, and the encoded value is used as the username; the client > password is encoded using the same algorithm and used as the > password. > > Corrected Text > -------------- > Clients in possession of a client password MAY use the HTTP Basic > authentication scheme as defined in [RFC7617] to authenticate with > the authorization server. > > Notes > ----- > RFC 2617 has been superseded by RFC7617 which clearly defines in section > 2.1 how a charset can be provided to solve the usecase described with > encoding. > > The original text of this RFC violates the approach described for Basic > authentication. > > 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. > > -------------------------------------- > 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 > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
