The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework".
-------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4749 -------------------------------------- Type: Technical Reported by: Phil Hunt <phil.h...@oracle.com> 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. The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password. Corrected 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. The url encoded values are then encoded as defined in [RFC2617]. The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password. Notes ----- It was not clear to some implementers that the intention is a 2-step encoding. First for special characters and second the 2617 base 64 encoding. Implementers thought 6749 was in conflict with 2617. To avoid inter-op issues, a new clarifying sentence is proposed. "The url encoded values are then encoded as defined in [RFC2617]." 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 (IESG) 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
