draft-ietf-oauth-jwsreq-15.txt   draft-ietf-oauth-jwsreq-16.txt 
OAuth Working Group N. Sakimura OAuth Working Group N. Sakimura
Internet-Draft Nomura Research Institute Internet-Draft Nomura Research Institute
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: January 22, 2018 Yubico Expires: October 8, 2018 Yubico
July 21, 2017 April 6, 2018
The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
(JAR) (JAR)
draft-ietf-oauth-jwsreq-15 draft-ietf-oauth-jwsreq-16
Abstract Abstract
The authorization request in OAuth 2.0 described in RFC 6749 utilizes The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b) integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of the source of the communication is not authenticated. Because of
skipping to change at page 1, line 40 skipping to change at page 1, line 40
The request can be sent by value or by reference. The request can be sent by value or by reference.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 22, 2018. This Internet-Draft will expire on October 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 5 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 5
2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6
3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6 3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6
4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 6 4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 6
5. Authorization Request . . . . . . . . . . . . . . . . . . . . 8 5. Authorization Request . . . . . . . . . . . . . . . . . . . . 8
5.1. Passing a Request Object by Value . . . . . . . . . . . . 9 5.1. Passing a Request Object by Value . . . . . . . . . . . . 9
5.2. Passing a Request Object by Reference . . . . . . . . . . 9 5.2. Passing a Request Object by Reference . . . . . . . . . . 9
5.2.1. URI Referencing the Request Object . . . . . . . . . 10 5.2.1. URI Referencing the Request Object . . . . . . . . . 11
5.2.2. Request using the "request_uri" Request Parameter . . 11 5.2.2. Request using the "request_uri" Request Parameter . . 11
5.2.3. Authorization Server Fetches Request Object . . . . . 11 5.2.3. Authorization Server Fetches Request Object . . . . . 11
6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 12 6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 12
6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 12 6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 12
6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 12 6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 13
6.3. Request Parameter Assembly and Validation . . . . . . . . 13 6.3. Request Parameter Assembly and Validation . . . . . . . . 13
7. Authorization Server Response . . . . . . . . . . . . . . . . 13 7. Authorization Server Response . . . . . . . . . . . . . . . . 13
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 13 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 14 10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 14
10.2. Request Source Authentication . . . . . . . . . . . . . 14 10.2. Request Source Authentication . . . . . . . . . . . . . 15
10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 15 10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 15
10.4. Risks Associated with request_uri . . . . . . . . . . . 16 10.4. Risks Associated with request_uri . . . . . . . . . . . 16
10.4.1. DDoS Attack on the Authorization Server . . . . . . 16 10.4.1. DDoS Attack on the Authorization Server . . . . . . 16
10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 16 10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 16
11. TLS security considerations . . . . . . . . . . . . . . . . . 17 11. TLS security considerations . . . . . . . . . . . . . . . . . 17
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
12.1. Collection limitation . . . . . . . . . . . . . . . . . 17 12.1. Collection limitation . . . . . . . . . . . . . . . . . 17
12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18 12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18
12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18 12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18
12.2.2. Tracking using Request Object URI . . . . . . . . . 18 12.2.2. Tracking using Request Object URI . . . . . . . . . 18
skipping to change at page 6, line 35 skipping to change at page 6, line 35
WAP Wireless Application Protocol WAP Wireless Application Protocol
4. Request Object 4. Request Object
A Request Object (Section 2.1) is used to provide authorization A Request Object (Section 2.1) is used to provide authorization
request parameters for an OAuth 2.0 authorization request. It MUST request parameters for an OAuth 2.0 authorization request. It MUST
contains all the OAuth 2.0 [RFC6749] authorization request parameters contains all the OAuth 2.0 [RFC6749] authorization request parameters
including extension parameters. The parameters are represented as including extension parameters. The parameters are represented as
the JWT claims. Parameter names and string values MUST be included the JWT claims. Parameter names and string values MUST be included
as JSON strings. Since it is a JWT, JSON strings MUST be represented as JSON strings. Since Request Objects are handled across domains
in UTF-8. Numerical values MUST be included as JSON numbers. It MAY and potentially outside of a closed ecosystem, per section 8.1 of
include any extension parameters. This JSON [RFC7159] constitutes [RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629].
the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is Numerical values MUST be included as JSON numbers. It MAY include
then signed or signed and encrypted. any extension parameters. This JSON [RFC7159] constitutes the JWT
Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then
signed or signed and encrypted.
To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a
JWS signed JWT [RFC7519]. If signed, the Authorization Request JWS signed JWT [RFC7519]. If signed, the Authorization Request
Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
as members, with their semantics being the same as defined in the JWT as members, with their semantics being the same as defined in the JWT
[RFC7519] specification. [RFC7519] specification.
To encrypt, JWE [RFC7516] is used. When both signature and To encrypt, JWE [RFC7516] is used. When both signature and
encryption are being applied, the JWT MUST be signed then encrypted encryption are being applied, the JWT MUST be signed then encrypted
as advised in the section 11.2 of [RFC7519]. The result is a Nested as advised in the section 11.2 of [RFC7519]. The result is a Nested
skipping to change at page 10, line 8 skipping to change at page 10, line 8
The "request_uri" Authorization Request parameter enables OAuth The "request_uri" Authorization Request parameter enables OAuth
authorization requests to be passed by reference, rather than by authorization requests to be passed by reference, rather than by
value. This parameter is used identically to the "request" value. This parameter is used identically to the "request"
parameter, other than that the Request Object value is retrieved from parameter, other than that the Request Object value is retrieved from
the resource identified by the specified URI rather than passed by the resource identified by the specified URI rather than passed by
value. value.
The entire Request URI MUST NOT exceed 512 ASCII characters. There The entire Request URI MUST NOT exceed 512 ASCII characters. There
are three reasons for this restriction. are three reasons for this restriction.
1. Many WAP / feature phones do not accept large payloads. The 1. Many phones in the market as of this writing still do not accept
restriction is typically either 512 or 1024 ASCII characters. large payloads. The restriction is typically either 512 or 1024
ASCII characters.
2. The maximum URL length supported by older versions of Internet 2. The maximum URL length supported by older versions of Internet
Explorer is 2083 ASCII characters. Explorer is 2083 ASCII characters.
3. On a slow connection such as 2G mobile connection, a large URL 3. On a slow connection such as 2G mobile connection, a large URL
would cause the slow response and therefore the use of such is would cause the slow response and therefore the use of such is
not advisable from the user experience point of view. not advisable from the user experience point of view.
The contents of the resource referenced by the URI MUST be a Request The contents of the resource referenced by the URI MUST be a Request
Object. The "request_uri" value MUST be either URN as defined in Object. The "request_uri" value MUST be either URN as defined in
skipping to change at page 11, line 10 skipping to change at page 11, line 16
The Client stores the Request Object resource either locally or The Client stores the Request Object resource either locally or
remotely at a URI the Authorization Server can access. Such facility remotely at a URI the Authorization Server can access. Such facility
may be provided by the authorization server or a third party. For may be provided by the authorization server or a third party. For
example, the authorization server may provide a URL to which the example, the authorization server may provide a URL to which the
client POSTs the request object and obtains the Requiest URI. This client POSTs the request object and obtains the Requiest URI. This
URI is the Request Object URI, "request_uri". URI is the Request Object URI, "request_uri".
It is possible for the Request Object to include values that are to It is possible for the Request Object to include values that are to
be revealed only to the Authorization Server. As such, the be revealed only to the Authorization Server. As such, the
"request_uri" MUST have appropriate entropy for its lifetime. It is "request_uri" MUST have appropriate entropy for its lifetime. For
RECOMMENDED that it be removed after a reasonable timeout unless the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED
access control measures are taken. that it be removed after a reasonable timeout unless access control
measures are taken.
The following is an example of a Request Object URI value (with line The following is an example of a Request Object URI value (with line
wraps within values for display purposes only): wraps within values for display purposes only):
https://tfp.example.org/request.jwt# https://tfp.example.org/request.jwt#
GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
5.2.2. Request using the "request_uri" Request Parameter 5.2.2. Request using the "request_uri" Request Parameter
The Client sends the Authorization Request to the Authorization The Client sends the Authorization Request to the Authorization
skipping to change at page 12, line 42 skipping to change at page 12, line 47
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
6. Validating JWT-Based Requests 6. Validating JWT-Based Requests
6.1. Encrypted Request Object 6.1. Encrypted Request Object
If the request object is encrypted, the Authorization Server MUST If the request object is encrypted, the Authorization Server MUST
decrypt the JWT in accordance with the JSON Web Encryption [RFC7516] decrypt the JWT in accordance with the JSON Web Encryption [RFC7516]
specification. specification.
The result is a signed request object and the signature validation The result is a signed request object.
MUST be performed as defined in Section 6.2 as well.
If decryption fails, the Authorization Server MUST return an If decryption fails, the Authorization Server MUST return an
"invalid_request_object" error. "invalid_request_object" error.
6.2. JWS Signed Request Object 6.2. JWS Signed Request Object
To perform signature validation of a JSON Web Signature [RFC7515] The Authorization Server MUST perform the signature validation of the
signed request object, the "alg" Header Parameter in its JOSE Header JSON Web Signature [RFC7515] signed request object. For this, the
MUST match the value of the pre-registered algorithm. The signature "alg" Header Parameter in its JOSE Header MUST match the value of the
MUST be validated against the appropriate key for that "client_id" pre-registered algorithm. The signature MUST be validated against
and algorithm. the appropriate key for that "client_id" and algorithm.
If signature validation fails, the Authorization Server MUST return If signature validation fails, the Authorization Server MUST return
an "invalid_request_object" error. an "invalid_request_object" error.
6.3. Request Parameter Assembly and Validation 6.3. Request Parameter Assembly and Validation
The Authorization Server MUST extract the set of Authorization The Authorization Server MUST extract the set of Authorization
Request parameters from the Request Object value. The Authorization Request parameters from the Request Object value. The Authorization
Server MUST only use the parameters in the Request Object even if the Server MUST only use the parameters in the Request Object even if the
same parameter is provided in the query parameter. The Authorization same parameter is provided in the query parameter. The Authorization
skipping to change at page 18, line 48 skipping to change at page 19, line 4
history etc. and start correlating the user's activity using it. In history etc. and start correlating the user's activity using it. In
a way, it is a data disclosure as well and should be avoided. a way, it is a data disclosure as well and should be avoided.
Therefore, per-user Request Object URI should be avoided. Therefore, per-user Request Object URI should be avoided.
13. Acknowledgements 13. Acknowledgements
The following people contributed to the creation of this document in The following people contributed to the creation of this document in
the OAuth WG. (Affiliations at the time of the contribution are the OAuth WG. (Affiliations at the time of the contribution are
used.) used.)
Sergey Beryozkin, Brian Campbell (Ping Identity), Vladimir Dzhuvinov Sergey Beryozkin, Brian Campbell (Ping Identity), Vladimir Dzhuvinov
(Connect2id), Michael B. Jones (Microsoft), Torsten Lodderstedt (Connect2id), Michael B. Jones (Microsoft), Torsten Lodderstedt
(YES) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes Tschofenig (YES) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes Tschofenig
(ARM), Kathleen Moriarty (as AD), and Steve Kent (as SECDIR). (ARM), Ben Campbell, Kathleen Moriarty (as AD), and Steve Kent (as
SECDIR).
The following people contributed to creating this document through The following people contributed to creating this document through
the OpenID Connect Core 1.0 [OpenID.Core]. the OpenID Connect Core 1.0 [OpenID.Core].
Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou
(Mixi), Edmund Jay (Illumila), Michael B. Jones (Microsoft), Breno (Mixi), Edmund Jay (Illumila), Michael B. Jones (Microsoft), Breno
de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE). de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE).
In addition, the following people contributed to this and previous In addition, the following people contributed to this and previous
versions through the OAuth Working Group. versions through the OAuth Working Group.
Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer
(Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke (Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke
Shepard (Facebook). Shepard (Facebook).
14. Revision History 14. Revision History
Note to the RFC Editor: Please remove this section from the final
RFC.
-16
o Treated remaining Ben Campbell comments.
-15 -15
o Removed further duplication o Removed further duplication
-14 -14
o #71 Reiterate dynamic params are included. o #71 Reiterate dynamic params are included.
o #70 Made clear that AS must return error. o #70 Made clear that AS must return error.
skipping to change at page 24, line 34 skipping to change at page 24, line 43
15.1. Normative References 15.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, May 2015. (DTLS)", BCP 195, RFC 7525, May 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[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>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012,
<http://www.rfc-editor.org/info/rfc6750>. <https://www.rfc-editor.org/info/rfc6750>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013, DOI 10.17487/RFC6819, January 2013,
<http://www.rfc-editor.org/info/rfc6819>. <https://www.rfc-editor.org/info/rfc6819>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[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, <http://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,
<http://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,
<http://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,
<http://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<http://www.rfc-editor.org/info/rfc8141>. <https://www.rfc-editor.org/info/rfc8141>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
15.2. Informative References 15.2. Informative References
[BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing [BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing
the ISO/IEC 9798 Standard for Entity Authentication", the ISO/IEC 9798 Standard for Entity Authentication",
Journal of Computer Security - Security and Trust Journal of Computer Security - Security and Trust
Principles Volume 21 Issue 6, Pages 817-846, November Principles Volume 21 Issue 6, Pages 817-846, November
2013, 2013,
<https://www.cs.ox.ac.uk/people/cas.cremers/downloads/ <https://www.cs.ox.ac.uk/people/cas.cremers/downloads/
papers/BCM2012-iso9798.pdf>. papers/BCM2012-iso9798.pdf>.
[FETT] Fett, D., Kusters, R., and G. Schmitz, "A Comprehensive [FETT] Fett, D., Kusters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", CCS '16 Formal Security Analysis of OAuth 2.0", CCS '16
Proceedings of the 2016 ACM SIGSAC Conference on Computer Proceedings of the 2016 ACM SIGSAC Conference on Computer
and Communications Security Pages 1204-1215 , October and Communications Security Pages 1204-1215 , October
2016, <https://infsec.uni- 2016, <https://infsec.uni-
trier.de/people/publications/paper/FettKuestersSchmitz- trier.de/people/publications/paper/
CCS-2016.pdf>. FettKuestersSchmitz-CCS-2016.pdf>.
[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", OpenID C. Mortimore, "OpenID Connect Core 1.0", OpenID
Foundation Standards, February 2014, Foundation Standards, February 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
Authors' Addresses Authors' Addresses
Nat Sakimura Nat Sakimura
 End of changes. 32 change blocks. 
45 lines changed or deleted 64 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/