draft-ietf-oauth-discovery-07.txt   draft-ietf-oauth-discovery-08.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: March 11, 2018 NRI Expires: May 20, 2018 NRI
J. Bradley J. Bradley
Ping Identity Ping Identity
September 7, 2017 November 16, 2017
OAuth 2.0 Authorization Server Metadata OAuth 2.0 Authorization Server Metadata
draft-ietf-oauth-discovery-07 draft-ietf-oauth-discovery-08
Abstract Abstract
This specification defines a metadata format that an OAuth 2.0 client This specification defines a metadata format that an OAuth 2.0 client
can use to obtain the information needed to interact with an OAuth can use to obtain the information needed to interact with an OAuth
2.0 authorization server, including its endpoint locations and 2.0 authorization server, including its endpoint locations and
authorization server capabilities. authorization server capabilities.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2018. This Internet-Draft will expire on May 20, 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . 9 3.1. Authorization Server Metadata Request . . . . . . . . . . 9
3.2. Authorization Server Metadata Response . . . . . . . . . 9 3.2. Authorization Server Metadata Response . . . . . . . . . 9
3.3. Authorization Server Metadata Validation . . . . . . . . 10 3.3. Authorization Server Metadata Validation . . . . . . . . 10
4. String Operations . . . . . . . . . . . . . . . . . . . . . . 10 4. String Operations . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . 12
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 . . . . . . 13 7.1. OAuth Authorization Server Metadata Registry . . . . . . 14
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 . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Appendix B. Document History . . . . . . . . . . . . . . . . . . 21 Appendix B. Document History . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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
defined by "OpenID Connect Dynamic Client Registration 1.0" defined by "OpenID Connect Dynamic Client Registration 1.0"
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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
by the server origin via HTTPS or as a set of signed metadata values by the server origin via HTTPS or as a set of signed metadata values
represented as claims in a JSON Web Token (JWT) [JWT]. In the JWT 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 case, the issuer is vouching for the validity of the data about the
authorization server. This is analogous to the role that the authorization server. This is analogous to the role that the
Software Statement plays in OAuth Dynamic Client Registration Software Statement plays in OAuth Dynamic Client Registration
[RFC7591]. [RFC7591].
The means by which the client obtains the location of the The means by which the client chooses an authorization server is out
authorization server metadata document is out of scope. In some of scope. In some cases, its issuer identifier may be manually
cases, the location may be manually configured into the client. In configured into the client. In other cases, it may be dynamically
other cases, it may be dynamically discovered, for instance, through discovered, for instance, through the use of WebFinger [RFC7033], as
the use of WebFinger [RFC7033], as described in Section 2 of "OpenID described in Section 2 of "OpenID Connect Discovery 1.0"
Connect Discovery 1.0" [OpenID.Discovery]. [OpenID.Discovery].
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in 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 4, line 18 skipping to change at page 4, line 18
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].
authorization_endpoint authorization_endpoint
REQUIRED. URL of the authorization server's authorization URL of the authorization server's authorization endpoint
endpoint [RFC6749]. [RFC6749]. This is REQUIRED unless no grant types are supported
that use the authorization endpoint.
token_endpoint token_endpoint
URL of the authorization server's token endpoint [RFC6749]. This URL of the authorization server's token endpoint [RFC6749]. This
is REQUIRED unless only the implicit grant type is used. is REQUIRED unless only the implicit grant type is supported.
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. The referenced document contains the signing key(s) the document. The referenced document contains the signing key(s) the
client uses to validate signatures from the authorization server. client uses to validate signatures from the authorization server.
This URL MUST use the "https" scheme. The JWK Set MAY also This URL MUST use the "https" scheme. The JWK Set MAY also
contain the server's encryption key(s), which are used by clients contain the server's encryption key(s), which are used by clients
to encrypt requests to the server. When both signing and 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
skipping to change at page 8, line 20 skipping to change at page 8, line 26
signed_metadata signed_metadata
A JWT containing metadata values about the authorization server as A JWT containing metadata values about the authorization server as
claims. This is a string value consisting of the entire signed claims. This is a string value consisting of the entire signed
JWT. A "signed_metadata" metadata value SHOULD NOT appear as a JWT. A "signed_metadata" metadata value SHOULD NOT appear as a
claim in the JWT. claim in the JWT.
3. Obtaining Authorization Server Metadata 3. Obtaining Authorization Server Metadata
Authorization servers supporting metadata MUST make a JSON document Authorization servers supporting metadata MUST make a JSON document
containing metadata as specified in Section 2 available at a path containing metadata as specified in Section 2 available at a path
formed by concatenating a well-known URI string such as "/.well- formed by concatenating a well-known URI string to the authorization
known/oauth-authorization-server" to the authorization server's server's issuer identifier. By default, the well-known URI string
issuer identifier. This path MUST use the "https" scheme. The used is "/.well-known/oauth-authorization-server". This path MUST
syntax and semantics of ".well-known" are defined in RFC 5785 use the "https" scheme. The syntax and semantics of ".well-known"
[RFC5785]. The well-known URI path suffix used MUST be registered in are defined in RFC 5785 [RFC5785]. The well-known URI path suffix
the IANA "Well-Known URIs" registry [IANA.well-known]. used MUST be registered in 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
authorization server's issuer identifier. authorization server's issuer identifier. Alternatively, many such
applications will use the default well-known URI string "/.well-
known/oauth-authorization-server", which is the right choice for
general-purpose OAuth authorization servers, and not register an
application-specific one.
An OAuth 2.0 application using this specification MUST specify what An OAuth 2.0 application using this specification MUST specify what
well-known URI string it will use for this purpose. The same well-known URI 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
skipping to change at page 11, line 33 skipping to change at page 11, line 43
by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the
reuse of these identifiers that appear to be OpenID-specific, their reuse of these identifiers that appear to be OpenID-specific, their
usage in this specification is actually referring to general OAuth usage in this specification is actually referring to general OAuth
2.0 features that are not specific to OpenID Connect. 2.0 features that are not specific to OpenID Connect.
6. Security Considerations 6. Security Considerations
6.1. TLS Requirements 6.1. TLS Requirements
Implementations MUST support TLS. Which version(s) ought to be Implementations MUST support TLS. Which version(s) ought to be
implemented will vary over time, and depend on the widespread implemented will vary over time and depend on the widespread
deployment and known security vulnerabilities at the time of deployment and known security vulnerabilities at the time of
implementation. The authorization server MUST support TLS version implementation. The authorization server MUST support TLS version
1.2 [RFC5246] and MAY support additional transport-layer security 1.2 [RFC5246] and MAY support additional transport-layer security
mechanisms meeting its security requirements. When using TLS, the mechanisms meeting its security requirements. When using TLS, the
client MUST perform a TLS/SSL server certificate check, per RFC 6125 client MUST perform a TLS/SSL server certificate check, per RFC 6125
[RFC6125]. Implementation security considerations can be found in [RFC6125]. Implementation security considerations can be found in
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
skipping to change at page 13, line 10 skipping to change at page 13, line 21
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.
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 [RFC8126] 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 Metadata: example"). Authorization Server Metadata: example").
skipping to change at page 19, line 16 skipping to change at page 19, line 29
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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<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,
<https://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, <https://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
skipping to change at page 20, line 23 skipping to change at page 20, line 31
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", [UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
[USA15] Davis, M. and K. Whistler, "Unicode Normalization Forms", [USA15] Davis, M. and K. Whistler, "Unicode Normalization Forms",
Unicode Standard Annex 15, June 2015, Unicode Standard Annex 15, June 2015,
<http://www.unicode.org/reports/tr15/>. <http://www.unicode.org/reports/tr15/>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-oauth-mix-up-mitigation] [I-D.ietf-oauth-mix-up-mitigation]
skipping to change at page 21, line 15 skipping to change at page 21, line 26
[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, Dynamic Client Registration 1.0", November 2014,
<http://openid.net/specs/ <http://openid.net/specs/
openid-connect-registration-1_0.html>. 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. This specification standardizes the de
facto usage of the metadata format defined by OpenID Connect
Discovery to publish OAuth authorization server metadata.
The authors would like to thank the following people for their The authors would like to thank the following people for their
reviews of this specification: Brian Campbell, William Denniss, reviews of this specification: Shwetha Bhandari, Brian Campbell,
Vladimir Dzhuvinov, Samuel Erdtman, George Fletcher, Phil Hunt, Tony Brian Carpenter, William Denniss, Vladimir Dzhuvinov, Donald
Nadalin, Eric Rescorla, Justin Richer, Hannes Tschofenig, and Hans Eastlake, Samuel Erdtman, George Fletcher, Dick Hardt, Phil Hunt,
Zandbelt. Tony Nadalin, Mark Nottingham, 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 ]]
-08
o Changed the "authorization_endpoint" to be REQUIRED only when
grant types are supported that use the authorization endpoint.
o Added the statement, to provide historical context, that this
specification standardizes the de facto usage of the metadata
format defined by OpenID Connect Discovery to publish OAuth
authorization server metadata.
o Applied clarifications suggested by Mark Nottingham about when
application-specific well-known suffixes are and are not
appropriate.
o Acknowledged additional reviewers.
-07 -07
o Applied clarifications suggested by EKR. 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
 End of changes. 20 change blocks. 
36 lines changed or deleted 61 lines changed or added

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