RFC Errata
Found 2 records.
Status: Reported (2)
RFC 6750, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", October 2012
Note: This RFC has been updated by RFC 8996
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.