RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Reported (2)

RFC 6750, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", October 2012

Source of RFC: oauth (sec)

Errata ID: 5335
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Kavindu Dodanduwa
Date Reported: 2018-04-26

Section 2.1 says:

b64token

It should say:

token68

Notes:

Usage of b64token is confusing. Definition is self explanatory but could be easily confused with Base64.

RFC7235 defines token68. Following some old RFC draft discussions (http://w3-org.9356.n7.nabble.com/p7-rename-b64token-to-token68-to-avoid-misunderstandings-td108256.html) I found that b64token was renamed to token68.

I believe it's appropriate to use naming of token68 (instead of b64token) in RFC6750. So that it is less confusing as well as refers to an existing standard.

Errata ID: 6161
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Herbert Valerio Riedel
Date Reported: 2020-05-08

Section 4 says:

4.  Example Access Token Response

   Typically, a bearer token is returned to the client as part of an
   OAuth 2.0 [RFC6749] access token response.  An example of such a
   response is:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8

It should say:

4.  Example Access Token Response

   Typically, a bearer token is returned to the client as part of an
   OAuth 2.0 [RFC6749] access token response.  An example of such a
   response is:

     HTTP/1.1 200 OK
     Content-Type: application/json

Notes:

The IANA registration (see https://tools.ietf.org/html/rfc8259#section-11) does not support any parameters for the `application/json` media type. The `charset=UTF-8` parameter used in the example is therefore non-compliant and ought to be omitted.

Report New Errata