[OAUTH-WG] [Technical Errata Reported] RFC8252 (8080)

[RFC Errata System]

The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8080

--
Type: Technical
Reported by: Bryce Thomas 

Section: 6 and 7.1

Original Text
-
> Any redirect URI that allows
   the app to receive the URI and inspect its parameters is viable.

and

> When choosing a URI scheme to associate with the app, apps MUST use a
   URI scheme based on a domain name under their control, expressed in
   reverse order, as recommended by Section 3.8 of [RFC7595] for
   private-use URI schemes.

These two statements appear to conflict.

Corrected Text
--
> Any redirect URI that allows
   the app to receive the URI and inspect its parameters is viable.

and

> When choosing a URI scheme to associate with the app, apps SHOULD use a
   URI scheme based on a domain name under their control, expressed in
   reverse order, as recommended by Section 3.8 of [RFC7595] for

Notes
-
Suggest downgrading the section 7.1 text from MUST to SHOULD to resolve the 
conflict.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] [Technical Errata Reported] RFC7519 (8060)

[RFC Errata System]

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8060

--
Type: Technical
Reported by: Pieter Kasselman 

Section: 7.2

Original Text
-
   5.   Verify that the resulting JOSE Header includes only parameters
and values whose syntax and semantics are both understood and
supported or that are specified as being ignored when not
understood.

Corrected Text
--
   5.   Verify that the resulting JOSE Header includes only parameters
and values whose syntax and semantics are both understood and
supported or that are specified as being ignored when not
understood. If the JWT is a JWS, the steps specified in 
RFC7515 takes precedence when validating JOSE Header parameters.

Notes
-
Validation step 5 in section 7.2 of RFC 7519 states that header parameters 
should only be ignored if they are explicitly specified as needing to be 
ignored. 

This is contrary to step 7 in section 7.2 which requires that the processing 
rules of RFC 1515 be used if the JWT is a JWS (defined in RFC 1515). RFC 7515 
does not include any special provisions for only ignoring header parameters if 
they are specified as being ignored, but instead requires all header parameters 
to be ignored if they are not understood (repeated below for convenience). 

"Unless listed as a critical Header Parameter, per
   Section 4.1.11, all Header Parameters not defined by this
   specification MUST be ignored when not understood."

A discussion with the authors at IETF 120 confirmed that all header parameters 
that are not understood must be ignored.

The proposed errata aims to clarify that if the JWT is a JWS, the processing 
rules of RFC 7151 should apply (including ignoring header parameters that are 
not understood). This is consistent with point 7.2, which requires that RFC 
7515 [JWS] rules applies and avoids the impression that a new requirement on 
when parameters are ignored is being introduced in (i.e. the need to be 
explicitly defined as needing to be ignored).

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] [Technical Errata Reported] RFC7591 (7969)

[RFC Errata System]

The following errata report has been submitted for RFC7591,
"OAuth 2.0 Dynamic Client Registration Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7969

--
Type: Technical
Reported by: Ivan Mok 

Section: 2.3

Original Text
-
   For example, a software statement could contain the following claims:

 {
  "software_id": "4NRB1-0XZABZI9E6-5SM3R",
  "client_name": "Example Statement-based Client",
  "client_uri": "https://client.example.net/";
 }

   The following non-normative example JWT includes these claims and has
   been asymmetrically signed using "RS256" (with line breaks for
   display purposes only):

 eyJhbGciOiJSUzI1NiJ9.
 eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
 bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
 aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
 GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
 zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
 fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
 U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
 IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA

Corrected Text
--
   For example, a software statement could contain the following claims:

 {
  "iss": "https://example.com";,
  "software_id": "4NRB1-0XZABZI9E6-5SM3R",
  "client_name": "Example Statement-based Client",
  "client_uri": "https://client.example.net/";
 }

   The following non-normative example JWT includes these claims and has
   been asymmetrically signed using "RS256" (with line breaks for
   display purposes only):

 eyJhbGciOiJSUzI1NiJ9..

Notes
-
Section 2.3 Software Statement says, "the software statement ... MUST contain 
an "iss" (issuer) claim denoting the party attesting to the claims in the 
software statement." It would be useful to readers if the sample software 
statement in the same section adheres to this condition. 

If this change is reasonable, the signed JWT in section 3.1.1.  Client 
Registration Request Using a Software Statement should also be updated.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC7591 (draft-ietf-oauth-dyn-reg-30)
--
Title   : OAuth 2.0 Dynamic Client Registration Protocol
Publication Date: July 2015
Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] [Technical Errata Reported] RFC9470 (7951)

[RFC Errata System]

The following errata report has been submitted for RFC9470,
"OAuth 2.0 Step Up Authentication Challenge Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7951

--
Type: Technical
Reported by: Tomasz Kuczyński 

Section: 6.2

Original Text
-
 "exp": 1639528912,
 "iat": 1618354090,
 "auth_time": 1646340198,

Corrected Text
--
 "exp": 1639528912,
 "iat": 1618354090,
 "auth_time": 1618354090,

Notes
-
I noticed a small inconsistency in the example "Figure 7: Introspection 
Response". It seems that the time for the user-authentication event should be 
less than or equal to the time of token issuance to ensure logical coherence.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC9470 (draft-ietf-oauth-step-up-authn-challenge-17)
--
Title   : OAuth 2.0 Step Up Authentication Challenge Protocol
Publication Date: September 2023
Author(s)   : V. Bertocci, B. Campbell
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] [Editorial Errata Reported] RFC7519 (7893)

[RFC Errata System]

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7893

--
Type: Editorial
Reported by: McCoy L Stevens 

Section: GLOBAL

Original Text
-
{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "q-23falevZhhD3hm9CQbkP5MQyU"
}.{
  "aud": "2110848d-29a3-4056-9ed0-70c4961ece0e",
  "iss": 
"https://5b0fff5a-c23f-4758-956c-02b23cac3f4c.ciamlogin.com/5b0fff5a-c23f-4758-956c-02b23cac3f4c/v2.0";,
  "iat": 1713199391,
  "nbf": 1713199391,
  "exp": 1713203291,
  "aio": 
"AcQAO/8WyIBCeT8pBlTXZLK6GnGT2Tw3Rl6dXhMO5nr1rimjTKyT5w8ZrUjOFyKCPvz/zRh+sVsPNPS/s+Xqg5kPbsbCTq2fmTahpvzF7aY+sz4QkA0/BRGR02ex0nUs8JGpVrQwEKWWSbacQ9bbJTxqZXeL9aZpQNGuIo9c1KdO4H1dOrwidtH5mL41vFlqn2tPbRqb5j390IRMe0kuGihgitT+rAbI8zN+fyMVw8MQl4paCJy/vlxb7HOfPQDxJkcnLpxg",
  "nonce": "defaultNonce",
  "rh": "0.AbgAWv8PWz_CWEeVbAKyPKw_TI2EECGjKVZAntBwxJYezg64ABs.",
  "sub": "QCrryxZCdJTGM8_AeI5VM7-Dz1sIKLCeDyhWIFopeAI",
  "tid": "5b0fff5a-c23f-4758-956c-02b23cac3f4c",
  "uti": "iMF3083nS0mmMCFYBEUBAA",
  "ver": "2.0"
}.[Signature]

Corrected Text
--
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InEtMjNmYWxldlpoaEQzaG05Q1Fia1A1TVF5VSJ9.eyJhdWQiOiIyMTEwODQ4ZC0yOWEzLTQwNTYtOWVkMC03MGM0OTYxZWNlMGUiLCJpc3MiOiJodHRwczovLzViMGZmZjVhLWMyM2YtNDc1OC05NTZjLTAyYjIzY2FjM2Y0Yy5jaWFtbG9naW4uY29tLzViMGZmZjVhLWMyM2YtNDc1OC05NTZjLTAyYjIzY2FjM2Y0Yy92Mi4wIiwiaWF0IjoxNzEzMTk5MzkxLCJuYmYiOjE3MTMxOTkzOTEsImV4cCI6MTcxMzIwMzI5MSwiYWlvIjoiQWNRQU8vOFdBQUFBeUlCQ2VUOHBCbFRYWkxLNkduR1QyVHczUmw2ZFhoTU81bnIxcmltalRLeVQ1dzhaclVqT0Z5S0NQdnovelJoK3NWc1BOUFMvcytYcWc1a1Bic2JDVHEyZm1UYWhwdnpGN2FZK3N6NFFrQTAvQlJHUjAyZXgwblVzOEpHcFZyUXdFS1dXU2JhY1E5YmJKVHhxWlhlTDlhWnBRTkd1SW85YzFLZE80SDFkT3J3aWR0SDVtTDQxdkZscW4ydFBiUnFiNWozOTBJUk1lMGt1R2loZ2l0VCtyQWJJOHpOK2Z5TVZ3OE1RbDRwYUNKeS92bHhiN0hPZlBRRHhKa2NuTHB4ZyIsIm5vbmNlIjoiZGVmYXVsdE5vbmNlIiwicmgiOiIwLkFiZ0FXdjhQV3pfQ1dFZVZiQUt5UEt3X1RJMkVFQ0dqS1ZaQW50Qnd4Slllemc2NEFCcy4iLCJzdWIiOiJRQ3JyeXhaQ2RKVEdNOF9BZUk1Vk03LUR6MXNJS0xDZUR5aFdJRm9wZUFJIiwidGlkIjoiNWIwZmZmNWEtYzIzZi00NzU4LTk1NmMtMDJiMjNjYWMzZjRjIiwidXRpIjoiaU1GMzA4M25TMG1tT
 
