draft-ietf-oauth-jwt-introspection-response-04.txt   draft-ietf-oauth-jwt-introspection-response-05.txt 
Open Authentication Protocol T. Lodderstedt, Ed. Open Authentication Protocol T. Lodderstedt, Ed.
Internet-Draft yes.com AG Internet-Draft yes.com AG
Intended status: Standards Track V. Dzhuvinov Intended status: Standards Track V. Dzhuvinov
Expires: January 23, 2020 Connect2id Ltd. Expires: January 24, 2020 Connect2id Ltd.
Jul 22, 2019 Jul 23, 2019
JWT Response for OAuth Token Introspection JWT Response for OAuth Token Introspection
draft-ietf-oauth-jwt-introspection-response-04 draft-ietf-oauth-jwt-introspection-response-05
Abstract Abstract
This draft proposes an additional JSON Web Token (JWT) based response This draft proposes an additional JSON Web Token (JWT) based response
for OAuth 2.0 Token Introspection. for OAuth 2.0 Token Introspection.
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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 January 23, 2020. This Internet-Draft will expire on January 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
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
2. Requesting a JWT Response . . . . . . . . . . . . . . . . . . 3 2. Requesting a JWT Response . . . . . . . . . . . . . . . . . . 3
3. JWT Response . . . . . . . . . . . . . . . . . . . . . . . . 3 3. JWT Response . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 4 4. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 5
5. Authorization Server Metadata . . . . . . . . . . . . . . . . 5 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6.1. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 6 6.1. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 6
6.2. Token Data Leakage . . . . . . . . . . . . . . . . . . . 6 6.2. Token Data Leakage . . . . . . . . . . . . . . . . . . . 7
6.3. Data Minimization . . . . . . . . . . . . . . . . . . . . 7 6.3. Keeping Token Data Confidential from OAuth Clients . . . 7
6.4. Logging and Audit of Introspection Activity . . . . . . . 7
6.5. Data Minimization . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. OAuth Dynamic Client Registration Metadata Registration . 7 8.1. OAuth Dynamic Client Registration Metadata Registration . 8
8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 7 8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8
8.2. OAuth Authorization Server Metadata Registration . . . . 8 8.2. OAuth Authorization Server Metadata Registration . . . . 8
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 8 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 8
8.3. OAuth Token Introspection Response . . . . . . . . . . . 8 8.3. OAuth Token Introspection Response . . . . . . . . . . . 9
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 9 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Document History . . . . . . . . . . . . . . . . . . 15 Appendix A. Document History . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
OAuth 2.0 Token Introspection [RFC7662] specifies a method for a OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
protected resource to query an OAuth 2.0 authorization server to protected resource to query an OAuth 2.0 authorization server to
determine the state of an access token and obtain data associated determine the state of an access token and obtain data associated
with the access token. This allows deployments to implement with the access token. This allows deployments to implement
identifier-based access tokens in an interoperable way. identifier-based access tokens in an interoperable way.
The introspection response, as specified in OAuth 2.0 Token The introspection response, as specified in OAuth 2.0 Token
skipping to change at page 3, line 5 skipping to change at page 3, line 7
where the authorization server assumes liability for the token's where the authorization server assumes liability for the token's
content. An example is a resource server using verified person data content. An example is a resource server using verified person data
to create certificates, which in turn are used to create qualified to create certificates, which in turn are used to create qualified
electronic signatures. electronic signatures.
In such use cases it may be useful or even required to return a In such use cases it may be useful or even required to return a
signed JWT as the introspection response. This specification extends signed JWT as the introspection response. This specification extends
the token introspection endpoint with the capability to return the token introspection endpoint with the capability to return
responses as JWTs. responses as JWTs.
1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Requesting a JWT Response 2. Requesting a JWT Response
A resource server requests to receive a JWT introspection response by A resource server requests to receive a JWT introspection response by
including an Accept header with content type "application/jwt" in the including an Accept header with content type "application/jwt" in the
introspection request. introspection request.
The following is a non-normative example request: The following is a non-normative example request:
POST /introspect HTTP/1.1 POST /introspect HTTP/1.1
Host: server.example.com Host: server.example.com
skipping to change at page 6, line 21 skipping to change at page 6, line 41
Such an attack can be prevented like any other token substitution Such an attack can be prevented like any other token substitution
attack. The authorization server MUST include the claims "iss" and attack. The authorization server MUST include the claims "iss" and
"aud" in each JWT introspection response, with the "iss" value set to "aud" in each JWT introspection response, with the "iss" value set to
the authorization server's issuer URL and the "aud" value set to the the authorization server's issuer URL and the "aud" value set to the
resource server's identifier. This allows a correctly implemented resource server's identifier. This allows a correctly implemented
OpenID Connect relying party to detect substitution by checking the OpenID Connect relying party to detect substitution by checking the
"iss" and "aud" claims as described in Section 3.1.3.7. of "iss" and "aud" claims as described in Section 3.1.3.7. of
[OpenID.Core]. Relying parties SHOULD also use and check the "nonce" [OpenID.Core]. Relying parties SHOULD also use and check the "nonce"
parameter and claim to prevent token and code replay. parameter and claim to prevent token and code replay.
Resource servers utilizing JWTs to represent structured access tokens Resource servers utilizing JWTs to represent self-contained access
could be susceptible to replay attacks. Resource servers should tokens could be susceptible to replay attacks. Resource servers
therefore apply proper counter measures against replay as described should therefore apply proper counter measures against replay as
in [I-D.ietf-oauth-security-topics], section 2.2. described in [I-D.ietf-oauth-security-topics], section 2.2.
JWT Confusion and other attacks involving JWTs are discussed in JWT Confusion and other attacks involving JWTs are discussed in
[I-D.ietf-oauth-jwt-bcp]. [I-D.ietf-oauth-jwt-bcp].
6.2. Token Data Leakage 6.2. Token Data Leakage
The authorization server MUST use Transport Layer Security (TLS) 1.2 The authorization server MUST use Transport Layer Security (TLS) 1.2
(or higher) in order to prevent token data leakage. (or higher) per [RFC7525] in order to prevent token data leakage.
If the authorization server supports unauthenticated requests an To prevent introspection of leaked tokens and to present an
attacker could potentially retrieve token data which must be kept additional security layer against token guessing attacks the
confidential. This attack can be prevented by either authenticating authorization server may require all requests to the token
any request to the token introspection endpoint or by setting up the introspection endpoint to be authenticated. As an alternative or as
respective recipient for encrypted responses. an addition to the authentication, the intended recipients may be set
up for encrypted responses.
In the latter case, confidentiality is ensured by the fact that only In the latter case, confidentiality is ensured by the fact that only
the legitimate recipient is able to decrypt the response. An the legitimate recipient is able to decrypt the response. An
attacker could try to circumvent this measure by requesting a plain attacker could try to circumvent this measure by requesting a plain
JSON response, using an Accept header with the content type set to, JSON response, using an Accept header with the content type set to,
for example, "application/json" instead of "application/jwt". To for example, "application/json" instead of "application/jwt". To
prevent this attack the authorization server MUST NOT serve requests prevent this attack the authorization server MUST NOT serve requests
with content type other than "application/jwt" if the resource server with content type other than "application/jwt" if the resource server
is set up to receive encrypted responses (see also Section 3). is set up to receive encrypted responses (see also Section 3).
6.3. Data Minimization 6.3. Keeping Token Data Confidential from OAuth Clients
Authorization servers with a policy that requires token data to be
kept confidential from OAuth clients must require all requests to the
token introspection endpoint to be authenticated. As an alternative
or as an addition to the authentication, the intended recipients may
be set up for encrypted responses.
6.4. Logging and Audit of Introspection Activity
Authorization servers with a policy that requires token introspection
activity to be logged and audited must require all requests to the
token introspection endpoint to be authenticated.
6.5. Data Minimization
The authorisation server determines the token data a resource server The authorisation server determines the token data a resource server
is allowed to see based on the resource server's client_id and is allowed to see based on the resource server's client_id and
suitable token data, e.g. the scope value. suitable token data, e.g. the scope value.
7. Acknowledgements 7. Acknowledgements
We would like to thank Petteri Stenius, Neil Madden, Filip Skokan, We would like to thank Petteri Stenius, Neil Madden, Filip Skokan,
and Tony Nadalin for their valuable feedback. and Tony Nadalin for their valuable feedback.
skipping to change at page 11, line 4 skipping to change at page 11, line 38
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "website" o Name: "website"
o Description: URL of the End-User's Web page or blog. This Web o Description: URL of the End-User's Web page or blog. This Web
page SHOULD contain information published by the End-User or an page SHOULD contain information published by the End-User or an
organization that the End-User is affiliated with. organization that the End-User is affiliated with.
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "email" o Name: "email"
o Description: End-User's preferred e-mail address. Its value MUST o Description: End-User's preferred e-mail address. Its value MUST
conform to the RFC 5322 [RFC5322] addr-spec syntax. conform to the [RFC5322] "addr-spec" syntax.
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "email_verified" o Name: "email_verified"
o Description: True if the End-User's e-mail address has been o Description: True if the End-User's e-mail address has been
verified; otherwise false. When this Claim Value is true, this verified; otherwise false. When this Claim Value is true, this
means that the OP took affirmative steps to ensure that this means that the OP took affirmative steps to ensure that this
e-mail address was controlled by the End-User at the time the e-mail address was controlled by the End-User at the time the
verification was performed. The means by which an e-mail address verification was performed. The means by which an e-mail address
is verified is context-specific, and dependent upon the trust is verified is context-specific, and dependent upon the trust
framework or contractual agreements within which the parties are framework or contractual agreements within which the parties are
operating. operating.
o Change Controller: IESG o Change Controller: IESG
skipping to change at page 12, line 28 skipping to change at page 13, line 15
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "phone_number" o Name: "phone_number"
o Description: End-User's preferred telephone number. E.164 [E.164] o Description: End-User's preferred telephone number. E.164 [E.164]
is RECOMMENDED as the format of this Claim, for example, +1 (425) is RECOMMENDED as the format of this Claim, for example, +1 (425)
555-1212 or +56 (2) 687 2400. If the phone number contains an 555-1212 or +56 (2) 687 2400. If the phone number contains an
extension, it is RECOMMENDED that the extension be represented extension, it is RECOMMENDED that the extension be represented
using the RFC 3966 [RFC3966] extension syntax, for example, +1 using the [RFC3966] extension syntax, for example, +1 (604)
(604) 555-1234;ext=5678. 555-1234;ext=5678.
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "phone_number_verified" o Name: "phone_number_verified"
o Description: True if the End-User's phone number has been o Description: True if the End-User's phone number has been
verified; otherwise false. When this Claim Value is true, this verified; otherwise false. When this Claim Value is true, this
means that the OP took affirmative steps to ensure that this phone means that the OP took affirmative steps to ensure that this phone
number was controlled by the End-User at the time the verification number was controlled by the End-User at the time the verification
was performed. The means by which a phone number is verified is was performed. The means by which a phone number is verified is
context-specific, and dependent upon the trust framework or context-specific, and dependent upon the trust framework or
contractual agreements within which the parties are operating. contractual agreements within which the parties are operating.
When true, the phone_number Claim MUST be in E.164 format and any When true, the phone_number Claim MUST be in E.164 format and any
extensions MUST be represented in RFC 3966 format. extensions MUST be represented in [RFC3966] format.
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "address" o Name: "address"
o Description: End-User's preferred postal address. The value of o Description: End-User's preferred postal address. The value of
the address member is a JSON [RFC4627] structure containing some the address member is a JSON [RFC7159] structure containing some
or all of the members defined in [OpenID.Core],Section 5.1.1. or all of the members defined in [OpenID.Core], Section 5.1.1.
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "updated_at" o Name: "updated_at"
o Description: Time the End-User's information was last updated. o Description: Time the End-User's information was last updated.
Its value is a JSON number representing the number of seconds from Its value is a JSON number representing the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time. 1970-01-01T0:0:0Z as measured in UTC until the date/time.
skipping to change at page 13, line 28 skipping to change at page 14, line 15
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1 o Specification Document(s):[OpenID.Core], Section 5.1
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-oauth-jwt-bcp] [I-D.ietf-oauth-jwt-bcp]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", draft-ietf-oauth-jwt-bcp-04 (work in Current Practices", draft-ietf-oauth-jwt-bcp-06 (work in
progress), November 2018. progress), June 2019.
[I-D.ietf-oauth-security-topics] [I-D.ietf-oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", draft-ietf- "OAuth 2.0 Security Best Current Practice", draft-ietf-
oauth-security-topics-11 (work in progress), December oauth-security-topics-13 (work in progress), July 2019.
2018.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", Nov 2014, errata set 1", Nov 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-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 incorporating errata set Dynamic Client Registration 1.0 incorporating errata set
1", Nov 2014, <https://openid.net/specs/ 1", Nov 2014, <https://openid.net/specs/
openid-connect-registration-1_0.html>. openid-connect-registration-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>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 3966, DOI 10.17487/RFC3966, December 2004,
<https://www.rfc-editor.org/info/rfc2246>. <https://www.rfc-editor.org/info/rfc3966>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] 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,
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] 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,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[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,
<https://www.rfc-editor.org/info/rfc7591>. <https://www.rfc-editor.org/info/rfc7591>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414, Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018, DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
9.2. Informative References 9.2. Informative References
[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>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-05
o improved wording for TLS requirement
o added RFC 2119 boilerplate
o fixed and updated some references
-04
o reworked definition of parameters in section 4
o added text on data minimization to security considerations section
o added statement regarding TLS to security considerations section
-03 -03
o added registration for OpenID Connect Standard Claims to OAuth o added registration for OpenID Connect Standard Claims to OAuth
Token Introspection Response registry Token Introspection Response registry
-02 -02
o updated references o updated references
-01 -01
 End of changes. 28 change blocks. 
42 lines changed or deleted 102 lines changed or added

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