RFC Errata
Found 28 records.
Status: Verified (5)
RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012
Note: This RFC has been updated by RFC 8252, RFC 8996
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: 5708
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Campbell
Date Reported: 2019-04-29
Verifier Name: Roman Danyliw
Date Verified: 2024-01-17
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: 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 (20)
RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012
Note: This RFC has been updated by RFC 8252, RFC 8996
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: 7429
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gasan Guseinov
Date Reported: 2023-04-20
Section 2 says:
Before initiating the protocol, the client registers with the authorization server. The means through which the client registers with the authorization server are beyond the scope of this specification but typically involve end-user interaction with an HTML registration form.
It should say:
Before initiating the protocol, the client registers with the authorization server. The means through which the client registers with the authorization server are beyond the scope of this specification but typically involve client developer interaction with an HTML registration form.
Notes:
As described in 1.1 resource owner if person is referred to as end user. Resource owner is not responsible for registering a client with authorization server, but the client developer is.
Errata ID: 7642
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Wilhelm Fast
Date Reported: 2023-09-17
Section 1 says:
Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation- specific credentials (access token).
It should say:
Instead, she directly authenticates with a trusted server, the authorization server, which issues delegation-specific credentials, known as access tokens, to the printing service for controlled and secure access.
Notes:
The sentence is confusing, and the reader might confuse the Authorization Server with the Resource Server.
Errata ID: 7631
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daiki Usami
Date Reported: 2023-09-05
Section 3.2.1 says:
This protects the client from substitution of the authentication code.
It should say:
This protects the client from substitution of the authorization code.
Notes:
It will be a bit confusing to figure out if it is a MAC or an authorization code.
Errata ID: 7716
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Wilson
Date Reported: 2023-11-29
Section 4.2.2 says:
For example, the authorization server redirects the user-agent by sending the following HTTP response (with extra line breaks for display purposes only): HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600
It should say:
For example, the authorization server redirects the user-agent by sending the following HTTP response (with extra line breaks for display purposes only): HTTP/1.1 302 Found Location: http://client.example.com/cb?access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600
Notes:
- Host example.com should be client.example.com to be consistent with other examples.
- A hash is used for the query parameters when a question mark should have been used.
RFC Editor Note: The first point above is a duplicate of EID 4819, which is currently still in Reported state (see https://www.rfc-editor.org/errata/eid4819).
Errata ID: 7715
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Wilson
Date Reported: 2023-11-29
Section 4.2.2.1 says:
HTTP/1.1 302 Found Location: https://client.example.com/cb#error=access_denied&state=xyz
It should say:
HTTP/1.1 302 Found Location: https://client.example.com/cb?error=access_denied&state=xyz
Notes:
For query parameters, the hash should be a question mark.
Errata ID: 7823
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Stumpf
Date Reported: 2024-02-26
Section 3.2.1 says:
Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint. Client authentication is used for: o Enforcing the binding of refresh tokens and authorization codes to the client they were issued to. Client authentication is critical when an authorization code is transmitted to the redirection endpoint over an insecure channel or when the redirection URI has not been registered in full.
It should say:
Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint. Client authentication is used for: o Enforcing the binding of refresh tokens, authorization codes, and (in the case of the Client Credentials Grant as described in Section 4.4) the access token to the client they were issued to. Client authentication is critical when an authorization code is transmitted to the redirection endpoint over an insecure channel or when the redirection URI has not been registered in full.
Notes:
Section 4.4.2 requires for the "client_credentials" grant type that the client is authenticated to the authorization server according to section 3.2.1. The reason for this authentication is (or so I assume) that the to-be-issued access token shall be bound to the correct (authenticated) client. Otherwise, the client could authenticate with valid credentials as "client A" and request a token for "client B", and would still be in accordance with the RFC, which is probably not intended.
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: 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.
Status: Held for Document Update (2)
RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012
Note: This RFC has been updated by RFC 8252, RFC 8996
Source of RFC: oauth (sec)
Errata ID: 3780
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Torsten Lodderstedt
Date Reported: 2013-11-04
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-12-08
Section 3.2.1 says:
A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.
It should say:
A public client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.
Notes:
Note from AD: The provided link doesn't exactly demonstrate consensus, but the change makes sense, hence this is marked "Held for Document Update".
From Submitter: The current text may mislead confidential clients to sent their client_id in the request body in addition to their client_id and client_secret in the BASIC authz header. This leads to unnecessary duplication and ambiguities.
There has been consensus on the list that the intention of this sentence was to advise _public_ clients to identity themselves towards the token endpoint in order to mitigate substitution attacks and allow for logging. Confidential clients need to authenticate anyway, this sentence should be narrowed down to public clients only.
see http://www.ietf.org/mail-archive/web/oauth/current/msg12005.html
This issue was discovered in the course of the OpenID Connect Interop testings.
Errata ID: 4206
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Kempgen
Date Reported: 2014-12-23
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-12-08
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 redirection URI provided by the client in step (A). If valid, the authorization server responds back with an access token and, optionally, a refresh token.
Notes:
AD & WG notes: The wording is better, so this is accepted, but it does mean the same thing. The URI in A and C are the same.
See https://www.ietf.org/mail-archive/web/oauth/current/msg15277.html and responses.
Submitter notes: As written in section 4.1.3, the redirection URI in the access token request must match the redirection URI provided by the client in the authorization request (4.1.1). The URI used to redirect the user agent to the client in step (C) is actually different from this URI, as it contains the additional query parameters "code" and "state".
Affects the same sentence as Errata ID: 3500.
Status: Rejected (1)
RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012
Note: This RFC has been updated by RFC 8252, RFC 8996
Source of RFC: oauth (sec)
Errata ID: 3880
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Eriksen Costa
Date Reported: 2014-02-04
Rejected by: Kathleen Moriarty
Date Rejected: 2015-12-08
Section 10.16 says:
For public clients using implicit flows, this specification does not provide any method for the client to determine what client an access token was issued to.
It should say:
For public clients using implicit flows, this specification does not provide any method for the authorization server to determine what client an access token was issued to.
Notes:
A client can only know about tokens issued to it and not for other clients.
From the WG:
https://www.ietf.org/mail-archive/web/oauth/current/msg12391.html
--VERIFIER NOTES--
The current text is correct, see https://www.ietf.org/mail-archive/web/oauth/current/msg12391.html