UNGWUJFVUJBQSIsInZlciI6IjIuMCJ9.JdOleC_9GXS9jJ8iuQ_VkTXv8DN1whV2psp_PhnTEcme2YhRcck8yHoEXWIT5UxuO1-gJL-fsruirWwBYrYL6_lbBGz9ryzbsq1Xm_bSi74j7F6IAzhfmiv6F8hWtYjKQzhYD5ui8P9r1W8MCUb1mBwFG4-qvNwGtxTyZ-N65CgbntOSboGpPHsJdZA2FjnCOeitVdLQMgW4-NTEnaMtB_3ZaU4SUV4D8PmqDENLF4NpcLslkRANyCY5e6skxu1BRTjjgE0uY_yHUd42RsCOfqVfLv80SNqgqZuXyWwAaWKUIaQuLgEM-ZrSFJsGhjXO1eHe-MAav7DbWCAZLHBy5g

Notes
-
times have changed

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7823)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7823

--
Type: Editorial
Reported by: Alexander Stumpf 

Section: 3.2.1

Original Text
-
   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.

Corrected Text
--
   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.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC8414 (7793)

[RFC Errata System]

The following errata report has been submitted for RFC8414,
"OAuth 2.0 Authorization Server Metadata".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7793

--
Type: Technical
Reported by: Kristina Yasuda 

Section: 2

Original Text
-
response_types_supported
  REQUIRED.  JSON array containing a list of the OAuth 2.0
  "response_type" values that this authorization server supports.
  The array values used are the same as those used with the
  "response_types" parameter defined by "OAuth 2.0 Dynamic Client
  Registration Protocol" [RFC7591].

Corrected Text
--
response_types_supported
  JSON array containing a list of the OAuth 2.0
  "response_type" values that this authorization server supports.
  This is REQUIRED unless no grant types are supported
  that use the authorization endpoint. The array values used are
  the same as those used with the "response_types" parameter defined by
  "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].

Notes
-
For the authorization servers that only support grant types that do not use 
authorization endpoint (like client credentials grant), there is no value to 
put in the required `response_types_supported` parameter. At the same time, 
section 3.2 says that "Claims with zero elements MUST be omitted from the 
response." `authorization_endpoint`parameter is already required for the ASs 
that support grant types that use the authorization endpoint, so it should be 
the same for the `response_types_supported` parameter.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC8414 (draft-ietf-oauth-discovery-10)
--
Title   : OAuth 2.0 Authorization Server Metadata
Publication Date: June 2018
Author(s)   : M. Jones, N. Sakimura, J. Bradley
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7591 (7782)

[RFC Errata System]

The following errata report has been submitted for RFC7591,
"OAuth 2.0 Dynamic Client Registration Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7782

--
Type: Technical
Reported by: Tim Würtele 

Section: 3.2.1

Original Text
-
client_id
  REQUIRED.  OAuth 2.0 client identifier string.  It SHOULD NOT be
  currently valid for any other registered client, though an
  authorization server MAY issue the same client identifier to
  multiple instances of a registered client at its discretion.

Corrected Text
--
client_id
  REQUIRED.  OAuth 2.0 client identifier string.  It MUST NOT be
  currently valid for any other registered client, though an
  authorization server MAY issue the same client identifier to
  multiple instances of a registered client at its discretion.

Notes
-
Allowing the same client_id for multiple clients is a contradiction to:

1. This document, Section 1.3, (D), 2nd bullet point: "a client identifier that 
is unique at the server"

2. This document, Section 3.1: "The authorization server assigns this client a 
unique client identifier"

3. (normative reference) RFC 6749, Section 2.2: "The authorization server 
issues the registered client a client identifier -- a unique string 
representing the registration information provided by the client. [...] The 
client identifier is unique to the authorization server."

4. (non-normative reference) OpenID Connect Dynamic Client Registration 1.0 
incorporating errata set 2, Section 2: "Clients have metadata associated with 
their unique Client Identifier at the Authorization Server."; Section 3.1: "The 
Authorization Server assigns this Client a unique Client Identifier"; Section 
3.2: "client_id REQUIRED. Unique Client Identifier. It MUST NOT be currently 
valid for any other registered Client. "

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC7591 (draft-ietf-oauth-dyn-reg-30)
--
Title   : OAuth 2.0 Dynamic Client Registration Protocol
Publication Date: July 2015
Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC7662 (4764)

[RFC Errata System]

The following errata report has been verified for RFC7662,
"OAuth 2.0 Token Introspection". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid4764

--
Status: Verified
Type: Editorial

Reported by: Brian Campbell 
Date Reported: 2016-08-04
Verified by: Roman Danyliw (IESG)

Section: 3.1

Original Text
-
OAuth registration client metadata names and descriptions are
registered by

Corrected Text
--
OAuth token introspection response parameters are registered by

Notes
-
The original text erroneously mentions registration of client metadata names, 
however, this RFC 7662 is about about token introspection and this section is 
about registration of token introspection response parameters (client metadata 
name registration is RFC 7591).

--
RFC7662 (draft-ietf-oauth-introspection-11)
--
Title   : OAuth 2.0 Token Introspection
Publication Date: October 2015
Author(s)   : J. Richer, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC6749 (5708)

[RFC Errata System]

The following errata report has been verified for RFC6749,
"The OAuth 2.0 Authorization Framework". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5708

--
Status: Verified
Type: Editorial

Reported by: Brian Campbell 
Date Reported: 2019-04-29
Verified by: Roman Danyliw (IESG)

Section: 3.1 and 3.2

Original Text
-
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.

Corrected Text
--
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.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Rejected] RFC7519 (5648)

[RFC Errata System]

The following errata report has been rejected for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5648

--
Status: Rejected
Type: Editorial

Reported by: Andy Delcambre 
Date Reported: 2019-03-08
Rejected by: Roman Danyliw (IESG)

Section: 1

Original Text
-
JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.

   The suggested pronunciation of JWT is the same as the English word
   "jot".



Corrected Text
--
JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.


Notes
-
The suggested pronunciation is strange and confusing. It makes it hard to 
onboard new people verbally and always requires an explanation of the 
pronunciation. The standard already has a perfectly reasonable initialism of 
JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a 
pronunciation that does not map to the letters of the spec, and in my 
experience often leads to confusion when used.
 --VERIFIER NOTES-- 
This guidance was produced with the consensus of the WG.  Per 
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/,
 "Errata are items that were errors at the time the document was published"

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)

[RFC Errata System]

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7720

--
Type: Technical
Reported by: Timothy Vergenz 

Section: 4.1.6

Original Text
-
4.1.6.  "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued.  This claim can be used to determine the age of the JWT.  Its
value MUST be a number containing a NumericDate value.  Use of this
claim is OPTIONAL.

Corrected Text
--
4.1.6.  "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued.  This claim can be used to determine the age of the JWT.  Its
value MUST be a number containing a NumericDate value.  Use of this
claim is OPTIONAL. Implementors MUST NOT reject otherwise-valid JWTs
with "iat" claims that appear to be from the future; token issuers
desiring this behavior may require it by including an "nbf" claim.

Notes
-
There is substantial confusion and disagreement among JWT library implementors 
about whether to reject JWTs with `iat` claims that appear to be from the 
future due to clock drift. This confusion has led to over half a dozen Github 
issues & PRs over the years in libraries in many different ecosystems, and lots 
of strong disagreement among library developers and users.

