draft-ietf-oauth-discovery-03.txt   draft-ietf-oauth-discovery-04.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: January 9, 2017 NRI Expires: February 4, 2017 NRI
J. Bradley J. Bradley
Ping Identity Ping Identity
July 8, 2016 August 3, 2016
OAuth 2.0 Authorization Server Discovery Metadata OAuth 2.0 Authorization Server Metadata
draft-ietf-oauth-discovery-03 draft-ietf-oauth-discovery-04
Abstract Abstract
This specification defines a discovery metadata format that an OAuth This specification defines a metadata format that an OAuth 2.0 client
2.0 client can use to obtain the information needed to interact with can use to obtain the information needed to interact with an OAuth
an OAuth 2.0 authorization server, including its endpoint locations 2.0 authorization server, including its endpoint locations and
and authorization server capabilities. authorization server capabilities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 9, 2017. This Internet-Draft will expire on February 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . 3
3. Obtaining Authorization Server Discovery Metadata . . . . . . 7 2.1. Signed Authorization Server Metadata . . . . . . . . . . 7
3.1. Authorization Server Discovery Metadata Request . . . . . 8 3. Obtaining Authorization Server Metadata . . . . . . . . . . . 8
3.2. Authorization Server Discovery Metadata Response . . . . 8 3.1. Authorization Server Metadata Request . . . . . . . . . . 8
3.3. Authorization Server Discovery Metadata Validation . . . 9 3.2. Authorization Server Metadata Response . . . . . . . . . 9
3.3. Authorization Server Metadata Validation . . . . . . . . 10
4. String Operations . . . . . . . . . . . . . . . . . . . . . . 10 4. String Operations . . . . . . . . . . . . . . . . . . . . . . 10
5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 10 5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 10 6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 11
6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 11 6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 11
6.3. Publishing Metadata in a Standard Format . . . . . . . . 11 6.3. Publishing Metadata in a Standard Format . . . . . . . . 12
6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 11 6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. OAuth Authorization Server Discovery Metadata Registry . 13 7.1. OAuth Authorization Server Metadata Registry . . . . . . 14
7.1.1. Registration Template . . . . . . . . . . . . . . . . 13 7.1.1. Registration Template . . . . . . . . . . . . . . . . 14
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14
7.2. Updated Registration Instructions . . . . . . . . . . . . 17 7.2. Updated Registration Instructions . . . . . . . . . . . . 17
7.3. Well-Known URI Registry . . . . . . . . . . . . . . . . . 17 7.3. Well-Known URI Registry . . . . . . . . . . . . . . . . . 18
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This specification generalizes the discovery metadata format defined This specification generalizes the metadata format defined by "OpenID
by "OpenID Connect Discovery 1.0" [OpenID.Discovery] in a way that is Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible
compatible with OpenID Connect Discovery, while being applicable to a with OpenID Connect Discovery, while being applicable to a wider set
wider set of OAuth 2.0 use cases. This is intentionally parallel to of OAuth 2.0 use cases. This is intentionally parallel to the way
the way that the "OAuth 2.0 Dynamic Client Registration Protocol" that the "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]
[RFC7591] specification generalized the dynamic client registration specification generalized the dynamic client registration mechanisms
mechanisms defined by "OpenID Connect Dynamic Client Registration defined by "OpenID Connect Dynamic Client Registration 1.0"
1.0" [OpenID.Registration] in a way that was compatible with it. [OpenID.Registration] in a way that was compatible with it.
The discovery metadata for an authorization server is retrieved from The metadata for an authorization server is retrieved from a well-
a well-known location as a JSON [RFC7159] document, which declares known location as a JSON [RFC7159] document, which declares its
its endpoint locations and authorization server capabilities. This endpoint locations and authorization server capabilities. This
process is described in Section 3. process is described in Section 3.
This metadata can either be communicated in a self-asserted fashion
or as a set of signed metadata values represented as claims in a JSON
Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for
the validity of the data about the authorization server. This is
analogous to the role that the Software Statement plays in OAuth
Dynamic Client Registration [RFC7591].
The means by which the client obtains the location of the The means by which the client obtains the location of the
authorization server discovery metadata document is out of scope. In authorization server metadata document is out of scope. In some
some cases, the location may be manually configured into the client. cases, the location may be manually configured into the client. In
In other cases, it may be dynamically discovered, for instance, other cases, it may be dynamically discovered, for instance, through
through the use of WebFinger [RFC7033], as described in Section 2 of the use of WebFinger [RFC7033], as described in Section 2 of "OpenID
"OpenID Connect Discovery 1.0" [OpenID.Discovery]. Connect Discovery 1.0" [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 RFC
2119 [RFC2119]. 2119 [RFC2119].
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
skipping to change at page 3, line 44 skipping to change at page 3, line 51
[RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token [RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token
(JWT)" defined by JSON Web Token (JWT) [JWT], and the term "Response (JWT)" defined by JSON Web Token (JWT) [JWT], and the term "Response
Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices
[OAuth.Responses]. [OAuth.Responses].
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 Discovery Metadata" registry established in Authorization Server Metadata" registry established in Section 7.1:
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. This is the location where ".well-known" RFC 5785
[RFC5785] resources containing information about the authorization [RFC5785] resources containing information about the authorization
server are published. Using these well-known resources is server are published. Using these well-known resources is
described in Section 3. The issuer identifier is used to prevent described in Section 3. The issuer identifier is used to prevent
authorization server mix-up attacks, as described in "OAuth 2.0 authorization server mix-up attacks, as described in "OAuth 2.0
Mix-Up Mitigation" [I-D.ietf-oauth-mix-up-mitigation]. Mix-Up Mitigation" [I-D.ietf-oauth-mix-up-mitigation].
skipping to change at page 4, line 25 skipping to change at page 4, line 31
is REQUIRED unless only the implicit grant type is used. is REQUIRED unless only the implicit grant type is used.
jwks_uri jwks_uri
OPTIONAL. URL of the authorization server's JWK Set [JWK] OPTIONAL. URL of the authorization server's JWK Set [JWK]
document. This contains the signing key(s) the client uses to document. This contains the signing key(s) the client uses to
validate signatures from the authorization server. The JWK Set validate signatures from the authorization server. The JWK Set
MAY also contain the server's encryption key(s), which are used by MAY also contain the server's encryption key(s), which are used by
clients to encrypt requests to the server. When both signing and clients to encrypt requests to the server. When both signing and
encryption keys are made available, a "use" (public key use) encryption keys are made available, a "use" (public key use)
parameter value is REQUIRED for all keys in the referenced JWK Set parameter value is REQUIRED for all keys in the referenced JWK Set
to indicate each key's intended usage. Although some algorithms to indicate each key's intended usage.
allow the same key to be used for both signatures and encryption,
doing so is NOT RECOMMENDED, as it is less secure. The JWK "x5c"
parameter MAY be used to provide X.509 representations of keys
provided. When used, the bare key values MUST still be present
and MUST match those in the certificate.
registration_endpoint registration_endpoint
OPTIONAL. URL of the authorization server's OAuth 2.0 Dynamic OPTIONAL. URL of the authorization server's OAuth 2.0 Dynamic
Client Registration endpoint [RFC7591]. Client Registration endpoint [RFC7591].
scopes_supported scopes_supported
RECOMMENDED. JSON array containing a list of the OAuth 2.0 RECOMMENDED. JSON array containing a list of the OAuth 2.0
[RFC6749] "scope" values that this authorization server supports. [RFC6749] "scope" values that this authorization server supports.
Servers MAY choose not to advertise some supported scope values Servers MAY choose not to advertise some supported scope values
even when this parameter is used. even when this parameter is used.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
server's requirements on how the client can use the data provided server's requirements on how the client can use the data provided
by the authorization server. The registration process SHOULD by the authorization server. The registration process SHOULD
display this URL to the person registering the client if it is display this URL to the person registering the client if it is
given. As described in Section 5, despite the identifier given. As described in Section 5, despite the identifier
"op_policy_uri", appearing to be OpenID-specific, its usage in "op_policy_uri", appearing to be OpenID-specific, its usage in
this specification is actually referring to a general OAuth 2.0 this specification is actually referring to a general OAuth 2.0
feature that is not specific to OpenID Connect. feature that is not specific to OpenID Connect.
op_tos_uri op_tos_uri
OPTIONAL. URL that the authorization server provides to the OPTIONAL. URL that the authorization server provides to the
person registering the client to read about authorization server's person registering the client to read about the authorization
terms of service. The registration process SHOULD display this server's terms of service. The registration process SHOULD
URL to the person registering the client if it is given. As display this URL to the person registering the client if it is
described in Section 5, despite the identifier "op_tos_uri", given. As described in Section 5, despite the identifier
appearing to be OpenID-specific, its usage in this specification "op_tos_uri", appearing to be OpenID-specific, its usage in this
is actually referring to a general OAuth 2.0 feature that is not specification is actually referring to a general OAuth 2.0 feature
specific to OpenID Connect. that is not specific to OpenID Connect.
revocation_endpoint revocation_endpoint
OPTIONAL. URL of the authorization server's OAuth 2.0 revocation OPTIONAL. URL of the authorization server's OAuth 2.0 revocation
endpoint [RFC7009]. endpoint [RFC7009].
revocation_endpoint_auth_methods_supported revocation_endpoint_auth_methods_supported
OPTIONAL. JSON array containing a list of client authentication OPTIONAL. JSON array containing a list of client authentication
methods supported by this revocation endpoint. The valid client methods supported by this revocation endpoint. The valid client
authentication method values are those registered in the IANA authentication method values are those registered in the IANA
"OAuth Token Endpoint Authentication Methods" registry "OAuth Token Endpoint Authentication Methods" registry
skipping to change at page 7, line 19 skipping to change at page 7, line 19
NOT be used. NOT be used.
code_challenge_methods_supported code_challenge_methods_supported
OPTIONAL. JSON array containing a list of PKCE [RFC7636] code OPTIONAL. JSON array containing a list of PKCE [RFC7636] code
challenge methods supported by this authorization server. Code challenge methods supported by this authorization server. Code
challenge method values are used in the "code_challenge_method" challenge method values are used in the "code_challenge_method"
parameter defined in Section 4.3 of [RFC7636]. The valid code parameter defined in Section 4.3 of [RFC7636]. The valid code
challenge method values are those registered in the IANA "PKCE challenge method values are those registered in the IANA "PKCE
Code Challenge Methods" registry [IANA.OAuth.Parameters]. Code Challenge Methods" registry [IANA.OAuth.Parameters].
protected_resources
OPTIONAL. JSON array containing a list of resource identifiers
for OAuth protected resources, as defined in
[OAuth.ResourceMetadata], for protected resources that can be used
with this authorization server. Authorization servers MAY choose
not to advertise some supported protected resources even when this
parameter is used. In some use cases, the set of protected
resources will not be enumerable, in which case this metadata
parameter would not be used.
Additional authorization server metadata parameters MAY also be used. Additional authorization server metadata parameters MAY also be used.
Some are defined by other specifications, such as OpenID Connect Some are defined by other specifications, such as OpenID Connect
Discovery 1.0 [OpenID.Discovery]. Discovery 1.0 [OpenID.Discovery].
3. Obtaining Authorization Server Discovery Metadata 2.1. Signed Authorization Server Metadata
Authorization servers supporting discovery MUST make a JSON document In addition to JSON elements, metadata values MAY also be provided as
containing discovery metadata as specified in Section 2 available at a "signed_metadata" value, which is a JSON Web Token (JWT) [JWT] that
a path formed by concatenating a well-known URI string such as asserts metadata values about the authorization server as a bundle.
"/.well-known/oauth-authorization-server" to the authorization A set of claims that can be used in signed metadata are defined in
server's issuer identifier. The syntax and semantics of ".well- Section 2. The signed metadata MUST be digitally signed or MACed
known" are defined in RFC 5785 [RFC5785]. The well-known URI path using JSON Web Signature (JWS) [JWS] and MUST contain an "iss"
suffix used MUST be registered in the IANA "Well-Known URIs" registry (issuer) claim denoting the party attesting to the claims in the
signed metadata. Consumers of the metadata MAY ignore the signed
metadata if they do not support this feature. If the consumer of the
metadata supports signed metadata, metadata values conveyed in the
signed metadata MUST take precedence over those conveyed using plain
JSON elements.
Signed metadata is included in the authorization server metadata JSON
object using this OPTIONAL member:
signed_metadata
A JWT containing metadata values about the authorization server as
claims. This is a string value consisting of the entire signed
JWT. A "signed_metadata" metadata value SHOULD NOT appear as a
claim in the JWT.
3. Obtaining Authorization Server Metadata
Authorization servers supporting metadata MUST make a JSON document
containing metadata as specified in Section 2 available at a path
formed by concatenating a well-known URI string such as "/.well-
known/oauth-authorization-server" to the authorization server's
issuer identifier. The syntax and semantics of ".well-known" are
defined in RFC 5785 [RFC5785]. The well-known URI path 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 path suffixes used to publish authorization server metadata
as used by those applications. For instance, if the Example as used by those applications. For instance, if the Example
application uses an OAuth authorization server in an Example-specific application uses an OAuth authorization server in an Example-specific
way, and there are Example-specific metadata values that it needs to way, and there are Example-specific metadata values that it needs to
publish, then it might register and use the "example-configuration" publish, then it might register and use the "example-configuration"
URI path suffix and publish the metadata document at the path formed URI path suffix and publish the metadata document at the path formed
skipping to change at page 8, line 14 skipping to change at page 8, line 47
Some OAuth applications will choose to use the well-known URI path Some OAuth applications will choose to use the well-known URI path
suffix "openid-configuration" and publish the metadata document at suffix "openid-configuration" and publish the metadata document at
the path formed by concatenating "/.well-known/openid-configuration" the path formed by concatenating "/.well-known/openid-configuration"
to the authorization server's issuer identifier. As described in to the authorization server's issuer identifier. As described in
Section 5, despite the identifier "/.well-known/openid- Section 5, despite the identifier "/.well-known/openid-
configuration", appearing to be OpenID-specific, its usage in this configuration", appearing to be OpenID-specific, its usage in this
specification is actually referring to a general OAuth 2.0 feature specification is actually referring to a general OAuth 2.0 feature
that is not specific to OpenID Connect. that is not specific to OpenID Connect.
3.1. Authorization Server Discovery Metadata Request 3.1. Authorization Server Metadata Request
An authorization server discovery metadata document MUST be queried An authorization server metadata document MUST be queried using an
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 path
suffix is "oauth-authorization-server" to obtain the discovery suffix is "oauth-authorization-server" to obtain the metadata, since
metadata, since the issuer identifier contains no path component: the issuer 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 appending "/.well-known/" and
the well-known URI path suffix. The client would make the following the well-known URI path suffix. The client would make the following
request when the issuer identifier is "https://example.com/issuer1" request when the issuer identifier is "https://example.com/issuer1"
and the well-known URI path suffix is "oauth-authorization-server" to and the well-known URI path suffix is "oauth-authorization-server" to
obtain the discovery metadata, since the issuer identifier contains a obtain the metadata, since the issuer identifier contains a path
path component: component:
GET /issuer1/.well-known/oauth-authorization-server HTTP/1.1 GET /issuer1/.well-known/oauth-authorization-server 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 Discovery Metadata Response 3.2. Authorization Server Metadata Response
The response is a set of claims about the authorization server's The response is a set of claims about the authorization server's
configuration, including all necessary endpoints and public key configuration, including all necessary endpoints and public key
location information. A successful response MUST use the 200 OK HTTP location information. A successful response MUST use the 200 OK HTTP
status code and return a JSON object using the "application/json" status code and return a JSON object using the "application/json"
content type that contains a set of claims as its members that are a content type that contains a set of claims as its members that are a
subset of the metadata values defined in Section 2. Other claims MAY subset of the metadata values defined in Section 2. Other claims MAY
also be returned. also be returned.
Claims that return multiple values are represented as JSON arrays. Claims that return multiple values are represented as JSON arrays.
skipping to change at page 9, line 43 skipping to change at page 10, line 38
["openid", "profile", "email", "address", ["openid", "profile", "email", "address",
"phone", "offline_access"], "phone", "offline_access"],
"response_types_supported": "response_types_supported":
["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 Discovery 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 that was concatenated with the well-
known URI path suffix to create the URL used to retrieve the known URI path suffix to create the URL used to retrieve the
discovery metadata. If these values are not identical, the data metadata. If these values are not identical, the data contained in
contained in the response MUST NOT be used. the response 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
discovery metadata response might be compared to specific member metadata response might be compared to specific member names such as
names such as "issuer". Comparing Unicode [UNICODE] strings, "issuer". Comparing Unicode [UNICODE] strings, however, has
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
MUST be performed as specified below: MUST be performed as specified below:
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.
skipping to change at page 11, line 9 skipping to change at page 11, line 50
Recommendations for Secure Use of TLS and DTLS [BCP195]. Recommendations for Secure Use of TLS and DTLS [BCP195].
To protect against information disclosure and tampering, To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a confidentiality protection MUST be applied using TLS with a
ciphersuite that provides confidentiality and integrity protection. ciphersuite that provides confidentiality and integrity protection.
6.2. Impersonation Attacks 6.2. Impersonation Attacks
TLS certificate checking MUST be performed by the client, as TLS certificate checking MUST be performed by the client, as
described in Section 6.1, when making an authorization server described in Section 6.1, when making an authorization server
discovery metadata request. Checking that the server certificate is metadata request. Checking that the server certificate is valid for
valid for the issuer identifier URL prevents man-in-middle and DNS- the issuer identifier URL prevents man-in-middle and DNS-based
based attacks. These attacks could cause a client to be tricked into attacks. These attacks could cause a client to be tricked into using
using an attacker's keys and endpoints, which would enable an attacker's keys and endpoints, which would enable impersonation of
impersonation of the legitimate authorization server. If an attacker the legitimate authorization server. If an attacker can accomplish
can accomplish this, they can access the resources that the affected this, they can access the resources that the affected client has
client has access to using the authorization server that they are access to using the authorization server that they are impersonating.
impersonating.
An attacker may also attempt to impersonate an authorization server An attacker may also attempt to impersonate an authorization server
by publishing a discovery document that contains an "issuer" claim by publishing a metadata document that contains an "issuer" claim
using the issuer identifier URL of the authorization server being using the issuer identifier URL of the authorization server being
impersonated, but with its own endpoints and signing keys. This impersonated, but with its own endpoints and signing keys. This
would enable it to impersonate that authorization server, if accepted would enable it to impersonate that authorization server, if accepted
by the client. To prevent this, the client MUST ensure that the by the client. To prevent this, the client MUST ensure that the
issuer identifier URL it is using as the prefix for the discovery issuer identifier URL it is using as the prefix for the metadata
metadata request exactly matches the value of the "issuer" metadata request exactly matches the value of the "issuer" metadata value in
value in the authorization server discovery metadata document the authorization server metadata document received by the client.
received by the client.
6.3. Publishing Metadata in a Standard Format 6.3. Publishing Metadata in a Standard Format
Publishing information about the authorization server in a standard Publishing information about the authorization server in a standard
format makes it easier for both legitimate clients and attackers to format makes it easier for both legitimate clients and attackers to
use the authorization server. Whether an authorization server use the authorization server. Whether an authorization server
publishes its metadata in an ad-hoc manner or in the standard format publishes its metadata in an ad-hoc manner or in the standard format
defined by this specification, the same defenses against attacks that defined by this specification, the same defenses against attacks that
might be mounted that use this information should be applied. might be mounted that use this information should be applied.
6.4. Protected Resources 6.4. Protected Resources
Secure determination of appropriate protected resource endpoints to Secure determination of appropriate protected resources to use with
use with an authorization server is out of scope of this an authorization server for all use cases is out of scope of this
specification. This specification assumes that the client has a specification. This specification assumes that the client has a
means of determining appropriate resource endpoint(s) to use with an means of determining appropriate protected resources to use with an
authorization server and that the client is using the correct authorization server and that the client is using the correct
discovery metadata for each authorization server. Implementers need metadata for each authorization server. Implementers need to be
to be aware that if an inappropriate resource endpoint is used by the aware that if an inappropriate protected resource is used by the
client, that an attacker may be able to act as a man-in-the-middle client, that an attacker may be able to act as a man-in-the-middle
proxy to a valid protected resource without it being detected by the proxy to a valid protected resource without it being detected by the
authorization server or the client. authorization server or the client.
The ways to determine the appropriate protected resources to use with The ways to determine the appropriate protected resources to use with
an authorization server are in general, application-dependent. For an authorization server are in general, application-dependent. For
instance, some authorization servers are used with a fixed protected instance, some authorization servers are used with a fixed protected
resource or set of protected resources, the locations of which may be resource or set of protected resources, the locations of which may be
well known, or which could be published as metadata values by the well known, or which could be published as metadata values by the
authorization server. In other cases, the set of resources that can authorization server. In other cases, the set of resources that can
be used with an authorization server can by dynamically changed by be used with an authorization server can by dynamically changed by
administrative actions. Many other means of determining appropriate administrative actions. Many other means of determining appropriate
associations between authorization servers and protected resources associations between authorization servers and protected resources
are also possible. are also possible.
To support use cases in which the set of legitimate protected
resources to use with the authorization server is fixed and
enumerable, this specification defines the "protected_resources"
metadata value, which enables explicitly listing them. Note that if
the set of legitimate authorization servers to use with a protected
resource is also fixed and enumerable, lists in the authorization
server metadata and protected resource metadata should be cross-
checked against one another for consistency when these lists are used
by the application profile.
7. IANA Considerations 7. IANA Considerations
The following registration procedure is used for the registry The following registration procedure is used for the registry
established by this specification. established by this specification.
Values are registered on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC5226] basis
after a two-week review period on the oauth-ext-review@ietf.org after a two-week review period on the oauth-ext-review@ietf.org
mailing list, on the advice of one or more Designated Experts. mailing list, on the advice of one or more Designated Experts.
However, to allow for the allocation of values prior to publication, However, to allow for the allocation of values prior to publication,
the Designated Experts may approve registration once they are the Designated Experts may approve registration once they are
satisfied that such a specification will be published. satisfied that such a specification will be published.
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register OAuth an appropriate subject (e.g., "Request to register OAuth
Authorization Server Discovery Metadata: example"). Authorization Server Metadata: example").
Within the review period, the Designated Experts will either approve Within the review period, the Designated Experts will either approve
or deny the registration request, communicating this decision to the or deny the registration request, communicating this decision to the
review list and IANA. Denials should include an explanation and, if review list and IANA. Denials should include an explanation and, if
applicable, suggestions as to how to make the request successful. applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the 21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution. iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Experts includes Criteria that should be applied by the Designated Experts includes
skipping to change at page 13, line 7 skipping to change at page 14, line 8
list. list.
It is suggested that multiple Designated Experts be appointed who are It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
this specification, in order to enable broadly-informed review of this specification, in order to enable broadly-informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
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 Discovery 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
Discovery Metadata" registry for OAuth 2.0 authorization server Metadata" registry for OAuth 2.0 authorization server metadata names.
metadata names. The registry records the authorization server The registry records the authorization server metadata member and a
metadata member and a reference to the specification that defines it. reference to the specification that defines it.
7.1.1. Registration Template 7.1.1. Registration Template
Discovery 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.
Discovery Metadata Description: Metadata Description:
Brief description of the discovery metadata (e.g., "Issuer Brief description of the metadata (e.g., "Issuer identifier URL").
identifier URL").
Change Controller: Change Controller:
For Standards Track RFCs, list the "IESG". For others, give the For Standards Track RFCs, list the "IESG". For others, give the
name of the responsible party. Other details (e.g., postal name of the responsible party. Other details (e.g., postal
address, email address, home page URI) may also be included. address, email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document or documents that specify the parameter, Reference to the document or documents that specify the parameter,
preferably including URIs that can be used to retrieve copies of preferably including URIs that can be used to retrieve copies of
the documents. An indication of the relevant sections may also be the documents. An indication of the relevant sections may also be
included but is not required. included but is not required.
7.1.2. Initial Registry Contents 7.1.2. Initial Registry Contents
o Discovery Metadata Name: "issuer" o Metadata Name: "issuer"
o Discovery Metadata Description: Authorization server's issuer o Metadata Description: Authorization server's issuer identifier URL
identifier URL
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "authorization_endpoint" o Metadata Name: "authorization_endpoint"
o Discovery Metadata Description: URL of the authorization server's o Metadata Description: URL of the authorization server's
authorization endpoint authorization endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "token_endpoint" o Metadata Name: "token_endpoint"
o Discovery Metadata Description: URL of the authorization server's o Metadata Description: URL of the authorization server's token
token endpoint endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "jwks_uri" o Metadata Name: "jwks_uri"
o Discovery Metadata Description: URL of the authorization server's o Metadata Description: URL of the authorization server's JWK Set
JWK Set document document
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "registration_endpoint" o Metadata Name: "registration_endpoint"
o Discovery Metadata Description: URL of the authorization server's o Metadata Description: URL of the authorization server's OAuth 2.0
OAuth 2.0 Dynamic Client Registration Endpoint Dynamic Client Registration Endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "scopes_supported" o Metadata Name: "scopes_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of the OAuth
the OAuth 2.0 "scope" values that this authorization server 2.0 "scope" values that this authorization server supports
supports
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "response_types_supported" o Metadata Name: "response_types_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of the OAuth
the OAuth 2.0 "response_type" values that this authorization 2.0 "response_type" values that this authorization server supports
server supports
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "response_modes_supported" o Metadata Name: "response_modes_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of the OAuth
the OAuth 2.0 "response_mode" values that this authorization 2.0 "response_mode" values that this authorization server supports
server supports
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "grant_types_supported" o Metadata Name: "grant_types_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of the OAuth
the OAuth 2.0 grant type values that this authorization server 2.0 grant type values that this authorization server supports
supports
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "token_endpoint_auth_methods_supported" o Metadata Name: "token_endpoint_auth_methods_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of client
client authentication methods supported by this token endpoint authentication methods supported by this token endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: o Metadata Name: "token_endpoint_auth_signing_alg_values_supported"
"token_endpoint_auth_signing_alg_values_supported" o Metadata Description: JSON array containing a list of the JWS
o Discovery Metadata Description: JSON array containing a list of signing algorithms supported by the token endpoint for the
the JWS signing algorithms supported by the token endpoint for the
signature on the JWT used to authenticate the client at the token signature on the JWT used to authenticate the client at the token
endpoint endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "service_documentation" o Metadata Name: "service_documentation"
o Discovery Metadata Description: URL of a page containing human- o Metadata Description: URL of a page containing human-readable
readable information that developers might want or need to know information that developers might want or need to know when using
when using the authorization server the authorization server
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "ui_locales_supported" o Metadata Name: "ui_locales_supported"
o Discovery Metadata Description: Languages and scripts supported o Metadata Description: Languages and scripts supported for the user
for the user interface, represented as a JSON array of BCP47 interface, represented as a JSON array of BCP47 language tag
language tag values values
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "op_policy_uri" o Metadata Name: "op_policy_uri"
o Discovery Metadata Description: URL that the authorization server o Metadata Description: URL that the authorization server provides
provides to the person registering the client to read about the to the person registering the client to read about the
authorization server's requirements on how the client can use the authorization server's requirements on how the client can use the
data provided by the authorization server data provided by the authorization server
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "op_tos_uri" o Metadata Name: "op_tos_uri"
o Discovery Metadata Description: URL that the authorization server o Metadata Description: URL that the authorization server provides
provides to the person registering the client to read about to the person registering the client to read about the
authorization server's terms of service authorization server's terms of service
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "revocation_endpoint" o Metadata Name: "revocation_endpoint"
o Discovery Metadata Description: URL of the authorization server's o Metadata Description: URL of the authorization server's OAuth 2.0
OAuth 2.0 revocation endpoint revocation endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name:
"revocation_endpoint_auth_methods_supported" o Metadata Name: "revocation_endpoint_auth_methods_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of client
client authentication methods supported by this revocation authentication methods supported by this revocation endpoint
endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Metadata Name:
o Discovery Metadata Name:
"revocation_endpoint_auth_signing_alg_values_supported" "revocation_endpoint_auth_signing_alg_values_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of the JWS
the JWS signing algorithms supported by the revocation endpoint signing algorithms supported by the revocation endpoint for the
for the signature on the JWT used to authenticate the client at signature on the JWT used to authenticate the client at the
the revocation endpoint revocation endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "introspection_endpoint" o Metadata Name: "introspection_endpoint"
o Discovery Metadata Description: URL of the authorization server's o Metadata Description: URL of the authorization server's OAuth 2.0
OAuth 2.0 introspection endpoint introspection endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: o Metadata Name: "introspection_endpoint_auth_methods_supported"
"introspection_endpoint_auth_methods_supported" o Metadata Description: JSON array containing a list of client
o Discovery Metadata Description: JSON array containing a list of authentication methods supported by this introspection endpoint
client authentication methods supported by this introspection
endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: o Metadata Name:
"introspection_endpoint_auth_signing_alg_values_supported" "introspection_endpoint_auth_signing_alg_values_supported"
o Discovery Metadata Description: JSON array containing a list of o Metadata Description: JSON array containing a list of the JWS
the JWS signing algorithms supported by the introspection endpoint signing algorithms supported by the introspection endpoint for the
for the signature on the JWT used to authenticate the client at signature on the JWT used to authenticate the client at the
the introspection endpoint introspection endpoint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
o Discovery Metadata Name: "code_challenge_methods_supported" o Metadata Name: "code_challenge_methods_supported"
o Discovery Metadata Description: PKCE code challenge methods o Metadata Description: PKCE code challenge methods supported by
supported by this authorization server this authorization server
o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]]
o Metadata Name: "protected_resources"
o Metadata Description: JSON array containing a list of resource
identifiers for OAuth protected resources
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2 of [[ this specification ]] o Specification Document(s): Section 2 of [[ this specification ]]
7.2. Updated Registration Instructions 7.2. Updated Registration Instructions
This specification adds to the instructions for the Designated This specification adds to the instructions for the Designated
Experts of the following IANA registries, both of which are in the Experts of the following IANA registries, both of which are in the
"OAuth Parameters" registry [IANA.OAuth.Parameters]: "OAuth Parameters" registry [IANA.OAuth.Parameters]:
o OAuth Access Token Types o OAuth Access Token Types
skipping to change at page 18, line 34 skipping to change at page 19, line 26
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://tools.ietf.org/html/rfc7519>. <http://tools.ietf.org/html/rfc7519>.
[OAuth.Post] [OAuth.Post]
Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
Mode", April 2015, <http://openid.net/specs/ Mode", April 2015, <http://openid.net/specs/
oauth-v2-form-post-response-mode-1_0.html>. oauth-v2-form-post-response-mode-1_0.html>.
[OAuth.ResourceMetadata]
Jones, M. and P. Hunt, "OAuth 2.0 Protected Resource
Metadata", draft-jones-oauth-resource-metadata-00 (work in
progress), August 2016, <http://tools.ietf.org/html/
draft-jones-oauth-resource-metadata-00>.
[OAuth.Responses] [OAuth.Responses]
de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
Jones, "OAuth 2.0 Multiple Response Type Encoding Jones, "OAuth 2.0 Multiple Response Type Encoding
Practices", February 2014, <http://openid.net/specs/ Practices", February 2014, <http://openid.net/specs/
oauth-v2-multiple-response-types-1_0.html>. oauth-v2-multiple-response-types-1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 21, line 20 skipping to change at page 22, line 20
Review comments resulting in substantive edits to the specification Review comments resulting in substantive edits to the specification
were made by Brian Campbell, William Denniss, Vladimir Dzhuvinov, were made by Brian Campbell, William Denniss, Vladimir Dzhuvinov,
Samuel Erdtman, George Fletcher, Phil Hunt, Tony Nadalin, Justin Samuel Erdtman, George Fletcher, Phil Hunt, Tony Nadalin, Justin
Richer, and Hans Zandbelt. Richer, 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 ]]
-04
o Added the ability to list protected resources with the
"protected_resources" element.
o Added ability to provide signed metadata with the
"signed_metadata" element.
o Removed "Discovery" from the name, since this is now just about
authorization server metadata.
-03 -03
o Changed term "issuer URL" to "issuer identifier" for terminology o Changed term "issuer URL" to "issuer identifier" for terminology
consistency, paralleling the same terminology consistency change consistency, paralleling the same terminology consistency change
in the mix-up mitigation spec. in the mix-up mitigation spec.
-02 -02
o Changed the title to OAuth 2.0 Authorization Server Discovery o Changed the title to OAuth 2.0 Authorization Server Discovery
Metadata. Metadata.
 End of changes. 65 change blocks. 
192 lines changed or deleted 245 lines changed or added

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