draft-ietf-oauth-jwsreq-17.txt   draft-ietf-oauth-jwsreq-18.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: April 24, 2019 Yubico Expires: November 17, 2019 Yubico
October 21, 2018 May 16, 2019
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-17 draft-ietf-oauth-jwsreq-18
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 47 skipping to change at page 1, line 47
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 April 24, 2019. This Internet-Draft will expire on November 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 6, line 45 skipping to change at page 6, line 45
[RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629]. [RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629].
Numerical values MUST be included as JSON numbers. It MAY include Numerical values MUST be included as JSON numbers. It MAY include
any extension parameters. This JSON [RFC7159] constitutes the JWT any extension parameters. This JSON [RFC7159] constitutes the JWT
Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then
signed or signed and encrypted. 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. The value of "aud" should be the value of
the Authorization Server (AS) "issuer" as defined in RFC8414
[RFC8414].
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
JWT, as defined in [RFC7519]. JWT, as defined in [RFC7519].
The Authorization Request Object MAY be sent by value as described in The Authorization Request Object MAY be sent by value as described in
Section 5.1 or by reference as described in Section 5.2. Section 5.1 or by reference as described in Section 5.2.
"request" and "request_uri" parameters MUST NOT be included in "request" and "request_uri" parameters MUST NOT be included in
skipping to change at page 25, line 30 skipping to change at page 25, line 30
[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,
<https://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,
<https://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
Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<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, <https://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,
<https://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
skipping to change at page 26, line 26 skipping to change at page 26, line 18
[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,
<https://www.rfc-editor.org/info/rfc8141>. <https://www.rfc-editor.org/info/rfc8141>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
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>.
skipping to change at page 27, line 5 skipping to change at page 26, line 47
2016, <https://infsec.uni- 2016, <https://infsec.uni-
trier.de/people/publications/paper/ trier.de/people/publications/paper/
FettKuestersSchmitz-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>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
Authors' Addresses Authors' Addresses
Nat Sakimura Nat Sakimura
Nomura Research Institute Nomura Research Institute
Otemachi Financial City Grand Cube, 1-9-2 Otemachi Otemachi Financial City Grand Cube, 1-9-2 Otemachi
Chiyoda-ku, Tokyo 100-0004 Chiyoda-ku, Tokyo 100-0004
Japan Japan
Phone: +81-3-5533-2111 Phone: +81-3-5533-2111
Email: n-sakimura@nri.co.jp Email: n-sakimura@nri.co.jp
 End of changes. 8 change blocks. 
17 lines changed or deleted 24 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/