Based on a sample of the top Google search results for jwt client libraries in 
11 different language ecosystems, the majority (7) of the libraries sampled do 
not reject future `iat` claims, while the remaining 4 *do* reject future `iat` 
claims by default. Of those 4 who do, *all* of them have had Github issues 
filed (by different unique users) in which the user was having a JWT 
unexpectedly rejected by a token validator using the library whose clock had 
drifted from that of the token issuer enough to trigger `iat`-based rejection.

I propose we update the spec to explicitly prohibit rejection of future-`iat` 
JWTs (especially since token issuers have always been able to opt into this 
behavior using an `nbf` claim). Since this RFC has been published and cannot be 
edited, a new superseding RFC will have to be published and this one deprecated 
in order for the suggested change to make it out of the errata and into an 
actual RFC doc.

I'm not sure if this merits a full RFC republish -- but as a data point for 
impact consideration, it's worth noting that this confusion has almost 
certainly wasted at least multiple hours per person (on average) of *dozens* of 
developers' time over the years, and led to at least half a dozen production 
bugs that I've seen mentioned. One of these bugs cropped up in my own 
organization on 2023-11-31 and has been observed previously but was 
misunderstood and not resolved; the 2023-11-31 occurence involved 10+ people in 
discussion. One Github issue I saw described an elongated full web server 
outage attributed to this confusion which cropped up during a 
leap-second-related clock drift issue. I'm filing this errata request on 
calendar day 3+ of discussing this issue in my organization (if you include 
past times this issue has cropped up).

Thanks for your consideration! I look forward to hearing back.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7716)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7716

--
Type: Editorial
Reported by: Alex Wilson 

Section: 4.2.2

Original Text
-
   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


Corrected Text
--
   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.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7715)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7715

--
Type: Editorial
Reported by: Alex Wilson 

Section: 4.2.2.1

Original Text
-

   HTTP/1.1 302 Found
   Location: https://client.example.com/cb#error=access_denied&state=xyz

Corrected Text
--

   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.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC9449 (7646)

[RFC Errata System]

The following errata report has been verified for RFC9449,
"OAuth 2.0 Demonstrating Proof of Possession (DPoP)". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7646

--
Status: Verified
Type: Editorial

Reported by: Michiel Albracht 
Date Reported: 2023-09-18
Verified by: RFC Editor  

Section: 4.2

Original Text
-
When the authentication server or resource server provides a DPoP-Nonce

Corrected Text
--
When the authorization server or resource server provides a DPoP-Nonce

Notes
-
authentication server must be authorization server

--
RFC9449 (draft-ietf-oauth-dpop-16)
--
Title   : OAuth 2.0 Demonstrating Proof of Possession (DPoP)
Publication Date: September 2023
Author(s)   : D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. 
Jones, D. Waite
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC9449 (7646)

[RFC Errata System]

The following errata report has been submitted for RFC9449,
"OAuth 2.0 Demonstrating Proof of Possession (DPoP)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7646

--
Type: Editorial
Reported by: Michiel Albracht 

Section: 4.2

Original Text
-
When the authentication server or resource server provides a DPoP-Nonce

Corrected Text
--
When the authorization server or resource server provides a DPoP-Nonce

Notes
-
authentication server must be authorization server

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC9449 (draft-ietf-oauth-dpop-16)
--
Title   : OAuth 2.0 Demonstrating Proof of Possession (DPoP)
Publication Date: September 2023
Author(s)   : D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. 
Jones, D. Waite
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7642

--
Type: Editorial
Reported by: Wilhelm Fast 

Section: 1

Original Text
-
 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).

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7631)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7631

--
Type: Editorial
Reported by: Daiki Usami 

Section: 3.2.1

Original Text
-
This protects the client from substitution of the authentication code.

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

[RFC Errata System]

The following errata report has been submitted for RFC7662,
"OAuth 2.0 Token Introspection".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7607

--
Type: Technical
Reported by: Fulong Sun 

Section: 2.2

Original Text
-
a given token has been issued by this authorization server, has not been 
revoked by the resource owner, and is within its given time window of validity

Corrected Text
--
a given token has been issued by this authorization server, has not been 
revoked by the resource owner or client, and is within its given time window of 
validity

Notes
-
RFC 7009 defined a given token can be revoke by client, so should write client 
here.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7662 (draft-ietf-oauth-introspection-11)
--
Title   : OAuth 2.0 Token Introspection
Publication Date: October 2015
Author(s)   : J. Richer, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7569)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7569

--
Type: Editorial
Reported by: BRUNO LEITE DA SILVA 

Section: 6749

Original Text
-
BANCO.COM

Corrected Text
--
BANCO.COM/

Notes
-
/ALLISSUR

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC8693 (7511)

[RFC Errata System]

The following errata report has been submitted for RFC8693,
"OAuth 2.0 Token Exchange".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7511

--
Type: Technical
Reported by: Jesse Estum 

Section: 2.1

Original Text
-
Client authentication to the authorization server is done using the 
normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] 
defines password-based authentication of the client, however, client 
authentication is extensible and other mechanisms are possible. For 
example, [RFC7523] defines client authentication using bearer JSON Web 
Tokens (JWTs) [JWT]. The supported methods of client authentication and 
whether or not to allow unauthenticated or unidentified clients are 
deployment decisions that are at the discretion of the authorization 
server.

Corrected Text
--
Client authentication to the authorization server is done using the 
normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] 
defines password-based authentication of the client, however, client 
authentication is extensible and other mechanisms are possible. The 
supported methods of client authentication and whether or not to allow 
unauthenticated or unidentified clients are deployment decisions that 
are at the discretion of the authorization server. 

Notes
-
The specific example of authentication with RFC7523 would require "grant_type" 
value of "urn:ietf:params:oauth:grant-type:jwt-bearer", however this directly 
conflicts with RFC8693 as it requires "grant_type" value of 
"urn:ietf:params:oauth:grant-type:token-exchange".

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8693 (draft-ietf-oauth-token-exchange-19)
--
Title   : OAuth 2.0 Token Exchange
Publication Date: January 2020
Author(s)   : M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. 
Mortimore
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (7429)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7429

--
Type: Technical
Reported by: Gasan Guseinov 

Section: 2

Original Text
-
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.

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7591 (7414)

[RFC Errata System]

The following errata report has been submitted for RFC7591,
"OAuth 2.0 Dynamic Client Registration Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7414

--
Type: Technical
Reported by: Mary Williams 

Section: 2119

Original Text
-
https://api-m.paypal.com/v1/payments/payouts

Corrected Text
--
https://api-m.paypal.com/v1/payments/payouts

Notes
-
https://api-m.paypal.com/v1/payments/payouts

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7591 (draft-ietf-oauth-dyn-reg-30)
--
Title   : OAuth 2.0 Dynamic Client Registration Protocol
Publication Date: July 2015
Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC9126 (7410)

[RFC Errata System]

The following errata report has been submitted for RFC9126,
"OAuth 2.0 Pushed Authorization Requests".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7410

--
Type: Editorial
Reported by: Andrii Deinega 

Section: 1.1

Original Text
-
Uses "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" in two examples.

Corrected Text
--
Use "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2"
instead.

Notes
-
Some may find the use of "urn:example:" a bit misleading.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC9126 (draft-ietf-oauth-par-10)
--
Title   : OAuth 2.0 Pushed Authorization Requests
Publication Date: September 2021
Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. 
Skokan
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC9126 (7254)

[RFC Errata System]

The following errata report has been submitted for RFC9126,
"OAuth 2.0 Pushed Authorization Requests".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7254

--
Type: Editorial
Reported by: Joseph Heenan 

Section: 1.1

Original Text
-
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

&response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
<...>

Corrected Text
--
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
<...>

Notes
-
In the 'Introductory Example', the POST body to the par endpoint contains an 
unnecessary '&' at the start. (It's perhaps technically valid, but could 
potentially confuse readers.)

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC9126 (draft-ietf-oauth-par-10)
--
Title   : OAuth 2.0 Pushed Authorization Requests
Publication Date: September 2021
Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. 
Skokan
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7519 (7114)

[RFC Errata System]

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7114

--
Type: Editorial
Reported by: SaiZinLinOo 

Section: 7

Original Text
-
Deleted License Blocked

Corrected Text
--
Delete licensed Blocked 

Notes
-
Thanks

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC8252 (7085)

[RFC Errata System]

The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7085

--
Type: Technical
Reported by: Keepn 

Section: Global

Original Text
-
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "SFSafariViewController" class
or its successor "SFAuthenticationSession", which implement the in-
app browser tab pattern.  Safari can be used to handle requests on
old versions of iOS without in-app browser tab functionality

