RFC Errata
Found 19 records.
Status: Verified (4)
RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012
Source of RFC: oauth (sec)
Errata ID: 3446
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nov Matake
Date Reported: 2013-01-07
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16
Section 1 says:
o Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.
It should say:
o Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing their password.
Notes:
The text was originally "their" but changed to "the third party's" between the last draft and RFC.
However, "their" means "resource owners'", not "the third party's".
Errata ID: 3500
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Field
Date Reported: 2013-02-26
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16
Section 4.1 says:
(E) The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
It should say:
(E) The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect (the resource owner's user-agent)
to the client in step (C). If valid, the authorization server
responds back with an access token and, optionally, a refresh token.
Notes:
The URI in question is the URI that was used to redirect the resource owner's user-agent back to the client to deliver the code. The original text in step (E) seems to say that this URI was used to redirect the client, but I think this is an ambiguous/imprecise use of the word "client." It was not the OAuth client that was redirected using that URI, it was the resource owner's user-agent that was redirected, *to* the client.
The parenthetical (the resource owner's user-agent) is more precise but may perhaps be too verbose. I think, at minimum, we must say "....the URI used to redirect *to* the client in step (C)."
Errata ID: 3904
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takahiko Kawasaki
Date Reported: 2014-03-01
Verifier Name: Kathleen Moriarty
Date Verified: 2015-12-08
Section 11.2.2. says:
It should say:
o Parameter name: error o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749
Notes:
"error" is missing and should be added to the list of Initial Registry Contents of OAuth Parameters Registry.
AD note: This is in the normative registry, although it doesn't appear in the final published RFC. The WG suspects there was a mistake that removed it from RFC 6749 prior to final publication. I've marked this as editorial since the IANA registry is normative, but also as verified.
Errata ID: 6613
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2021-06-17
Verifier Name: Benjamin Kaduk
Date Verified: 2021-07-18
Section 3.3 says:
The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings
It should say:
The value of the scope parameter is expressed as a space-delimited list of case-sensitive strings
Notes:
The original/current seems to be a bit confusing.
The value is not a collection of space-delimited strings (whatever a "space-delimited string" would be), but it a space-delimited (representation of) a collection of strings.
Status: Reported (15)
RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012
Source of RFC: oauth (sec)
Errata ID: 4679
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yi EungJun
Date Reported: 2016-04-29
Throughout the document, when it says:
Content-Type: application/json;charset=UTF-8
It should say:
Content-Type: application/json
Notes:
application/json does not have charset parameter.
Errata ID: 4745
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Clark Downum
Date Reported: 2016-07-20
Section 5.2 says:
error
REQUIRED. A single ASCII [USASCII] error code from the
following:
invalid_request
The request is missing a required parameter, includes an
unsupported parameter value (other than grant type),
repeats a parameter, includes multiple credentials,
utilizes more than one mechanism for authenticating the
client, or is otherwise malformed.
invalid_client
Client authentication failed (e.g., unknown client, no
client authentication included, or unsupported
authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code and
include the "WWW-Authenticate" response header field
matching the authentication scheme used by the client.
invalid_grant
The provided authorization grant (e.g., authorization
code, resource owner credentials) or refresh token is
invalid, expired, revoked, does not match the redirection
URI used in the authorization request, or was issued to
another client.
unauthorized_client
The authenticated client is not authorized to use this
authorization grant type.
unsupported_grant_type
The authorization grant type is not supported by the
authorization server.
invalid_scope
The requested scope is invalid, unknown, malformed, or
exceeds the scope granted by the resource owner.
Values for the "error" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E.
It should say:
error
REQUIRED. A single ASCII [USASCII] error code from the
following:
invalid_request
The request is missing a required parameter, includes an
unsupported parameter value (other than grant type),
repeats a parameter, includes multiple credentials,
utilizes more than one mechanism for authenticating the
client, or is otherwise malformed.
invalid_client
Client authentication failed (e.g., unknown client, no
client authentication included, or unsupported
authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code and
include the "WWW-Authenticate" response header field
matching the authentication scheme used by the client.
invalid_grant
The provided authorization grant (e.g., authorization
code, resource owner credentials) or refresh token is
invalid, expired, revoked, does not match the redirection
URI used in the authorization request, or was issued to
another client.
unauthorized_client
The authenticated client is not authorized to use this
authorization grant type.
unsupported_grant_type
The authorization grant type is not supported by the
authorization server.
invalid_scope
The requested scope is invalid, unknown, malformed, or
exceeds the scope granted by the resource owner.
server_error
The authorization server encountered an unexpected
condition that prevented it from fulfilling the request.
(This error code is needed because a 500 Internal Server
Error HTTP status code cannot be returned to the client
via an HTTP redirect.)
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance
of the server. (This error code is needed because a 503
Service Unavailable HTTP status code cannot be returned
to the client via an HTTP redirect.)
Values for the "error" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E.
Notes:
This is simply adding the server_error and temporarily_unavailable errors in other responses responses to the access token response for non-implicit grant types.
Errata ID: 4749
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Phil Hunt
Date Reported: 2016-07-26
Section 2.3.1 says:
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.
It should say:
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]."
Errata ID: 4819
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Lars Kemmann
Date Reported: 2016-10-05
Section 4.2.2 says:
HTTP/1.1 302 Found
Location: http://example.com/cb#
access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
It should say:
HTTP/1.1 302 Found
Location: http://client.example.com/cb#
access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
Notes:
In the example for section 4.2.1, the request was made with a `redirect_uri` parameter value of `redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb`. If I understand correctly, the `client` subdomain should be included in the `Location` header in the response.
Errata ID: 5234
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Randip Kumar Malakar
Date Reported: 2018-01-12
Section 2.1. says:
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
It should say:
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
third-party (not resource owner but another end user), such as an
installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
Notes:
I think in case of public client type, it should state as "e.g. the clients executing on the device used by third-party and not the actual resource owner" as mentioned in the original RFC. I let the author or experts to review my remark. Thanks.
Errata ID: 5332
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald F Coffin
Date Reported: 2018-04-24
Section 4.1 says:
(B) The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
It should say:
(B) The authorization server validates the request to ensure that
all required parameters are present and valid. If the request
is valid, the authorization server authenticates the resource
owner and obtains an authorization decision (by asking the
resource owner via the user-agent or by use of other
established approval means).
Notes:
"Section 4.1 Authorization Code Grant (B)" conflicts with "Section 4.1.1 Authorization
Request". The current verbiage implies the resource owner should be authenticated
prior to "The authorization server validates the request to ensure that all required
parameters are present and valid". Such implementations lead to overly complex
user experiences when the Authorization Server determines the request is invalid.
Errata ID: 5793
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin May
Date Reported: 2019-07-25
Section 2.3.1 says:
Alternatively, the authorization server MAY support including the client credentials in the request-body using the following parameters:
It should say:
In addition to that, the authorization server MAY support including the client credentials in the request-body using the following parameters:
Notes:
Given that the authorization MUST support the HTTP Basic authentication scheme in the paragraphs just before this one, using the word "alternatively" here can be understood as "instead of", which is not the intention and can lead to confusion for implementors.
This intention is further highlighted by the use of the word MAY in the paragraph above.
Errata ID: 5873
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ludwig Seitz
Date Reported: 2019-10-11
Section 11.4 says:
It should say:
11.4.2 Initial Registry Contents The OAuth Extensions Error registry's initial contents are: o Error name: invalid_request o Error usage location: authorization code grant error response, implicit grant error response, token error response o Related protocol extension: authorization code grant, implicit grant, any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: unauthorized_client o Error usage location: authorization code grant error response, implicit grant error response, token error response o Related protocol extension: authorization code grant, implicit grant, any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: access_denied o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit grant o Change controller: IETF o Specification document(s): RFC 6749 o Error name: unsupported_response_type o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit grant o Change controller: IETF o Specification document(s): RFC 6749 o Error name: invalid_scope o Error usage location: authorization code grant error response, implicit grant error response, token error response o Related protocol extension: authorization code grant, implicit grant, any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: server_error o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit grant o Change controller: IETF o Specification document(s): RFC 6749 o Error name: temporarily_unavailable o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit granto Change controller: IETF o Specification document(s): RFC 6749 o Error name: invalid_client o Error usage location: token error response o Related protocol extension: any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: invalid_grant o Error usage location: token error response o Related protocol extension: any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: unsupported_grant_type o Error usage location: token error response o Related protocol extension: any access token type o Change controller: IETF o Specification document(s): RFC 6749
Notes:
It seems that the values specified in sections 4.1.2.1.,4.2.2.1. and 5.2. should have been added to the registry but were forgotten.
This errata suggests "any access token type" for "Related protocol extension" for the error codes of 5.2 since they seem to apply to any errors returned from the token endpoint, no matter which access token type is involved.
Errata ID: 6017
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Osipov
Date Reported: 2020-03-15
Section 2.3.1 says:
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.
It should say:
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.
Errata ID: 4697
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ludwig Seitz
Date Reported: 2016-05-19
Section 7.1 says:
For example, the "bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request:
It should say:
For example, the "Bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request:
Notes:
RFC6750 defines the "Bearer" token type not the "bearer" token type.
Errata ID: 4945
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Abhimanyu Singh Gaur
Date Reported: 2017-02-21
Section 4.1.4 says:
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request client authentication failed or is invalid, the authorization server returns an error response as described in Section 5.2.
It should say:
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.
Notes:
In the 2nd line, "request failed" makes more sense than the original text.
The 1st paragraph of section 5 in the document and the para just before section 5 also state "If the request failed client authentication or ..." instead of what is currently mentioned in section 4.1.4.
It is just a typing mistake, I think the words got exchanged during typing.
Please, correct it.
Errata ID: 5379
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2018-06-06
Section 5.1, 4.2.2 says:
expires_in
RECOMMENDED. The lifetime in seconds of the access token. For
example, the value "3600" denotes ...
It should say:
expires_in
RECOMMENDED. The lifetime in seconds of the access token. For
example, the value 3600 denotes ...
Notes:
The "expires_in" member in JSON must be a numeric value, not a string. Unfortunately quite a few implementations have got this wrong. A likely reason is the quoted value "3600" in the RFC where "expires_in" is defined. The quotes in the text version of the RFC are only an artefact of the marked-up as a protocol value in the RFC production chain.
Errata ID: 5708
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Campbell
Date Reported: 2019-04-29
Section 3.1 and 3.2 says:
Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters MUST NOT be included more than once.
It should say:
Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters defined by this specification MUST NOT be included more than once.
Notes:
Adds the text "defined by this specification" to the last sentence to clarify that the restriction only applies to parameters defined in RFC 6749 and not to unrecognized parameters or parameters defined by extension.
Errata ID: 6614
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2021-06-17
Section 5.1 says:
... adding the following parameters to the entity-body of the HTTP response ...
It should say:
... adding the following parameters as members to the JSON object in the entity-body of the HTTP response ...
Notes:
Saying "adding the following parameters to the entity-body" seems to be confusing,
implying that HTTP entity bodies have parameters (at the level of semantics defined by HTTP), which they don't.
The corrected text doesn't necessarily need to be what I proposed in the "Corrected Text" field, but it should probably at least refer to the data or (JSON) object inside the entity body instead of just referring to the entity body.
Errata ID: 6615
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2021-06-17
Throughout the document, when it says:
Condition descriptions like "The authorization server ... validates the authorization grant, and if valid, issues an access token."
It should say:
Adjusted descriptions like "The authorization server ... validates the authorization grant, and if it is valid, issues an access token."
Notes:
The wording pattern "A validates B, and if valid, does X" means "A validates B, and if A is valid, does X" and is confusing.
Those descriptions' wording should be adjusted, probably to the pattern "A validates B, and if it is valid, does X" (or whatever else actually says what was meant to be specified).
There are many occurrences with literally "and if valid"; it looks (from a quick search) like most, but not all, need adjustment. There are also several cases of "and if" followed by something other than "valid"--some seem correct, but a few might need adjustment.
