Errata

Status:

Reported

Type:

Technical

Reported By:

Kristina Yasuda

Date Reported:

2024-01-31

Section 2 says:

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

It should say:

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.

Status:

Reported

Type:

Technical

Reported By:

Wren Turkal

Date Reported:

2026-09-15

Section 3.1 and 3.2 says:

In the first example of Section 3.1, "https://example.com" is the issuer. Section 3.2 has an example response that identifies the issuer as "https://server.example.com".

It should say:

Section 3.2 should update the issuer for the example response to be "https://example.com"

Notes:

If I am understanding how the issuer is used to generate the well-known URL for the discovery document, it seems that the issuer in the response example in Section 3.2 should be "https://example.com" to match one of the examples in 3.1.

Section 6.2 also confirms that prefix for the URL for the metadata request and the issuer field in the discovery document must match exactly. Making the examples align with that would make it easier to understand.
 
I have seen many issuers in the wild that do not match the issuer derived from the discovery document URL, so it seems that this part of the standard is commonly violated. For example, of Google, Microsoft, and Quickbooks Online OAuth implementations, only the Google's implementation complies with the Section 6.2 guidance of matching issuer URL prefix and issuer field in the discovery doc.

Status:

Rejected

Type:

Editorial

Reported By:

Philip Wedemann

Date Reported:

2026-01-07

Rejected by:

RFC Editor

Date Rejected:

2026-12-01

Section 8.2 says:

[MIX-UP]   Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up
              Mitigation", Work in Progress, draft-ietf-oauth-mix-up-
              mitigation-01, July 2016.

It should say:

[RFC9207]  Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server 
Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022, <https://
www.rfc-editor.org/info/rfc9207>.

Notes:

[MIX-UP]  is not a draft anymore, but was accepted in RFC 9207
 --VERIFIER NOTES-- 
Reference was correct at the time of publication.