Corrected Text
--
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "ASWebAuthenticationSession"
class or its successors "SFAuthenticationSession" and
"SFSafariViewController", which implement the in-app browser tab
pattern.  The first of these allows calls to a handler registered
for the AS URL, consistent with Section 7.2. The latter two classes,
now deprecated, can use Safari to handle requests on old versions of
iOS without in-app browser tab functionality.

Notes
-
SFAuthenticationSession documentation reflects deprecated status:

https://developer.apple.com/documentation/safariservices/sfauthenticationsession

Here's the documentation for ASWebAuthenticationSession:

https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession
--VERIFIER NOTES--
This sort of change to update for events since the time of publication is not 
appropriate for an erratum; errata are intended solely to indicate errors in a 
document that were errors at the time of publication. A revision of the 
document or a new document with an "Updates:" relationship would be more 
appropriate ways to indicate that the situation has changed.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC8707 (6810)

[RFC Errata System]

The following errata report has been verified for RFC8707,
"Resource Indicators for OAuth 2.0". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6810

--
Status: Verified
Type: Editorial

Reported by: Jan Goebel 
Date Reported: 2022-01-05
Verified by: Roman Danyliw (IESG)

Section: 4

Original Text
-
In typical OAuth deployments the authorization sever is in a position
to observe and track a significant amount of user and client behavior.

Corrected Text
--
In typical OAuth deployments, the authorization server is in a position
to observe and track a significant amount of user and client behavior.

Notes
-
1. typo: sever -> server
2. I think we also need a comma after "In typical OAuth deployments" because it 
is an introductory phrase, but maybe a native English speaker can confirm.

--
RFC8707 (draft-ietf-oauth-resource-indicators-08)
--
Title   : Resource Indicators for OAuth 2.0
Publication Date: February 2020
Author(s)   : B. Campbell, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC8707 (6810)

[RFC Errata System]

The following errata report has been submitted for RFC8707,
"Resource Indicators for OAuth 2.0".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6810

--
Type: Editorial
Reported by: Jan Goebel 

Section: 4

Original Text
-
In typical OAuth deployments the authorization sever is in a position
to observe and track a significant amount of user and client behavior.

Corrected Text
--
In typical OAuth deployments, the authorization server is in a position
to observe and track a significant amount of user and client behavior.

Notes
-
1. typo: sever -> server
2. I think we also need a comma after "In typical OAuth deployments" because it 
is an introductory phrase, but maybe a native English speaker can confirm.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8707 (draft-ietf-oauth-resource-indicators-08)
--
Title   : Resource Indicators for OAuth 2.0
Publication Date: February 2020
Author(s)   : B. Campbell, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (6741)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6741

--
Type: Technical
Reported by: Breanna <2022brdoo...@bedford.k12.va.us>

Section: GLOBAL

Original Text
-
Original

Corrected Text
--
Corrected

Notes
-
Notes

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[RFC Errata System]

The following errata report has been submitted for RFC9126,
"OAuth 2.0 Pushed Authorization Requests".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6711

--
Type: Technical
Reported by: Brian Campbell 

Section: 3.

Original Text
-
   Clients MAY use the "request" parameter as defined in JAR [RFC9101]
   to push a Request Object JWT to the authorization server.  The rules
   for processing, signing, and encryption of the Request Object as
   defined in JAR [RFC9101] apply.  Request parameters required by a
   given client authentication method are included in the "application/
   x-www-form-urlencoded" request directly and are the only parameters
   other than "request" in the form body (e.g., mutual TLS client
   authentication [RFC8705] uses the "client_id" HTTP request parameter,
   while JWT assertion-based client authentication [RFC7523] uses
   "client_assertion" and "client_assertion_type").  All other request
   parameters, i.e., those pertaining to the authorization request
   itself, MUST appear as claims of the JWT representing the
   authorization request.

Corrected Text
--
  Clients MAY use the request and client_id parameters as defined in 
  JAR [RFC9101] to push a Request Object JWT to the authorization 
  server. The rules for processing, signing, and encryption of the 
  Request Object as defined in JAR [RFC9101] apply. Request parameters
  required by a given client authentication method are included in the
  application/x-www-form-urlencoded request directly and are the only 
  parameters other than request and client_id in the form body (e.g.,
  JWT assertion-based client authentication [RFC7523] uses 
  "client_assertion" and "client_assertion_type") HTTP request
  parameters). All authorization request parameters, i.e., those 
  pertaining to the authorization request itself, MUST appear as
  claims of the JWT representing the authorization request.

Notes
-
That first paragraph of Sec 3 was not properly updated to come inline with JAR 
(now RFC9101) when it changed in draft -21 to require "client_id" in the 
authorization request in addition to in addition to "request" or "request_uri" 
- so is  somewhat ambiguous in maybe suggesting that "client_id" isn't 
required. But it is required based on how PAR works and RFC9101 requiring 
"client_id".

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC9126 (draft-ietf-oauth-par-10)
--
Title   : OAuth 2.0 Pushed Authorization Requests
Publication Date: September 2021
Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. 
Skokan
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

[RFC Errata System]

The following errata report has been submitted for RFC7009,
"OAuth 2.0 Token Revocation".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6663

--
Type: Technical
Reported by: Ashvin Narayanan 

Section: 2.1

Original Text
-
The client constructs the request by including the following
   parameters using the "application/x-www-form-urlencoded" format in
   the HTTP request entity-body:

   token   REQUIRED.  The token that the client wants to get revoked.

   token_type_hint  OPTIONAL.  A hint about the type of the token
   submitted for revocation.  Clients MAY pass this parameter in
   order to help the authorization server to optimize the token
   lookup.  If the server is unable to locate the token using
   the given hint, it MUST extend its search across all of its
   supported token types.  An authorization server MAY ignore
   this parameter, particularly if it is able to detect the
   token type automatically.  This specification defines two
   such values:

   * access_token: An access token as defined in [RFC6749],
 Section 1.4

   * refresh_token: A refresh token as defined in [RFC6749],
 Section 1.5

   Specific implementations, profiles, and extensions of this
   specification MAY define other values for this parameter
   using the registry defined in Section 4.1.2.

   The client also includes its authentication credentials as described
   in Section 2.3. of [RFC6749].

   For example, a client may request the revocation of a refresh token
   with the following request:

 POST /revoke HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

   The authorization server first validates the client credentials (in
   case of a confidential client) and then verifies whether the token
   was issued to the client making the revocation request.  If this
   validation fails, the request is refused and the client is informed
   of the error by the authorization server as described below.

Corrected Text
--
The client calls the revocation endpoint using an HTTP
   POST [RFC7231] request with the following parameters sent as
   "application/x-www-form-urlencoded" data in the request body:

   token   REQUIRED.  The token that the client wants to get revoked.

   token_type_hint  OPTIONAL.  A hint about the type of the token
   submitted for revocation.  Clients MAY pass this parameter in
   order to help the authorization server to optimize the token
   lookup.  If the server is unable to locate the token using
   the given hint, it MUST extend its search across all of its
   supported token types.  An authorization server MAY ignore
   this parameter, particularly if it is able to detect the
   token type automatically.  This specification defines two
   such values:

   * access_token: An access token as defined in [RFC6749],
 Section 1.4

   * refresh_token: A refresh token as defined in [RFC6749],
 Section 1.5

   Specific implementations, profiles, and extensions of this
   specification MAY define other values for this parameter
   using the registry defined in Section 4.1.2.

   The client MUST also include in the request, the access token it received 
   from the authorization server. It must do so in the same way as it  would  
   when accessing a protected resource, as describe in [RFC6749], Section 7.

   The following is a non-normative example request in which the client uses 
   its access token to revoke the associated refresh token:

 POST /revoke HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

   The following is a non-normative example request in which the client uses 
   its access token to revoke the same access token:

 POST /revoke HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

 token=czZCaGRSa3F0MzpnWDFmQmF0M2JW&token_type_hint=access_token

   The authorization server MUST validate the access token used by the
   client to authorize its call to the revocation endpoint, including 
   ensuring that it is not expired or revoked. 
   Additionally, the authorization server MUST also validate whether the
   access token used for authorization is part of the same grant  as the 
   token being revoked. If validation fails, the request is  refused and 
   the client is informe

[OAUTH-WG] [Errata Verified] RFC6749 (6613)

[RFC Errata System]

The following errata report has been verified for RFC6749,
"The OAuth 2.0 Authorization Framework". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6613

--
Status: Verified
Type: Editorial

Reported by: Daniel Barclay 
Date Reported: 2021-06-17
Verified by: Benjamin Kaduk (IESG)

Section: 3.3

