draft-ietf-oauth-discovery-04.txt   draft-ietf-oauth-discovery-05.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: February 4, 2017 NRI Expires: July 23, 2017 NRI
J. Bradley J. Bradley
Ping Identity Ping Identity
August 3, 2016 January 19, 2017
OAuth 2.0 Authorization Server Metadata OAuth 2.0 Authorization Server Metadata
draft-ietf-oauth-discovery-04 draft-ietf-oauth-discovery-05
Abstract Abstract
This specification defines a metadata format that an OAuth 2.0 client This specification defines a metadata format that an OAuth 2.0 client
can use to obtain the information needed to interact with an OAuth can use to obtain the information needed to interact with an OAuth
2.0 authorization server, including its endpoint locations and 2.0 authorization server, including its endpoint locations and
authorization server capabilities. authorization server capabilities.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 February 4, 2017. This Internet-Draft will expire on July 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 7
3.1. Authorization Server Metadata Request . . . . . . . . . . 8 3.1. Authorization Server Metadata Request . . . . . . . . . . 8
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
7.1. OAuth Authorization Server Metadata Registry . . . . . . 14 7.1. OAuth Authorization Server Metadata Registry . . . . . . 13
7.1.1. Registration Template . . . . . . . . . . . . . . . . 14 7.1.1. Registration Template . . . . . . . . . . . . . . . . 14
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 18 7.3. Well-Known URI Registry . . . . . . . . . . . . . . . . . 18
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Appendix B. Document History . . . . . . . . . . . . . . . . . . 22 Appendix B. Document History . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This specification generalizes the metadata format defined by "OpenID This specification generalizes the metadata format defined by "OpenID
Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible
with OpenID Connect Discovery, while being applicable to a wider set with OpenID Connect Discovery, while being applicable to a wider set
of OAuth 2.0 use cases. This is intentionally parallel to the way of OAuth 2.0 use cases. This is intentionally parallel to the way
that the "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] that the "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]
specification generalized the dynamic client registration mechanisms specification generalized the dynamic client registration mechanisms
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].
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.
A set of claims that can be used in signed metadata are defined in A set of claims that can be used in signed metadata are defined in
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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
skipping to change at page 17, line 40 skipping to change at page 17, line 29
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 Metadata Name: "code_challenge_methods_supported" o Metadata Name: "code_challenge_methods_supported"
o Metadata Description: PKCE code challenge methods supported by o Metadata Description: PKCE code challenge methods supported by
this authorization server 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 ]]
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 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
skipping to change at page 19, line 26 skipping to change at page 19, line 10
[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 22, line 20 skipping to change at page 21, line 48
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 ]]
-05
o Removed the "protected_resources" element and the reference to
draft-jones-oauth-resource-metadata.
-04 -04
o Added the ability to list protected resources with the o Added the ability to list protected resources with the
"protected_resources" element. "protected_resources" element.
o Added ability to provide signed metadata with the o Added ability to provide signed metadata with the
"signed_metadata" element. "signed_metadata" element.
o Removed "Discovery" from the name, since this is now just about o Removed "Discovery" from the name, since this is now just about
authorization server metadata. authorization server metadata.
-03 -03
 End of changes. 13 change blocks. 
41 lines changed or deleted 14 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/