draft-ietf-oauth-discovery-06.txt   draft-ietf-oauth-discovery-07.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: September 11, 2017 NRI Expires: March 11, 2018 NRI
J. Bradley J. Bradley
Ping Identity Ping Identity
March 10, 2017 September 7, 2017
OAuth 2.0 Authorization Server Metadata OAuth 2.0 Authorization Server Metadata
draft-ietf-oauth-discovery-06 draft-ietf-oauth-discovery-07
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
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 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 September 11, 2017. This Internet-Draft will expire on March 11, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (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 . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . 10 4. String Operations . . . . . . . . . . . . . . . . . . . . . . 10
5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 11 5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 11 6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 11
6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 11 6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 11
6.3. Publishing Metadata in a Standard Format . . . . . . . . 12 6.3. Publishing Metadata in a Standard Format . . . . . . . . 12
6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 12 6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 8 skipping to change at page 3, line 8
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"
[OpenID.Registration] in a way that was compatible with it. [OpenID.Registration] in a way that was compatible with it.
The metadata for an authorization server is retrieved from a well- The metadata for an authorization server is retrieved from a well-
known location as a JSON [RFC7159] document, which declares its known location as a JSON [RFC7159] document, which declares 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 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 by the server origin via HTTPS or as a set of signed metadata values
Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for represented as claims in a JSON Web Token (JWT) [JWT]. In the JWT
the validity of the data about the authorization server. This is case, the issuer is vouching for the validity of the data about the
analogous to the role that the Software Statement plays in OAuth authorization server. This is analogous to the role that the
Dynamic Client Registration [RFC7591]. 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 metadata document is out of scope. In some authorization server metadata document is out of scope. In some
cases, the location may be manually configured into the client. In cases, the location may be manually configured into the client. In
other cases, it may be dynamically discovered, for instance, through other cases, it may be dynamically discovered, for instance, through
the use of WebFinger [RFC7033], as described in Section 2 of "OpenID the use of WebFinger [RFC7033], as described in Section 2 of "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
skipping to change at page 5, line 32 skipping to change at page 5, line 34
method values are used in the "token_endpoint_auth_method" method values are used in the "token_endpoint_auth_method"
parameter defined in Section 2 of [RFC7591]. If omitted, the parameter defined in Section 2 of [RFC7591]. If omitted, the
default is "client_secret_basic" -- the HTTP Basic Authentication default is "client_secret_basic" -- the HTTP Basic Authentication
Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749]. Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
token_endpoint_auth_signing_alg_values_supported token_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing OPTIONAL. JSON array containing a list of the JWS signing
algorithms ("alg" values) supported by the token endpoint for the algorithms ("alg" values) supported by the token endpoint for the
signature on the JWT [JWT] used to authenticate the client at the signature on the JWT [JWT] used to authenticate the client at the
token endpoint for the "private_key_jwt" and "client_secret_jwt" token endpoint for the "private_key_jwt" and "client_secret_jwt"
authentication methods. Servers SHOULD support "RS256". The authentication methods. This metadata entry MUST be present if
value "none" MUST NOT be used. either of these authentication methods are specified in the
"token_endpoint_auth_methods_supported" entry. No default
algorithms are implied if this entry is omitted. Servers SHOULD
support "RS256". The value "none" MUST NOT be used.
service_documentation service_documentation
OPTIONAL. URL of a page containing human-readable information OPTIONAL. URL of a page containing human-readable information
that developers might want or need to know when using the that developers might want or need to know when using the
authorization server. In particular, if the authorization server authorization server. In particular, if the authorization server
does not support Dynamic Client Registration, then information on does not support Dynamic Client Registration, then information on
how to register clients needs to be provided in this how to register clients needs to be provided in this
documentation. documentation.
ui_locales_supported ui_locales_supported
OPTIONAL. Languages and scripts supported for the user interface, OPTIONAL. Languages and scripts supported for the user interface,
represented as a JSON array of BCP47 [RFC5646] language tag represented as a JSON array of BCP47 [RFC5646] language tag
values. values. If omitted, the set of supported languages and scripts is
unspecified.
op_policy_uri op_policy_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 the authorization person registering the client to read about the authorization
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
skipping to change at page 6, line 30 skipping to change at page 6, line 35
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
[IANA.OAuth.Parameters]. [IANA.OAuth.Parameters]. If omitted, the default is
"client_secret_basic" -- the HTTP Basic Authentication Scheme
specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
revocation_endpoint_auth_signing_alg_values_supported revocation_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing OPTIONAL. JSON array containing a list of the JWS signing
algorithms ("alg" values) supported by the revocation endpoint for algorithms ("alg" values) supported by the revocation endpoint for
the signature on the JWT [JWT] used to authenticate the client at the signature on the JWT [JWT] used to authenticate the client at
the revocation endpoint for the "private_key_jwt" and the revocation endpoint for the "private_key_jwt" and
"client_secret_jwt" authentication methods. The value "none" MUST "client_secret_jwt" authentication methods. This metadata entry
NOT be used. MUST be present if either of these authentication methods are
specified in the "revocation_endpoint_auth_methods_supported"
entry. No default algorithms are implied if this entry is
omitted. The value "none" MUST NOT be used.
introspection_endpoint introspection_endpoint
OPTIONAL. URL of the authorization server's OAuth 2.0 OPTIONAL. URL of the authorization server's OAuth 2.0
introspection endpoint [RFC7662]. introspection endpoint [RFC7662].
introspection_endpoint_auth_methods_supported introspection_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 introspection endpoint. The valid methods supported by this introspection endpoint. The valid
client authentication method values are those registered in the client authentication method values are those registered in the
IANA "OAuth Token Endpoint Authentication Methods" registry IANA "OAuth Token Endpoint Authentication Methods" registry
[IANA.OAuth.Parameters] or those registered in the IANA "OAuth [IANA.OAuth.Parameters] or those registered in the IANA "OAuth
Access Token Types" registry [IANA.OAuth.Parameters]. (These Access Token Types" registry [IANA.OAuth.Parameters]. (These
values are and will remain distinct, due to Section 7.2.) values are and will remain distinct, due to Section 7.2.) If
omitted, the set of supported authentication methods MUST be
determined by other means.
introspection_endpoint_auth_signing_alg_values_supported introspection_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing OPTIONAL. JSON array containing a list of the JWS signing
algorithms ("alg" values) supported by the introspection endpoint algorithms ("alg" values) supported by the introspection endpoint
for the signature on the JWT [JWT] used to authenticate the client for the signature on the JWT [JWT] used to authenticate the client
at the introspection endpoint for the "private_key_jwt" and at the introspection endpoint for the "private_key_jwt" and
"client_secret_jwt" authentication methods. The value "none" MUST "client_secret_jwt" authentication methods. This metadata entry
NOT be used. MUST be present if either of these authentication methods are
specified in the "introspection_endpoint_auth_methods_supported"
entry. No default algorithms are implied if this entry is
omitted. The value "none" MUST 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]. If
omitted, the authorization server does not support PKCE.
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].
2.1. Signed Authorization Server Metadata 2.1. Signed Authorization Server Metadata
In addition to JSON elements, metadata values MAY also be provided as In addition to JSON elements, metadata values MAY also be provided as
a "signed_metadata" value, which is a JSON Web Token (JWT) [JWT] that a "signed_metadata" value, which is a JSON Web Token (JWT) [JWT] that
asserts metadata values about the authorization server as a bundle. asserts metadata values about the authorization server as a bundle.
skipping to change at page 8, line 11 skipping to change at page 8, line 22
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 such as "/.well- formed by concatenating a well-known URI string such as "/.well-
known/oauth-authorization-server" to the authorization server's known/oauth-authorization-server" to the authorization server's
issuer identifier. The syntax and semantics of ".well-known" are issuer identifier. This path MUST use the "https" scheme. The
defined in RFC 5785 [RFC5785]. The well-known URI path suffix used syntax and semantics of ".well-known" are defined in RFC 5785
MUST be registered in the IANA "Well-Known URIs" registry [RFC5785]. The well-known URI path suffix used MUST be registered in
[IANA.well-known]. the IANA "Well-Known URIs" registry [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
by concatenating "/.well-known/example-configuration" to the by concatenating "/.well-known/example-configuration" to the
skipping to change at page 19, line 14 skipping to change at page 19, line 14
[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>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <http://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <http://www.rfc-editor.org/info/rfc7009>. August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <http://www.rfc-editor.org/info/rfc7033>. 2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015, RFC 7591, DOI 10.17487/RFC7591, July 2015,
<http://www.rfc-editor.org/info/rfc7591>. <https://www.rfc-editor.org/info/rfc7591>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636, for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015, DOI 10.17487/RFC7636, September 2015,
<http://www.rfc-editor.org/info/rfc7636>. <https://www.rfc-editor.org/info/rfc7636>.
[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,
<http://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[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
skipping to change at page 21, line 20 skipping to change at page 21, line 20
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. of the OpenID Foundation.
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: Brian Campbell, William Denniss, reviews of this specification: Brian Campbell, William Denniss,
Vladimir Dzhuvinov, Samuel Erdtman, George Fletcher, Phil Hunt, Tony Vladimir Dzhuvinov, Samuel Erdtman, George Fletcher, Phil Hunt, Tony
Nadalin, Justin Richer, Hannes Tschofenig, and Hans Zandbelt. Nadalin, Eric Rescorla, Justin Richer, 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 ]]
-07
o Applied clarifications suggested by EKR.
-06 -06
o Incorporated resolutions to working group last call comments. o Incorporated resolutions to working group last call comments.
-05 -05
o Removed the "protected_resources" element and the reference to o Removed the "protected_resources" element and the reference to
draft-jones-oauth-resource-metadata. draft-jones-oauth-resource-metadata.
-04 -04
 End of changes. 32 change blocks. 
41 lines changed or deleted 62 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/