Original Text
-
The value of the scope parameter is expressed as a list of space-delimited, 
case-sensitive strings

Corrected Text
--
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.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Rejected] RFC7519 (6622)

[RFC Errata System]

The following errata report has been rejected for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6622

--
Status: Rejected
Type: Editorial

Reported by: Padmanarayanan SR 
Date Reported: 2021-06-25
Rejected by: Benjamin Kaduk (IESG)

Section: 11

Original Text
-
All the security considerations in the JWS specification also apply
   to JWT, as do the JWE security considerations when encryption is
   employed.  In particular, Sections 10.12

Corrected Text
--
All the security considerations in the JWS specification also apply
   to JWT, as do the JWE security considerations when encryption is
   employed.  In particular, Sections 10.12

Notes
-
The link appears to be broken. It is intended to point to rfc7515#section-10.12 
whereas it is pointing to the non-existent section of the same document.
 --VERIFIER NOTES-- 
The "text" publication format (the only official format for RFCs prior to 8650) 
does not include HTML links, so the "original text" section of this report does 
not match the version of the RFC that this tool is used for.  Accordingly, the 
submission has to be rejected as invalid.

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7519 (6622)

[RFC Errata System]

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6622

--
Type: Editorial
Reported by: Padmanarayanan SR 

Section: 11

Original Text
-
All the security considerations in the JWS specification also apply
   to JWT, as do the JWE security considerations when encryption is
   employed.  In particular, Sections 10.12

Corrected Text
--
All the security considerations in the JWS specification also apply
   to JWT, as do the JWE security considerations when encryption is
   employed.  In particular, Sections 10.12

Notes
-
The link appears to be broken. It is intended to point to rfc7515#section-10.12 
whereas it is pointing to the non-existent section of the same document.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Rejected] RFC7591 (6619)

[RFC Errata System]

The following errata report has been rejected for RFC7591,
"OAuth 2.0 Dynamic Client Registration Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6619

--
Status: Rejected
Type: Editorial

Reported by: Dave Isaacs 
Date Reported: 2021-06-22
Rejected by: Benjamin Kaduk (IESG)

Section: 2

Original Text
-
token_endpoint_auth_method
  String indicator of the requested authentication method for the
  token endpoint.  Values defined by this specification are:

  *  "none": The client is a public client as defined in OAuth 2.0,
 Section 2.1, and does not have a client secret.

  *  "client_secret_post": The client uses the HTTP POST parameters
 as defined in OAuth 2.0, Section 2.3.1.

  *  "client_secret_basic": The client uses HTTP Basic as defined in
 OAuth 2.0, Section 2.3.1.

Corrected Text
--
Text unchanged. It is the links that are incorrect.

Notes
-
The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 
(twice)—link internally to the current RFC (RFC 7591) when they are supposed to 
link to the OAuth 2.0 RFC (RFC 6749).
 --VERIFIER NOTES-- 
 Errata reports are for the official version(s) of the document as published by 
the RFC Editor.  Prior to RFC 8650 the official version is the plain text copy; 
the html version with links is the result of running a script over the text 
copy, and so the "wrong link" here is more properly a bug in the script than an 
error in the RFC.

--
RFC7591 (draft-ietf-oauth-dyn-reg-30)
--
Title   : OAuth 2.0 Dynamic Client Registration Protocol
Publication Date: July 2015
Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619)

[RFC Errata System]

The following errata report has been submitted for RFC7591,
"OAuth 2.0 Dynamic Client Registration Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6619

--
Type: Editorial
Reported by: Dave Isaacs 

Section: 2

Original Text
-
token_endpoint_auth_method
  String indicator of the requested authentication method for the
  token endpoint.  Values defined by this specification are:

  *  "none": The client is a public client as defined in OAuth 2.0,
 Section 2.1, and does not have a client secret.

  *  "client_secret_post": The client uses the HTTP POST parameters
 as defined in OAuth 2.0, Section 2.3.1.

  *  "client_secret_basic": The client uses HTTP Basic as defined in
 OAuth 2.0, Section 2.3.1.

Corrected Text
--
Text unchanged. It is the links that are incorrect.

Notes
-
The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 
(twice)—link internally to the current RFC (RFC 7591) when they are supposed to 
link to the OAuth 2.0 RFC (RFC 6749).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7591 (draft-ietf-oauth-dyn-reg-30)
--
Title   : OAuth 2.0 Dynamic Client Registration Protocol
Publication Date: July 2015
Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (6615)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6615

--
Type: Editorial
Reported by: Daniel Barclay 

Section: GLOBAL

Original Text
-
Condition descriptions like "The authorization server ... validates the 
authorization grant, and if valid, issues an access token."
 

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (6614)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6614

--
Type: Editorial
Reported by: Daniel Barclay 

Section: 5.1

Original Text
-
... adding the following parameters to the entity-body of the HTTP response ...

Corrected Text
--
... 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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6613

--
Type: Editorial
Reported by: Daniel Barclay 

Section: 3.3

Original Text
-
The value of the scope parameter is expressed as a list of space-delimited, 
case-sensitive strings

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7636 (6471)

[RFC Errata System]

The following errata report has been submitted for RFC7636,
"Proof Key for Code Exchange by OAuth Public Clients".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6471

--
Type: Technical
Reported by: Tom Crossland 

Section: 7.1

Original Text
-
The client SHOULD create a "code_verifier" with a minimum of 256 bits
of entropy.  This can be done by having a suitable random number
generator create a 32-octet sequence.  The octet sequence can then be
base64url-encoded to produce a 43-octet URL safe string to use as a
"code_challenge" that has the required entropy.

Corrected Text
--
The client SHOULD create a "code_verifier" with a minimum of 256 bits
of entropy.  This can be done by having a suitable random number
generator create a 32-octet sequence.  The octet sequence can then be
base64url-encoded to produce a 43-octet URL safe string to use as a
"code_verifier" that has the required entropy.

Notes
-
The "32-octet sequence" referenced in the original text seems to be 
inconsistent with Section 4.1, which states that the minimum length of the 
code_verifier is 43 characters. It would be consistent by changing 
"code_challenge" to "code_verifier".

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7636 (draft-ietf-oauth-spop-15)
--
Title   : Proof Key for Code Exchange by OAuth Public Clients
Publication Date: September 2015
Author(s)   : N. Sakimura, Ed., J. Bradley, N. Agarwal
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Rejected] RFC8176 (6314)

[RFC Errata System]

The following errata report has been rejected for RFC8176,
"Authentication Method Reference Values".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6314

--
Status: Rejected
Type: Editorial

Reported by: David Brossaard 
Date Reported: 2020-10-20
Rejected by: Benjamin Kaduk (IESG)

Section: 1.

Original Text
-
For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

Corrected Text
--
For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

Notes
-
There is no text change but the link on "Section 2" points to section 2 in the 
same RFC rather than section 2 in the OpenID Connect Core 1.0 specification.
 --VERIFIER NOTES-- 
Errata reports are for reporting issues with the authoritative RFC version(s) 
as published by the RFC Editor.  RFC 8176 predates the usage of the "v3 XML" 
format, so the plain text version is the authoritative one, and thus questions 
of HTML links are irrelevant for it.

--
RFC8176 (draft-ietf-oauth-amr-values-08)
--
Title   : Authentication Method Reference Values
Publication Date: June 2017
Author(s)   : M. Jones, P. Hunt, A. Nadalin
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC8176 (6314)

[RFC Errata System]

The following errata report has been submitted for RFC8176,
"Authentication Method Reference Values".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6314

--
Type: Editorial
Reported by: David Brossaard 

Section: 1.

Original Text
-
For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

Corrected Text
--
For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

Notes
-
There is no text change but the link on "Section 2" points to section 2 in the 
same RFC rather than section 2 in the OpenID Connect Core 1.0 specification.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8176 (draft-ietf-oauth-amr-values-08)
--
Title   : Authentication Method Reference Values
Publication Date: June 2017
Author(s)   : M. Jones, P. Hunt, A. Nadalin
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Rejected] RFC7800 (6195)

[RFC Errata System]

The following errata report has been rejected for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6195

--
Status: Rejected
Type: Editorial

Reported by: Eric ramos 
Date Reported: 2020-05-31
Rejected by: Benjamin Kaduk (IESG)

Section: 7157

Original Text
-


