draft-ietf-oauth-discovery-08.txt   draft-ietf-oauth-discovery-09.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track N. Sakimura Intended status: Standards Track N. Sakimura
Expires: May 20, 2018 NRI Expires: August 30, 2018 NRI
J. Bradley J. Bradley
Ping Identity Ping Identity
November 16, 2017 February 26, 2018
OAuth 2.0 Authorization Server Metadata OAuth 2.0 Authorization Server Metadata
draft-ietf-oauth-discovery-08 draft-ietf-oauth-discovery-09
Abstract Abstract
This specification defines a metadata format that an OAuth 2.0 client This specification defines a metadata format that an OAuth 2.0 client
can use to obtain the information needed to interact with an OAuth can use to obtain the information needed to interact with an OAuth
2.0 authorization server, including its endpoint locations and 2.0 authorization server, including its endpoint locations and
authorization server capabilities. authorization server capabilities.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2018. This Internet-Draft will expire on August 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation and Conventions . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authorization Server Metadata . . . . . . . . . . . . . . . . 3 2. Authorization Server Metadata . . . . . . . . . . . . . . . . 4
2.1. Signed Authorization Server Metadata . . . . . . . . . . 7 2.1. Signed Authorization Server Metadata . . . . . . . . . . 7
3. Obtaining Authorization Server Metadata . . . . . . . . . . . 8 3. Obtaining Authorization Server Metadata . . . . . . . . . . . 8
3.1. Authorization Server Metadata Request . . . . . . . . . . 9 3.1. Authorization Server Metadata Request . . . . . . . . . . 9
3.2. Authorization Server Metadata Response . . . . . . . . . 9 3.2. Authorization Server Metadata Response . . . . . . . . . 9
3.3. Authorization Server Metadata Validation . . . . . . . . 10 3.3. Authorization Server Metadata Validation . . . . . . . . 10
4. String Operations . . . . . . . . . . . . . . . . . . . . . . 11 4. String Operations . . . . . . . . . . . . . . . . . . . . . . 11
5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 11 5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 11 6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 12
6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 12 6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 12
6.3. Publishing Metadata in a Standard Format . . . . . . . . 12 6.3. Publishing Metadata in a Standard Format . . . . . . . . 13
6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 12 6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. OAuth Authorization Server Metadata Registry . . . . . . 14 7.1. OAuth Authorization Server Metadata Registry . . . . . . 14
7.1.1. Registration Template . . . . . . . . . . . . . . . . 14 7.1.1. Registration Template . . . . . . . . . . . . . . . . 15
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 15
7.2. Updated Registration Instructions . . . . . . . . . . . . 17 7.2. Updated Registration Instructions . . . . . . . . . . . . 18
7.3. Well-Known URI Registry . . . . . . . . . . . . . . . . . 18 7.3. Well-Known URI Registry . . . . . . . . . . . . . . . . . 19
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Appendix B. Document History . . . . . . . . . . . . . . . . . . 21 Appendix B. Document History . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This specification generalizes the metadata format defined by "OpenID This specification generalizes the metadata format defined by "OpenID
Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible
with OpenID Connect Discovery, while being applicable to a wider set with OpenID Connect Discovery, while being applicable to a wider set
of OAuth 2.0 use cases. This is intentionally parallel to the way of OAuth 2.0 use cases. This is intentionally parallel to the way
that the "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] that the "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]
specification generalized the dynamic client registration mechanisms specification generalized the dynamic client registration mechanisms
defined by "OpenID Connect Dynamic Client Registration 1.0" defined by "OpenID Connect Dynamic Client Registration 1.0"
skipping to change at page 3, line 26 skipping to change at page 3, line 26
of scope. In some cases, its issuer identifier may be manually of scope. In some cases, its issuer identifier may be manually
configured into the client. In other cases, it may be dynamically configured into the client. In other cases, it may be dynamically
discovered, for instance, through the use of WebFinger [RFC7033], as discovered, for instance, through the use of WebFinger [RFC7033], as
described in Section 2 of "OpenID Connect Discovery 1.0" described in Section 2 of "OpenID Connect Discovery 1.0"
[OpenID.Discovery]. [OpenID.Discovery].
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in BCP
2119 [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption
(JWE) [JWE] data structures in this specification utilize the JWS (JWE) [JWE] data structures in this specification utilize the JWS
Compact Serialization or the JWE Compact Serialization; the JWS JSON Compact Serialization or the JWE Compact Serialization; the JWS JSON
Serialization and the JWE JSON Serialization are not used. Serialization and the JWE JSON Serialization are not used.
1.2. Terminology 1.2. Terminology
This specification uses the terms "Access Token", "Authorization This specification uses the terms "Access Token", "Authorization
Code", "Authorization Endpoint", "Authorization Grant", Code", "Authorization Endpoint", "Authorization Grant",
skipping to change at page 4, line 10 skipping to change at page 4, line 15
2. Authorization Server Metadata 2. Authorization Server Metadata
Authorization servers can have metadata describing their Authorization servers can have metadata describing their
configuration. The following authorization server metadata values configuration. The following authorization server metadata values
are used by this specification and are registered in the IANA "OAuth are used by this specification and are registered in the IANA "OAuth
Authorization Server Metadata" registry established in Section 7.1: Authorization Server Metadata" registry established in Section 7.1:
issuer issuer
REQUIRED. The authorization server's issuer identifier, which is REQUIRED. The authorization server's issuer identifier, which is
a URL that uses the "https" scheme and has no query or fragment a URL that uses the "https" scheme and has no query or fragment
components. This is the location where ".well-known" RFC 5785 components. Authorization server metadata is published at a
[RFC5785] resources containing information about the authorization ".well-known" RFC 5785 [RFC5785] location derived from this issuer
server are published. Using these well-known resources is identifier, as described in Section 3. The issuer identifier is
described in Section 3. The issuer identifier is used to prevent used to prevent authorization server mix-up attacks, as described
authorization server mix-up attacks, as described in "OAuth 2.0 in "OAuth 2.0 Mix-Up Mitigation"
Mix-Up Mitigation" [I-D.ietf-oauth-mix-up-mitigation]. [I-D.ietf-oauth-mix-up-mitigation].
authorization_endpoint authorization_endpoint
URL of the authorization server's authorization endpoint URL of the authorization server's authorization endpoint
[RFC6749]. This is REQUIRED unless no grant types are supported [RFC6749]. This is REQUIRED unless no grant types are supported
that use the authorization endpoint. that use the authorization endpoint.
token_endpoint token_endpoint
URL of the authorization server's token endpoint [RFC6749]. This URL of the authorization server's token endpoint [RFC6749]. This
is REQUIRED unless only the implicit grant type is supported. is REQUIRED unless only the implicit grant type is supported.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
signed_metadata signed_metadata
A JWT containing metadata values about the authorization server as A JWT containing metadata values about the authorization server as
claims. This is a string value consisting of the entire signed claims. This is a string value consisting of the entire signed
JWT. A "signed_metadata" metadata value SHOULD NOT appear as a JWT. A "signed_metadata" metadata value SHOULD NOT appear as a
claim in the JWT. claim in the JWT.
3. Obtaining Authorization Server Metadata 3. Obtaining Authorization Server Metadata
Authorization servers supporting metadata MUST make a JSON document Authorization servers supporting metadata MUST make a JSON document
containing metadata as specified in Section 2 available at a path containing metadata as specified in Section 2 available at a path
formed by concatenating a well-known URI string to the authorization formed by inserting a well-known URI string into the authorization
server's issuer identifier. By default, the well-known URI string server's issuer identifier between the host component and the path
used is "/.well-known/oauth-authorization-server". This path MUST component, if any. By default, the well-known URI string used is
use the "https" scheme. The syntax and semantics of ".well-known" "/.well-known/oauth-authorization-server". This path MUST use the
are defined in RFC 5785 [RFC5785]. The well-known URI path suffix "https" scheme. The syntax and semantics of ".well-known" are
used MUST be registered in the IANA "Well-Known URIs" registry defined in RFC 5785 [RFC5785]. The well-known URI suffix used MUST
be registered in the IANA "Well-Known URIs" registry
[IANA.well-known]. [IANA.well-known].
Different applications utilizing OAuth authorization servers in Different applications utilizing OAuth authorization servers in
application-specific ways may define and register different well- application-specific ways may define and register different well-
known URI path suffixes used to publish authorization server metadata known URI suffixes used to publish authorization server metadata as
as used by those applications. For instance, if the Example used by those applications. For instance, if the Example application
application uses an OAuth authorization server in an Example-specific uses an OAuth authorization server in an Example-specific way, and
way, and there are Example-specific metadata values that it needs to there are Example-specific metadata values that it needs to publish,
publish, then it might register and use the "example-configuration" then it might register and use the "example-configuration" URI suffix
URI path suffix and publish the metadata document at the path formed and publish the metadata document at the path formed by inserting
by concatenating "/.well-known/example-configuration" to the "/.well-known/example-configuration" between the host and path
authorization server's issuer identifier. Alternatively, many such components of the authorization server's issuer identifier.
applications will use the default well-known URI string "/.well- Alternatively, many such applications will use the default well-known
known/oauth-authorization-server", which is the right choice for URI string "/.well-known/oauth-authorization-server", which is the
general-purpose OAuth authorization servers, and not register an right choice for general-purpose OAuth authorization servers, and not
application-specific one. register an application-specific one.
An OAuth 2.0 application using this specification MUST specify what An OAuth 2.0 application using this specification MUST specify what
well-known URI string it will use for this purpose. The same well-known URI suffix it will use for this purpose. The same
authorization server MAY choose to publish its metadata at multiple authorization server MAY choose to publish its metadata at multiple
well-known locations relative to its issuer identifier, for example, well-known locations derived from its issuer identifier, for example,
publishing metadata at both "/.well-known/example-configuration" and publishing metadata at both "/.well-known/example-configuration" and
"/.well-known/oauth-authorization-server". "/.well-known/oauth-authorization-server".
Some OAuth applications will choose to use the well-known URI path Some OAuth applications will choose to use the well-known URI suffix
suffix "openid-configuration" and publish the metadata document at "openid-configuration". As described in Section 5, despite the
the path formed by concatenating "/.well-known/openid-configuration" identifier "/.well-known/openid-configuration", appearing to be
to the authorization server's issuer identifier. As described in OpenID-specific, its usage in this specification is actually
Section 5, despite the identifier "/.well-known/openid- referring to a general OAuth 2.0 feature that is not specific to
configuration", appearing to be OpenID-specific, its usage in this OpenID Connect.
specification is actually referring to a general OAuth 2.0 feature
that is not specific to OpenID Connect.
3.1. Authorization Server Metadata Request 3.1. Authorization Server Metadata Request
An authorization server metadata document MUST be queried using an An authorization server metadata document MUST be queried using an
HTTP "GET" request at the previously specified path. HTTP "GET" request at the previously specified path.
The client would make the following request when the issuer The client would make the following request when the issuer
identifier is "https://example.com" and the well-known URI path identifier is "https://example.com" and the well-known URI suffix is
suffix is "oauth-authorization-server" to obtain the metadata, since "oauth-authorization-server" to obtain the metadata, since the issuer
the issuer identifier contains no path component: identifier contains no path component:
GET /.well-known/oauth-authorization-server HTTP/1.1 GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com Host: example.com
If the issuer identifier value contains a path component, any If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before appending "/.well-known/" and terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI path suffix. The client would make the following the well-known URI suffix between the host component and the path
request when the issuer identifier is "https://example.com/issuer1" component. The client would make the following request when the
and the well-known URI path suffix is "oauth-authorization-server" to issuer identifier is "https://example.com/issuer1" and the well-known
obtain the metadata, since the issuer identifier contains a path URI suffix is "oauth-authorization-server" to obtain the metadata,
component: since the issuer identifier contains a path component:
GET /issuer1/.well-known/oauth-authorization-server HTTP/1.1 GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com Host: example.com
Using path components enables supporting multiple issuers per host. Using path components enables supporting multiple issuers per host.
This is required in some multi-tenant hosting configurations. This This is required in some multi-tenant hosting configurations. This
use of ".well-known" is for supporting multiple issuers per host; use of ".well-known" is for supporting multiple issuers per host;
unlike its use in RFC 5785 [RFC5785], it does not provide general unlike its use in RFC 5785 [RFC5785], it does not provide general
information about the host. information about the host.
3.2. Authorization Server Metadata Response 3.2. Authorization Server Metadata Response
skipping to change at page 10, line 50 skipping to change at page 10, line 49
["code", "code token"], ["code", "code token"],
"service_documentation": "service_documentation":
"http://server.example.com/service_documentation.html", "http://server.example.com/service_documentation.html",
"ui_locales_supported": "ui_locales_supported":
["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"] ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
} }
3.3. Authorization Server Metadata Validation 3.3. Authorization Server Metadata Validation
The "issuer" value returned MUST be identical to the authorization The "issuer" value returned MUST be identical to the authorization
server's issuer identifier value that was concatenated with the well- server's issuer identifier value into which the well-known URI string
known URI path suffix to create the URL used to retrieve the was inserted to create the URL used to retrieve the metadata. If
metadata. If these values are not identical, the data contained in these values are not identical, the data contained in the response
the response MUST NOT be used. MUST NOT be used.
4. String Operations 4. String Operations
Processing some OAuth 2.0 messages requires comparing values in the Processing some OAuth 2.0 messages requires comparing values in the
messages to known values. For example, the member names in the messages to known values. For example, the member names in the
metadata response might be compared to specific member names such as metadata response might be compared to specific member names such as
"issuer". Comparing Unicode [UNICODE] strings, however, has "issuer". Comparing Unicode [UNICODE] strings, however, has
significant security implications. significant security implications.
Therefore, comparisons between JSON strings and other Unicode strings Therefore, comparisons between JSON strings and other Unicode strings
skipping to change at page 11, line 28 skipping to change at page 11, line 28
1. Remove any JSON applied escaping to produce an array of Unicode 1. Remove any JSON applied escaping to produce an array of Unicode
code points. code points.
2. Unicode Normalization [USA15] MUST NOT be applied at any point to 2. Unicode Normalization [USA15] MUST NOT be applied at any point to
either the JSON string or to the string it is to be compared either the JSON string or to the string it is to be compared
against. against.
3. Comparisons between the two strings MUST be performed as a 3. Comparisons between the two strings MUST be performed as a
Unicode code point to code point equality comparison. Unicode code point to code point equality comparison.
Note that this is the same equality comparison procedure described in
Section 8.3 of [RFC7159].
5. Compatibility Notes 5. Compatibility Notes
The identifiers "/.well-known/openid-configuration", "op_policy_uri", The identifiers "/.well-known/openid-configuration", "op_policy_uri",
and "op_tos_uri" contain strings referring to the OpenID Connect and "op_tos_uri" contain strings referring to the OpenID Connect
[OpenID.Core] family of specifications that were originally defined [OpenID.Core] family of specifications that were originally defined
by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the
reuse of these identifiers that appear to be OpenID-specific, their reuse of these identifiers that appear to be OpenID-specific, their
usage in this specification is actually referring to general OAuth usage in this specification is actually referring to general OAuth
2.0 features that are not specific to OpenID Connect. 2.0 features that are not specific to OpenID Connect.
The algorithm for transforming the issuer identifier to an
authorization server metadata location defined in Section 3 is
equivalent to the corresponding transformation defined in Section 4
of "OpenID Connect Discovery 1.0" [OpenID.Discovery], provided that
the issuer identifier contains no path component. However, they are
different when there is a path component, because OpenID Connect
Discovery 1.0 specifies that the well-known URI string is appended to
the issuer identifier (e.g., "https://example.com/issuer1/.well-
known/openid-configuration"), whereas this specification specifies
that the well-known URI string is inserted before the path component
of the issuer identifier (e.g., "https://example.com/.well-known/
openid-configuration/issuer1").
Going forward, OAuth authorization server metadata locations should
use the transformation defined in this specification. However, when
deployed in legacy environments in which the OpenID Connect Discovery
1.0 transformation is already used, it may be necessary during a
transition period to publish metadata for issuer identifiers
containing a path component at both locations. During this
transition period, applications should first apply the transformation
defined in this specification and attempt to retrieve the
authorization server metadata from the resulting location; only if
the retrieval from that location fails should they fall back to
attempting to retrive it from the alternate location obtained using
the transformation defined by OpenID Connect Discovery 1.0. This
backwards-compatibility behavior should only be necessary when the
well-known URI suffix employed by the application is "openid-
configuration".
6. Security Considerations 6. Security Considerations
6.1. TLS Requirements 6.1. TLS Requirements
Implementations MUST support TLS. Which version(s) ought to be Implementations MUST support TLS. Which version(s) ought to be
implemented will vary over time and depend on the widespread implemented will vary over time and depend on the widespread
deployment and known security vulnerabilities at the time of deployment and known security vulnerabilities at the time of
implementation. The authorization server MUST support TLS version implementation. The authorization server MUST support TLS version
1.2 [RFC5246] and MAY support additional transport-layer security 1.2 [RFC5246] and MAY support additional transport-layer security
mechanisms meeting its security requirements. When using TLS, the mechanisms meeting its security requirements. When using TLS, the
skipping to change at page 14, line 16 skipping to change at page 14, line 49
Expert, that Expert should defer to the judgment of the other Expert, that Expert should defer to the judgment of the other
Experts. Experts.
7.1. OAuth Authorization Server Metadata Registry 7.1. OAuth Authorization Server Metadata Registry
This specification establishes the IANA "OAuth Authorization Server This specification establishes the IANA "OAuth Authorization Server
Metadata" registry for OAuth 2.0 authorization server metadata names. Metadata" registry for OAuth 2.0 authorization server metadata names.
The registry records the authorization server metadata member and a The registry records the authorization server metadata member and a
reference to the specification that defines it. reference to the specification that defines it.
The Designated Experts must either:
(a) require that metadata names and values being registered use only
printable ASCII characters excluding double quote ('"') and backslash
('\') (the Unicode characters with code points U+0021, U+0023 through
U+005B, and U+005D through U+007E), or
(b) if new metadata members or values are defined that use other code
points, require that their definitions specify the exact Unicode code
point sequences used to represent them. Furthermore, proposed
registrations that use Unicode code points that can only be
represented in JSON strings as escaped characters must not be
accepted.
7.1.1. Registration Template 7.1.1. Registration Template
Metadata Name: Metadata Name:
The name requested (e.g., "issuer"). This name is case-sensitive. The name requested (e.g., "issuer"). This name is case-sensitive.
Names may not match other registered names in a case-insensitive Names may not match other registered names in a case-insensitive
manner unless the Designated Experts state that there is a manner unless the Designated Experts state that there is a
compelling reason to allow an exception. compelling reason to allow an exception.
Metadata Description: Metadata Description:
Brief description of the metadata (e.g., "Issuer identifier URL"). Brief description of the metadata (e.g., "Issuer identifier URL").
skipping to change at page 20, line 36 skipping to change at page 21, line 36
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", [UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
[USA15] Davis, M. and K. Whistler, "Unicode Normalization Forms", [USA15] Davis, M. and K. Whistler, "Unicode Normalization Forms",
Unicode Standard Annex 15, June 2015, Unicode Standard Annex 15, June 2015,
<http://www.unicode.org/reports/tr15/>. <http://www.unicode.org/reports/tr15/>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-oauth-mix-up-mitigation] [I-D.ietf-oauth-mix-up-mitigation]
skipping to change at page 21, line 31 skipping to change at page 22, line 35
Appendix A. Acknowledgements Appendix A. Acknowledgements
This specification is based on the OpenID Connect Discovery 1.0 This specification is based on the OpenID Connect Discovery 1.0
specification, which was produced by the OpenID Connect working group specification, which was produced by the OpenID Connect working group
of the OpenID Foundation. This specification standardizes the de of the OpenID Foundation. This specification standardizes the de
facto usage of the metadata format defined by OpenID Connect facto usage of the metadata format defined by OpenID Connect
Discovery to publish OAuth authorization server metadata. Discovery to publish OAuth authorization server metadata.
The authors would like to thank the following people for their The authors would like to thank the following people for their
reviews of this specification: Shwetha Bhandari, Brian Campbell, reviews of this specification: Shwetha Bhandari, Ben Campbell, Brian
Brian Carpenter, William Denniss, Vladimir Dzhuvinov, Donald Campbell, Brian Carpenter, William Denniss, Vladimir Dzhuvinov,
Eastlake, Samuel Erdtman, George Fletcher, Dick Hardt, Phil Hunt, Donald Eastlake, Samuel Erdtman, George Fletcher, Dick Hardt, Phil
Tony Nadalin, Mark Nottingham, Eric Rescorla, Justin Richer, Hannes Hunt, Alexey Melnikov, Tony Nadalin, Mark Nottingham, Eric Rescorla,
Tschofenig, and Hans Zandbelt. Justin Richer, Adam Roach, Hannes Tschofenig, and Hans Zandbelt.
Appendix B. Document History Appendix B. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-09
o Revised the transformation between the issuer identifier and the
authorization server metadata location to conform to BCP 190, as
suggested by Adam Roach.
o Defined the characters allowed in registered metadata names and
values, as suggested by Alexey Melnikov.
o Changed to using the RFC 8174 boilerplate instead of the RFC 2119
boilerplate, as suggested by Ben Campbell.
o Acknowledged additional reviewers.
-08 -08
o Changed the "authorization_endpoint" to be REQUIRED only when o Changed the "authorization_endpoint" to be REQUIRED only when
grant types are supported that use the authorization endpoint. grant types are supported that use the authorization endpoint.
o Added the statement, to provide historical context, that this o Added the statement, to provide historical context, that this
specification standardizes the de facto usage of the metadata specification standardizes the de facto usage of the metadata
format defined by OpenID Connect Discovery to publish OAuth format defined by OpenID Connect Discovery to publish OAuth
authorization server metadata. authorization server metadata.
 End of changes. 26 change blocks. 
76 lines changed or deleted 140 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/