draft-ietf-oauth-discovery-02.txt   draft-ietf-oauth-discovery-03.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 22, 2016 NRI Expires: January 9, 2017 NRI
J. Bradley J. Bradley
Ping Identity Ping Identity
March 21, 2016 July 8, 2016
OAuth 2.0 Authorization Server Discovery Metadata OAuth 2.0 Authorization Server Discovery Metadata
draft-ietf-oauth-discovery-02 draft-ietf-oauth-discovery-03
Abstract Abstract
This specification defines a discovery metadata format that an OAuth This specification defines a discovery metadata format that an OAuth
2.0 client can use to obtain the information needed to interact with 2.0 client can use to obtain the information needed to interact with
an OAuth 2.0 authorization server, including its endpoint locations an OAuth 2.0 authorization server, including its endpoint locations
and authorization server capabilities. and 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 September 22, 2016. This Internet-Draft will expire on January 9, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . 4 2. Authorization Server Metadata . . . . . . . . . . . . . . . . 3
3. Obtaining Authorization Server Discovery Metadata . . . . . . 7 3. Obtaining Authorization Server Discovery Metadata . . . . . . 7
3.1. Authorization Server Discovery Metadata Request . . . . . 8 3.1. Authorization Server Discovery Metadata Request . . . . . 8
3.2. Authorization Server Discovery Metadata Response . . . . . 9 3.2. Authorization Server Discovery Metadata Response . . . . 8
3.3. Authorization Server Discovery Metadata Validation . . . . 10 3.3. Authorization Server Discovery Metadata Validation . . . 9
4. String Operations . . . . . . . . . . . . . . . . . . . . . . 10 4. String Operations . . . . . . . . . . . . . . . . . . . . . . 10
5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 11 5. Compatibility Notes . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 11 6.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 10
6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 12 6.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 11
6.3. Publishing Metadata in a Standard Format . . . . . . . . . 12 6.3. Publishing Metadata in a Standard Format . . . . . . . . 11
6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 12 6.4. Protected Resources . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. OAuth Authorization Server Discovery Metadata Registry . . 14 7.1. OAuth Authorization Server Discovery Metadata Registry . 13
7.1.1. Registration Template . . . . . . . . . . . . . . . . 14 7.1.1. Registration Template . . . . . . . . . . . . . . . . 13
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13
7.2. Updated Registration Instructions . . . . . . . . . . . . 18 7.2. Updated Registration Instructions . . . . . . . . . . . . 17
7.3. Well-Known URI Registry . . . . . . . . . . . . . . . . . 18 7.3. Well-Known URI Registry . . . . . . . . . . . . . . . . . 17
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Appendix B. Document History . . . . . . . . . . . . . . . . . . 22 Appendix B. Document History . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This specification generalizes the discovery metadata format defined This specification generalizes the discovery metadata format defined
by "OpenID Connect Discovery 1.0" [OpenID.Discovery] in a way that is by "OpenID Connect Discovery 1.0" [OpenID.Discovery] in a way that is
compatible with OpenID Connect Discovery, while being applicable to a compatible with OpenID Connect Discovery, while being applicable to a
wider set of OAuth 2.0 use cases. This is intentionally parallel to wider set of OAuth 2.0 use cases. This is intentionally parallel to
the way that the "OAuth 2.0 Dynamic Client Registration Protocol" the way that the "OAuth 2.0 Dynamic Client Registration Protocol"
[RFC7591] specification generalized the dynamic client registration [RFC7591] specification generalized the dynamic client registration
mechanisms defined by "OpenID Connect Dynamic Client Registration mechanisms defined by "OpenID Connect Dynamic Client Registration
skipping to change at page 8, line 4 skipping to change at page 7, line 29
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 3. Obtaining Authorization Server Discovery Metadata
Authorization servers supporting discovery MUST make a JSON document Authorization servers supporting discovery MUST make a JSON document
containing discovery metadata as specified in Section 2 available at containing discovery metadata as specified in Section 2 available at
a path formed by concatenating a well-known URI string such as a path formed by concatenating a well-known URI string such as
"/.well-known/oauth-authorization-server" to the authorization "/.well-known/oauth-authorization-server" to the authorization
server's issuer identifier. The syntax and semantics of server's issuer identifier. The syntax and semantics of ".well-
".well-known" are defined in RFC 5785 [RFC5785]. The well-known URI known" are defined in RFC 5785 [RFC5785]. The well-known URI path
path suffix used MUST be registered in the IANA "Well-Known URIs" suffix used MUST be registered in the IANA "Well-Known URIs" registry
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
by concatenating "/.well-known/example-configuration" to the by concatenating "/.well-known/example-configuration" to the
skipping to change at page 8, line 31 skipping to change at page 8, line 9
well-known URI string it will use for this purpose. The same well-known URI string 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 relative to 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 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 Section 5, despite the identifier "/.well-known/openid-
"/.well-known/openid-configuration", appearing to be OpenID-specific, configuration", appearing to be OpenID-specific, its usage in this
its usage in this specification is actually referring to a general specification is actually referring to a general OAuth 2.0 feature
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 Discovery Metadata Request
An authorization server discovery metadata document MUST be queried An authorization server discovery metadata document MUST be queried
using an HTTP "GET" request at the previously specified path. using an 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 discovery
metadata, since the issuer identifier contains no path component: metadata, since the issuer identifier contains no path component:
skipping to change at page 14, line 24 skipping to change at page 13, line 23
7.1.1. Registration Template 7.1.1. Registration Template
Discovery Metadata Name: Discovery 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: Discovery Metadata Description:
Brief description of the discovery metadata (e.g., "Issuer URL"). Brief description of the discovery metadata (e.g., "Issuer
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
skipping to change at page 18, line 4 skipping to change at page 16, line 47
o Discovery Metadata Description: JSON array containing a list of o Discovery Metadata Description: JSON array containing a list of
the JWS signing algorithms supported by the introspection endpoint the JWS signing algorithms supported by the introspection endpoint
for the signature on the JWT used to authenticate the client at for the signature on the JWT used to authenticate the client at
the introspection endpoint the 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 Discovery Metadata Name: "code_challenge_methods_supported"
o Discovery Metadata Description: PKCE code challenge methods o Discovery Metadata Description: PKCE code challenge methods
supported by this authorization server supported by this 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 ]]
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
o OAuth Token Endpoint Authentication Methods o OAuth Token Endpoint Authentication Methods
IANA has added a link to this specification in the Reference sections IANA has added a link to this specification in the Reference sections
of these registries. [[ RFC Editor: The above sentence is written in of these registries. [[ RFC Editor: The above sentence is written in
the past tense as it would appear in the final specification, even the past tense as it would appear in the final specification, even
though these links won't actually be created until after the IESG has though these links won't actually be created until after the IESG has
requested publication of the specification. Please delete this note requested publication of the specification. Please delete this note
after the links are in place. ]] after the links are in place. ]]
For these registries, the designated experts must reject registration For these registries, the designated experts must reject registration
requests in one registry for values already occurring in the other requests in one registry for values already occurring in the other
registry. This is necessary because the registry. This is necessary because the
"introspection_endpoint_auth_methods_supported" parameter allows for "introspection_endpoint_auth_methods_supported" parameter allows for
the use of values from either registry. That way, because the values the use of values from either registry. That way, because the values
skipping to change at page 18, line 51 skipping to change at page 17, line 49
o Specification document: Section 3 of [[ this specification ]] o Specification document: Section 3 of [[ this specification ]]
o Related information: (none) o Related information: (none)
8. References 8. References
8.1. Normative References 8.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
May 2015, <http://www.rfc-editor.org/info/bcp195>. 2015, <http://www.rfc-editor.org/info/bcp195>.
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<http://tools.ietf.org/html/rfc7518>. <http://tools.ietf.org/html/rfc7518>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://tools.ietf.org/html/rfc7516>. <http://tools.ietf.org/html/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/ [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
RFC7517, May 2015, <http://tools.ietf.org/html/rfc7517>. DOI 10.17487/RFC7517, May 2015,
<http://tools.ietf.org/html/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
May 2015, <http://tools.ietf.org/html/rfc7515>. 2015, <http://tools.ietf.org/html/rfc7515>.
[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.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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
<http://www.rfc-editor.org/info/rfc2246>. <http://www.rfc-editor.org/info/rfc2246>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[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", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://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, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://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, <http://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>. <http://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, Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
March 2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <http://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>. <http://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, <http://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, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
September 2013, <http://www.rfc-editor.org/info/rfc7033>. 2013, <http://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, Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
March 2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, [RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565,
DOI 10.17487/RFC7565, May 2015, DOI 10.17487/RFC7565, May 2015,
<http://www.rfc-editor.org/info/rfc7565>. <http://www.rfc-editor.org/info/rfc7565>.
[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>. <http://www.rfc-editor.org/info/rfc7591>.
skipping to change at page 21, line 30 skipping to change at page 20, line 30
<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]
Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up
Mitigation", draft-ietf-oauth-mix-up-mitigation-00 (work Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work
in progress), March 2016. in progress), July 2016.
[IANA.well-known] [IANA.well-known]
IANA, "Well-Known URIs", IANA, "Well-Known URIs",
<http://www.iana.org/assignments/well-known-uris>. <http://www.iana.org/assignments/well-known-uris>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014, C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Discovery] [OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0", November 2014, <http://openid.net/ Connect Discovery 1.0", November 2014,
specs/openid-connect-discovery-1_0.html>. <http://openid.net/specs/
openid-connect-discovery-1_0.html>.
[OpenID.Registration] [OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Dynamic Client Registration 1.0", November 2014, <http:// Dynamic Client Registration 1.0", November 2014,
openid.net/specs/openid-connect-registration-1_0.html>. <http://openid.net/specs/
openid-connect-registration-1_0.html>.
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.
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, and Justin Samuel Erdtman, George Fletcher, Phil Hunt, Tony Nadalin, Justin
Richer. 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 ]]
-03
o Changed term "issuer URL" to "issuer identifier" for terminology
consistency, paralleling the same terminology consistency change
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.
o Made "jwks_uri" and "registration_endpoint" OPTIONAL. o Made "jwks_uri" and "registration_endpoint" OPTIONAL.
o Defined the well-known URI string "/.well-known/oauth-
o Defined the well-known URI string authorization-server".
"/.well-known/oauth-authorization-server".
o Added security considerations about publishing authorization o Added security considerations about publishing authorization
server discovery metadata in a standard format. server discovery metadata in a standard format.
o Added security considerations about protected resources. o Added security considerations about protected resources.
o Added more information to the "grant_types_supported" and o Added more information to the "grant_types_supported" and
"response_types_supported" definitions. "response_types_supported" definitions.
o Referenced the working group Mix-Up Mitigation draft. o Referenced the working group Mix-Up Mitigation draft.
o Changed some example metadata values. o Changed some example metadata values.
o Acknowledged individuals for their contributions to the o Acknowledged individuals for their contributions to the
specification. specification.
-01 -01
o Removed WebFinger discovery. o Removed WebFinger discovery.
o Clarified the relationship between the issuer identifier URL and o Clarified the relationship between the issuer identifier URL and
the well-known URI path relative to it at which the discovery the well-known URI path relative to it at which the discovery
metadata document is located. metadata document is located.
-00 -00
o Created the initial working group version based on draft-jones-
o Created the initial working group version based on oauth-discovery-01, with no normative changes.
draft-jones-oauth-discovery-01, with no normative changes.
Authors' Addresses Authors' Addresses
Michael B. Jones Michael B. Jones
Microsoft Microsoft
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
Nat Sakimura Nat Sakimura
 End of changes. 34 change blocks. 
82 lines changed or deleted 82 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/