Corrected Text
--
[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7517, May 2015,
  .


Notes
-

 --VERIFIER NOTES-- 
   Seems to be a (malformed?) duplicate of eid 6187

--
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--
Title   : Proof-of-Possession Key Semantics for JSON Web Tokens 
(JWTs)
Publication Date: April 2016
Author(s)   : M. Jones, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7800 (6195)

[RFC Errata System]

The following errata report has been submitted for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6195

--
Type: Editorial
Reported by: Eric ramos 

Section: 7157

Original Text
-


Corrected Text
--
[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7517, May 2015,
  .


Notes
-


Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--
Title   : Proof-of-Possession Key Semantics for JSON Web Tokens 
(JWTs)
Publication Date: April 2016
Author(s)   : M. Jones, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC7800 (6187)

[RFC Errata System]

The following errata report has been verified for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--
Status: Verified
Type: Editorial

Reported by: Pete Resnick 
Date Reported: 2020-05-26
Verified by: Benjamin Kaduk (IESG)

Section: 7.1

Original Text
-
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7157, May 2015,
  .


Corrected Text
--
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7517, May 2015,
  .


Notes
-
DOI has a typo: 7157 instead of 7517.

--
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--
Title   : Proof-of-Possession Key Semantics for JSON Web Tokens 
(JWTs)
Publication Date: April 2016
Author(s)   : M. Jones, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7800 (6187)

[RFC Errata System]

The following errata report has been submitted for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--
Type: Editorial
Reported by: Pete Resnick 

Section: 7.1

Original Text
-
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7157, May 2015,
  .


Corrected Text
--
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7517, May 2015,
  .


Notes
-
DOI has a typo: 7157 instead of 7517.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--
Title   : Proof-of-Possession Key Semantics for JSON Web Tokens 
(JWTs)
Publication Date: April 2016
Author(s)   : M. Jones, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)

[RFC Errata System]

The following errata report has been submitted for RFC7636,
"Proof Key for Code Exchange by OAuth Public Clients".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6179

--
Type: Technical
Reported by: Dmitry Khlebnikov 

Section: 7.3

Original Text
-
7.3.  Salting the code_challenge

   To reduce implementation complexity, salting is not used in the
   production of the code challenge, as the code verifier contains
   sufficient entropy to prevent brute-force attacks.  Concatenating a
   publicly known value to a code verifier (containing 256 bits of
   entropy) and then hashing it with SHA256 to produce a code challenge
   would not increase the number of attempts necessary to brute force a
   valid value for code verifier.

   While the "S256" transformation is like hashing a password, there are
   important differences.  Passwords tend to be relatively low-entropy
   words that can be hashed offline and the hash looked up in a
   dictionary.  By concatenating a unique though public value to each
   password prior to hashing, the dictionary space that an attacker
   needs to search is greatly expanded.

   Modern graphics processors now allow attackers to calculate hashes in
   real time faster than they could be looked up from a disk.  This
   eliminates the value of the salt in increasing the complexity of a
   brute-force attack for even low-entropy passwords.

Corrected Text
--


Notes
-
The section misrepresents the information about "salting" and the whole idea 
of "salting" is not applicable to a standalone hash.  I suggest to drop the 
entire
section as irrelevant to the rest of the standard.

For some reason the section implies that "salting" is protecting and increasing
entropy of a single hash, which is not what "salting" is about and is not the
reason for the technique.  The section is also making a speculative assumptions
about the low-entropy tendency in password hashes and makes an incorrect
conclusion on the benefits of "salting" for a password hash.

One could argue that the entropy and the complexity required to bruteforce a 
hash
and a salted hash for the same password (where the same hashing algorithm is
applied) are approximately the same in most cases (or just slightly more
complex for the salted version if the producer of the hash used a non-standard
routine in relation of mixing in the salt, e.g. instead of appending the salt
it inserts in in the middle of the password to be hashed).  In any case, that
public data is already known to the attacker and it is just a matter of the
configuration for the bruteforcing tool (such as JohnTheRipper) to incorporate
the knowledge.

Just as an illustration: consider an example password ('abc'), an example salt
('123'), and that the hash is generated using a concatinated version of these
two (e.g. HASH('abc123')).  Since the salt is included with the hash in plain
text, the bruteforcer would just need to set their tool up with the "^.*123$"
pattern making the salt essentially a string terminator which is not affecting
the bruteforce effort in any way).

More and more people I meet are confused about the problem area the "salting"
technique was invented to address: it is to increase the entropy of a set of
passwords, so the same password would not result in the same hash value, with
the primary goal is to prevent attackers to be able to re-use pre-calculated
hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to
make it impossible to quickly assess what hashes the attacker should focus on
(e.g.  when you have 1000 hashes and without salts you can easily spot that
some hashes are the same, which means breaking these one would gain much more
in comparison to unique hashes in the same set).

This being said, I am suggesting to drop section 7.3 completely as irrelevant, 
since what we currently have is very confusing and seeds unnecessary and
wrong ideas that "salting" can improve the security of a single hash by itself.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7636 (draft-ietf-oauth-spop-15)
--
Title   : Proof Key for Code Exchange by OAuth Public Clients
Publication Date: September 2015
Author(s)   : N. Sakimura, Ed., J. Bradley, N. Agarwal
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6750 (6161)

[RFC Errata System]

The following errata report has been submitted for RFC6750,
"The OAuth 2.0 Authorization Framework: Bearer Token Usage".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6161

--
Type: Editorial
Reported by: Herbert Valerio Riedel 

Section: 4

Original Text
-
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

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6750 (draft-ietf-oauth-v2-bearer-23)
--
Title   : The OAuth 2.0 Authorization Framework: Bearer Token Usage
Publication Date: October 2012
Author(s)   : M. Jones, D. Hardt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (6017)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6017

--
Type: Technical
Reported by: Michael Osipov <1983-01...@gmx.net>

Section: 2.3.1

Original Text
-
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.

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC6819 (5965)

[RFC Errata System]

The following errata report has been verified for RFC6819,
"OAuth 2.0 Threat Model and Security Considerations". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5965

--
Status: Verified
Type: Editorial

Reported by: David Piggott 
Date Reported: 2020-01-23
Verified by: Benjamin Kaduk (IESG)

Section: 4.4.1.2

Original Text
-
Store access token hashes only (Section 5.1.4.1.3).

Corrected Text
--
Store authorization code hashes only (Section 5.1.4.1.3).

Notes
-


--
RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
--
Title   : OAuth 2.0 Threat Model and Security Considerations
Publication Date: January 2013
Author(s)   : T. Lodderstedt, Ed., M. McGloin, P. Hunt
Category: INFORMATIONAL
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6819 (5965)

[RFC Errata System]

The following errata report has been submitted for RFC6819,
"OAuth 2.0 Threat Model and Security Considerations".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5965

--
Type: Editorial
Reported by: David Piggott 

Section: 4.4.1.2

Original Text
-
Store access token hashes only (Section 5.1.4.1.3).

Corrected Text
--
Store authorization code hashes only (Section 5.1.4.1.3).

Notes
-


Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
--
Title   : OAuth 2.0 Threat Model and Security Considerations
Publication Date: January 2013
Author(s)   : T. Lodderstedt, Ed., M. McGloin, P. Hunt
Category: INFORMATIONAL
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7519 (5906)

[RFC Errata System]

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5906

--
Type: Technical
Reported by: Erdem Memisyazici 

Section: 7.2

Original Text
-
   Finally, note that it is an application decision which algorithms may
   be used in a given context.  Even if a JWT can be successfully
   validated, unless the algorithms used in the JWT are acceptable to
   the application, it SHOULD reject the JWT.

Corrected Text
--
   Finally, note that it is an application decision which algorithms may
   be used in a given context.  Even if a JWT can be successfully
   validated, unless the algorithms used in the JWT are acceptable to
   the application, it MUST reject the JWT.

Notes
-
A vulnerability exists in certain implementations in the wild where 
applications simply look for valid JWT tokens which includes the "none" 
algorithm (https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a).  
A fairly popular library is auth0's java-jwt and at verification 
(https://github.com/auth0/java-jwt/blob/master/lib/src/main/java/com/auth0/jwt/JWTVerifier.java)
 quite reasonably you cannot initialize the class without an algorithm.  Given 
all capital SHOULD may be interpreted as a recommendation and as this RFC 
dictates the algorithm "none" MUST be implemented as a default algorithm under 
Section 8, one could argue JWTVerifier in the example doesn't have to 
verifyAlgorithm leading to the vulnerability pointed out in the first article 
while still complying by the specification.  There is no good reason why an 
algorithm unacceptable to the application must not be rejected as it does more 
harm than good and all popular library implementations interpret it as such.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (5873)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5873

--
Type: Technical
Reported by: Ludwig Seitz 

Section: 11.4

Original Text
-


Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Rejected] RFC8252 (5848)

