+1 From: OAuth <[email protected]> On Behalf Of Brian Campbell Sent: Monday, March 16, 2020 3:05 PM To: RFC Errata System <[email protected]> Cc: [email protected]; oauth <[email protected]> Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (6017)
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]<mailto:[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]<mailto:[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]<mailto:[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
