RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (3)

RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012

Source of RFC: oauth (sec)

Errata ID: 3446

Status: Verified
Type: Editorial

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

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

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.

Status: Reported (5)

RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012

Source of RFC: oauth (sec)

Errata ID: 4679

Status: Reported
Type: Technical

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

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

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

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: 4697

Status: Reported
Type: Editorial

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.

Status: Held for Document Update (2)

RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012

Source of RFC: oauth (sec)

Errata ID: 3780

Status: Held for Document Update
Type: Technical

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

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

Source of RFC: oauth (sec)

Errata ID: 3880

Status: Rejected
Type: Technical

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

Report New Errata



Search RFCs
Advanced Search
×