[RFC Errata System]

The following errata report has been rejected for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5848

--
Status: Rejected
Type: Technical

Reported by: Bayard Bell 
Date Reported: 2019-08-26
Rejected by: Benjamin Kaduk (IESG)

Section: Appendix B.1

Original Text
-
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "SFSafariViewController" class
or its successor "SFAuthenticationSession", which implement the in-
app browser tab pattern.  Safari can be used to handle requests on
old versions of iOS without in-app browser tab functionality.

Corrected Text
--
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "ASWebAuthenticationSession"
class or its successors "SFAuthenticationSession" and
"SFSafariViewController", which implement the in-app browser tab
pattern.  The first of these allows calls to a handler registered
for the AS URL, consistent with Section 7.2. The latter two classes,
now deprecated, can use Safari to handle requests on old versions of
iOS without in-app browser tab functionality.

Notes
-
SFAuthenticationSession documentation reflects deprecated status:

https://developer.apple.com/documentation/safariservices/sfauthenticationsession

Here's the documentation for ASWebAuthenticationSession:

https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession
 --VERIFIER NOTES-- 
This sort of change to update for events since the time of publication is not 
appropriate for an erratum; errata are intended solely to indicate errors in a 
document that were errors at the time of publication.  A revision of the 
document or a new document with an "Updates:" relationship would be more 
appropriate ways to indicate that the situation has changed.

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC8252 (5848)

[RFC Errata System]

The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5848

--
Type: Technical
Reported by: Bayard Bell 

Section: Appendix B.1

Original Text
-
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "SFSafariViewController" class
or its successor "SFAuthenticationSession", which implement the in-
app browser tab pattern.  Safari can be used to handle requests on
old versions of iOS without in-app browser tab functionality.

Corrected Text
--
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "ASWebAuthenticationSession"
class or its successors "SFAuthenticationSession" and
"SFSafariViewController", which implement the in-app browser tab
pattern.  The first of these allows calls to a handler registered
for the AS URL, consistent with Section 7.2. The latter two classes,
now deprecated, can use Safari to handle requests on old versions of
iOS without in-app browser tab functionality.

Notes
-
SFAuthenticationSession documentation reflects deprecated status:

https://developer.apple.com/documentation/safariservices/sfauthenticationsession

Here's the documentation for ASWebAuthenticationSession:

https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC8628 (5840)

[RFC Errata System]

The following errata report has been submitted for RFC8628,
"OAuth 2.0 Device Authorization Grant".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5840

--
Type: Technical
Reported by: Konstantin Lapine 

Section: 5.2

Original Text
-
An attacker who guesses the device code would be able to potentially
   obtain the authorization code once the user completes the flow.

Corrected Text
--
An attacker who guesses the device code would be able to potentially
   obtain the access token once the user completes the flow.


Notes
-
The "authorization code" term is associated with Authorization Code Grant 
(defined in RFC 6749) and has the meaning of a temporary credential used by an 
OAuth 2.0 client to obtain the access token. Section 5.2 of RFC 8628 seems to 
refer to the steps of the device authorization flow during which the device 
code and the client identifier are exchanged for the access token (and the 
optional refresh token). 

Alternative correction:

"An attacker who guesses the device code would be able to potentially obtain 
the access token and the optional refresh token once the user completes the 
flow."

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8628 (draft-ietf-oauth-device-flow-15)
--
Title   : OAuth 2.0 Device Authorization Grant
Publication Date: August 2019
Author(s)   : W. Denniss, J. Bradley, M. Jones, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (5793)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5793

--
Type: Technical
Reported by: Martin May 

Section: 2.3.1

Original Text
-
   Alternatively, the authorization server MAY support including the
   client credentials in the request-body using the following
   parameters:

Corrected Text
--
   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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC8252 (5776)

[RFC Errata System]

The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5776

--
Type: Editorial
Reported by: Jan Dziekan 

Section: GLOBAL

Original Text
-


Corrected Text
--


Notes
-
RFC8252 references specific Sections of RFC6749, however urls are pointing to 
Sections in RFC8252.
For example, in Section 6 there is a statement "code grant type per Section 4.1 
of OAuth 2.0 [RFC6749]", where "Section 4.1" links to 
https://tools.ietf.org/html/rfc8252#section-4.1 instead of 
https://tools.ietf.org/html/rfc6749#section-4.1
I have found such misplaced links in the following sections: 6, 8.2, 8.4, 8.5, 
8.6, 8.12

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (5708)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5708

--
Type: Editorial
Reported by: Brian Campbell 

Section: 3.1 and 3.2

Original Text
-
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.

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC7636 (5687)

[RFC Errata System]

The following errata report has been verified for RFC7636,
"Proof Key for Code Exchange by OAuth Public Clients". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5687

--
Status: Verified
Type: Technical

Reported by: Collin Sauve 
Date Reported: 2019-04-09
Verified by: Benjamin Kaduk (IESG)

Section: 5

Original Text
-
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_verifier"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Corrected Text
--
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_challenge"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Notes
-
The code_verifier is not sent in the authorization request.

--
RFC7636 (draft-ietf-oauth-spop-15)
--
Title   : Proof Key for Code Exchange by OAuth Public Clients
Publication Date: September 2015
Author(s)   : N. Sakimura, Ed., J. Bradley, N. Agarwal
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC7636 (5687)

[RFC Errata System]

The following errata report has been submitted for RFC7636,
"Proof Key for Code Exchange by OAuth Public Clients".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5687

--
Type: Technical
Reported by: Collin Sauve 

Section: 5

Original Text
-
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_verifier"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Corrected Text
--
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_challenge"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Notes
-
The code_verifier is not sent in the authorization request.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7636 (draft-ietf-oauth-spop-15)
--
Title   : Proof Key for Code Exchange by OAuth Public Clients
Publication Date: September 2015
Author(s)   : N. Sakimura, Ed., J. Bradley, N. Agarwal
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7519 (5648)

[RFC Errata System]

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5648

--
Type: Editorial
Reported by: Andy Delcambre 

Section: 1

Original Text
-
JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.

   The suggested pronunciation of JWT is the same as the English word
   "jot".



Corrected Text
--
JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.


Notes
-
The suggested pronunciation is strange and confusing. It makes it hard to 
onboard new people verbally and always requires an explanation of the 
pronunciation. The standard already has a perfectly reasonable initialism of 
JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a 
pronunciation that does not map to the letters of the spec, and in my 
experience often leads to confusion when used.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (5379)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5379

--
Type: Editorial
Reported by: James Manger 

Section: 5.1, 4.2.2

Original Text
-
expires_in
 RECOMMENDED.  The lifetime in seconds of the access token.  For
 example, the value "3600" denotes ...

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6750 (5335)

[RFC Errata System]

The following errata report has been submitted for RFC6750,
"The OAuth 2.0 Authorization Framework: Bearer Token Usage".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5335

--
Type: Technical
Reported by: Kavindu Dodanduwa 

Section: 2.1

Original Text
-
b64token

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6750 (draft-ietf-oauth-v2-bearer-23)
--
Title   : The OAuth 2.0 Authorization Framework: Bearer Token Usage
Publication Date: October 2012
Author(s)   : M. Jones, D. Hardt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (5332)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5332

--
Type: Technical
Reported by: Donald F Coffin 

Section: 4.1

