My understanding was that errata are only for when the text of the RFC was incorrect based on the information available at the time. Since RFC7617 was published after RFC6749, it can't be considered an errata of 6749. I also think this should be rejected.
---- Aaron Parecki aaronparecki.com @aaronpk On Mon, Mar 16, 2020 at 3:07 PM Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > +1 > > > > From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell > Sent: Monday, March 16, 2020 3:05 PM > To: RFC Errata System <rfc-edi...@rfc-editor.org> > Cc: 1983-01...@gmx.net; oauth <oauth@ietf.org> > 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 <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/eid6017 > > -------------------------------------- > Type: Technical > Reported by: Michael Osipov <1983-01...@gmx.net> > > 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 > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