Original Text
-
(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.

Corrected Text
--
(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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (5234)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5234

--
Type: Technical
Reported by: Randip Kumar Malakar 

Section: 2.1.

Original Text
-
   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.

Corrected Text
--
   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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC8252 (5149)

[RFC Errata System]

The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5149

--
Type: Editorial
Reported by: Brian Vosburgh 

Section: 8.1

Original Text
-
Authorization servers SHOULD reject
   authorization requests from native apps that don't use PKCE by
   returning an error message, as defined in Section 4.4.1 of PKCE
   [RFC7636].

Corrected Text
--


Notes
-
The embedded link for the text "Section 4.4.1" points at Section 4.4.1 of 
*this* RFC (i.e. https://tools.ietf.org/html/rfc8252#section-4.4.1); but it 
should point at Section 4.4.1 of *RFC7636* (i.e. 
https://tools.ietf.org/html/rfc7636#section-4.4.1).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC8252 (5148)

[RFC Errata System]

The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5148

--
Type: Editorial
Reported by: Brian Vosburgh 

Section: 8.1

Original Text
-
Section 1 of PKCE [RFC7636] details how this limitation can be
   used to execute a code interception attack.

Corrected Text
--


Notes
-
The embedded link for the text "Section 1" points at Section 1 of *this* RFC 
(i.e. https://tools.ietf.org/html/rfc8252#section-1); but it should point at 
Section 1 of *RFC7636* (i.e. https://tools.ietf.org/html/rfc7636#section-1).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC8252 (5147)

[RFC Errata System]

The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5147

--
Type: Editorial
Reported by: Brian Vosburgh 

Section: 6

Original Text
-
Native apps needing user authorization create an authorization
   request URI with the authorization code grant type per Section 4.1 of
   OAuth 2.0 [RFC6749], using a redirect URI capable of being received
   by the native app.

Corrected Text
--


Notes
-
The embedded link for the text "Section 4.1" points at Section 4.1 of *this* 
RFC (i.e. https://tools.ietf.org/html/rfc8252#section-4.1); but, given the 
context of the surrounding text, it should point at Section 4.1 of *RFC6749* 
(i.e. https://tools.ietf.org/html/rfc6749#section-4.1).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8252 (draft-ietf-oauth-native-apps-12)
--
Title   : OAuth 2.0 for Native Apps
Publication Date: October 2017
Author(s)   : W. Denniss, J. Bradley
Category: BEST CURRENT PRACTICE
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (4945)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4945

--
Type: Editorial
Reported by: Abhimanyu Singh Gaur 

Section: 4.1.4

Original Text
-
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.

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (4819)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4819

--
Type: Technical
Reported by: Lars Kemmann 

Section: 4.2.2

Original Text
-
HTTP/1.1 302 Found
Location: http://example.com/cb#
  access_token=2YotnFZFEjr1zCsicMWpAA
  &state=xyz&token_type=example&expires_in=3600

Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7662 (4764)

[RFC Errata System]

The following errata report has been submitted for RFC7662,
"OAuth 2.0 Token Introspection".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7662&eid=4764

--
Type: Editorial
Reported by: Brian Campbell 

Section: 3.1

Original Text
-
OAuth registration client metadata names and descriptions are
registered by

Corrected Text
--
OAuth token introspection response parameters are registered by

Notes
-
The original text erroneously mentions registration of client metadata names, 
however, this RFC 7662 is about about token introspection and this section is 
about registration of token introspection response parameters (client metadata 
name registration is RFC 7591).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC7662 (draft-ietf-oauth-introspection-11)
--
Title   : OAuth 2.0 Token Introspection
Publication Date: October 2015
Author(s)   : J. Richer, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4749

--
Type: Technical
Reported by: Phil Hunt 

Section: 2.3.1

Original Text
-
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.

Corrected Text
--
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]."

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (4745)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4745

--
Type: Technical
Reported by: Clark Downum 

Section: 5.2

Original Text
-
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.

Corrected Text
--
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
   

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4697

--
Type: Editorial
Reported by: Ludwig Seitz 

Section: 7.1

Original Text
-
For example, the "bearer" token type defined in [RFC6750] is utilized
   by simply including the access token string in the request:


Corrected Text
--
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (4679)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4679

--
Type: Technical
Reported by: Yi EungJun 

Section: GLOBAL

Original Text
-
 Content-Type: application/json;charset=UTF-8


Corrected Text
--
 Content-Type: application/json

Notes
-
application/json does not have charset parameter.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Held for Document Update] RFC6749 (4206)

[RFC Errata System]

The following errata report has been held for document update 
for RFC6749, "The OAuth 2.0 Authorization Framework". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4206

--
Status: Held for Document Update
Type: Editorial

Reported by: Alexander Kempgen 
Date Reported: 2014-12-23
Held by: Kathleen Moriarty (IESG)

Section: 4.1

Original Text
-
   (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.

Corrected Text
--
   (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.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Verified] RFC6749 (3904)

[RFC Errata System]

The following errata report has been verified for RFC6749,
"The OAuth 2.0 Authorization Framework". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3904

--
Status: Verified
Type: Editorial

Reported by: Takahiko Kawasaki 
Date Reported: 2014-03-01
Verified by: Kathleen Moriarty (IESG)

Section: 11.2.2.

Original Text
-


Corrected Text
--
   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 
RFC6749 prior to final publication.  I\\'ve marked this as editorial since the 
IANA registry is normative, but also as verified.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Rejected] RFC6749 (3880)

[RFC Errata System]

The following errata report has been rejected for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880

--
Status: Rejected
Type: Technical

Reported by: Eriksen Costa 
Date Reported: 2014-02-04
Rejected by: Kathleen Moriarty (IESG)

Section: 10.16

Original Text
-
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.

Corrected Text
--
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

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Held for Document Update] RFC6749 (3780)

[RFC Errata System]

The following errata report has been held for document update 
for RFC6749, "The OAuth 2.0 Authorization Framework". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3780

--
Status: Held for Document Update
Type: Technical

Reported by: Torsten Lodderstedt 
Date Reported: 2013-11-04
Held by: Kathleen Moriarty (IESG)

Section: 3.2.1

Original Text
-
A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.

Corrected Text
--
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 \\"Hold 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.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Errata Held for Document Update] RFC6819 (4267)

[RFC Errata System]

The following errata report has been held for document update 
for RFC6819, "OAuth 2.0 Threat Model and Security Considerations". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267

--
Status: Held for Document Update
Type: Editorial

Reported by: David Gladstone 
Date Reported: 2015-02-09
Held by: Kathleen Moriarty (IESG)

Section: 4.4.1.11

Original Text
-
If an authorization server includes a nontrivial amount of entropy

Corrected Text
--
If an authorization server includes a trivial amount of entropy

Notes
-
The threat being described outlines a scenario where too little entropy is 
involved; countermeasures include using non-trivial amounts of entropy.

--
RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
--
Title   : OAuth 2.0 Threat Model and Security Considerations
Publication Date: January 2013
Author(s)   : T. Lodderstedt, Ed., M. McGloin, P. Hunt
Category: INFORMATIONAL
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6819 (4267)

[RFC Errata System]

The following errata report has been submitted for RFC6819,
"OAuth 2.0 Threat Model and Security Considerations".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267

--
Type: Editorial
Reported by: David Gladstone 

Section: 4.4.1.11

Original Text
-
If an authorization server includes a nontrivial amount of entropy

Corrected Text
--
If an authorization server includes a trivial amount of entropy

Notes
-
The threat being described outlines a scenario where too little entropy is 
involved; countermeasures include using non-trivial amounts of entropy.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
--
Title   : OAuth 2.0 Threat Model and Security Considerations
Publication Date: January 2013
Author(s)   : T. Lodderstedt, Ed., M. McGloin, P. Hunt
Category: INFORMATIONAL
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (4206)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4206

--
Type: Technical
Reported by: Alexander Kempgen 

Section: 4.1

Original Text
-
   (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.

Corrected Text
--
   (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
-
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.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (4024)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4024

--
Type: Editorial
Reported by: Ebrahim Jodeiri dallalan 

Section: s

Original Text
-
s

Corrected Text
--
s

Notes
-
s

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (3904)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3904

--
Type: Technical
Reported by: Takahiko Kawasaki 

Section: 11.2.2.

Original Text
-


Corrected Text
--
   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.

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880

--
Type: Technical
Reported by: Eriksen Costa 

Section: 10.16

Original Text
-
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.

Corrected Text
--
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.

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC7009 (3808)

[RFC Errata System]

The following errata report has been submitted for RFC7009,
"OAuth 2.0 Token Revocation".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7009&eid=3808

--
Type: Editorial
Reported by: Charles MARAIS 

Section: 2.1

Original Text
-
The link concerning the description of the client authentication
(Section 2.3) is :
http://tools.ietf.org/html/rfc7009#section-2.3

Corrected Text
--
The link concerning the description of the client authentication
(Section 2.3) should be :
http://tools.ietf.org/html/rfc6749#section-2.3

Notes
-
In fact the pointed document is not the right one.

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC7009 (draft-ietf-oauth-revocation-11)
--
Title   : OAuth 2.0 Token Revocation
Publication Date: August 2013
Author(s)   : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Technical Errata Reported] RFC6749 (3780)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3780

--
Type: Technical
Reported by: Torsten Lodderstedt 

Section: 3.2.1

Original Text
-
A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.

Corrected Text
--
A public client MAY use the "client_id" request parameter to identify 
itself when sending requests to the token endpoint.

Notes
-
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.

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (3500)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3500

--
Type: Editorial
Reported by: John Field 

Section: 4.1

Original Text
-
(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.

Corrected Text
--
(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)."

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3446

--
Type: Editorial
Reported by: Nov Matake 

Section: 1

Original Text
-
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.

Corrected Text
--
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".

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth