draft-ietf-oauth-jwsreq-01.txt   draft-ietf-oauth-jwsreq-02.txt 
OAuth Working Group N. Sakimura, Ed. OAuth Working Group N. Sakimura, Ed.
Internet-Draft Nomura Research Institute Internet-Draft Nomura Research Institute
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: May 16, 2015 Ping Identity Expires: November 30, 2015 Ping Identity
November 12, 2014 May 29, 2015
Request by JWS ver.1.0 for OAuth 2.0 Request by JWS ver.1.0 for OAuth 2.0
draft-ietf-oauth-jwsreq-01 draft-ietf-oauth-jwsreq-02
Abstract Abstract
The authorization request in OAuth 2.0 utilizes query parameter The authorization request in OAuth 2.0 utilizes query parameter
serialization. This specification defines the authorization request serialization. This specification defines the authorization request
using JWT serialization. The request is sent through "request" using JWT serialization. The request is sent through "request"
parameter or by reference through "request_uri" parameter that points parameter or by reference through "request_uri" parameter that points
to the JWT, allowing the request to be optionally signed and to the JWT, allowing the request to be optionally signed and
encrypted. encrypted.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2015. This Internet-Draft will expire on November 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The parameters "request" and "request_uri" are introduced as The parameters "request" and "request_uri" are introduced as
additional authorization request parameters for the OAuth 2.0 additional authorization request parameters for the OAuth 2.0
[RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT)
[JWT] whose JWT Claims Set holds the JSON encoded OAuth 2.0 [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0
authorization request parameters. The [JWT] can be passed to the authorization request parameters. The [RFC7519] can be passed to the
authorization endpoint by reference, in which case the parameter authorization endpoint by reference, in which case the parameter
"request_uri" is used instead of the "request". "request_uri" is used instead of the "request".
Using [JWT] as the request encoding instead of query parameters has Using [RFC7519] as the request encoding instead of query parameters
several advantages: has several advantages:
1. The request may be signed so that integrity check may be 1. The request may be signed so that integrity check may be
implemented. If a suitable algorithm is used for the signing, implemented. If a suitable algorithm is used for the signing,
then non-repudiation property may be obtained in addition. then non-repudiation property may be obtained in addition.
2. The request may be encrypted so that end-to-end confidentiality 2. The request may be encrypted so that end-to-end confidentiality
may be obtained even if in the case TLS connection is terminated may be obtained even if in the case TLS connection is terminated
at a gateway or a similar device. at a gateway or a similar device.
There are a few cases that request by reference are useful such as: There are a few cases that request by reference are useful such as:
skipping to change at page 3, line 28 skipping to change at page 3, line 28
which is a win as well. which is a win as well.
4. When the client wants to simplify the implementation without 4. When the client wants to simplify the implementation without
compromising the security. If the request parameters go through compromising the security. If the request parameters go through
the Browser, they may be tampered in the browser even if TLS was the Browser, they may be tampered in the browser even if TLS was
used. This implies we need to have signature on the request as used. This implies we need to have signature on the request as
well. However, if HTTPS "request_uri" was used, it is not going well. However, if HTTPS "request_uri" was used, it is not going
to be tampered, thus we now do not have to sign the request. to be tampered, thus we now do not have to sign the request.
This simplifies the implementation. This simplifies the implementation.
This capability is in use by OpenID Connect. This capability is in use by OpenID Connect [openid_ab].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
For the purposes of this specification, the following terms and For the purposes of this specification, the following terms and
definitions apply. definitions apply.
2.1. Request Object 2.1. Request Object
JWT [JWT] that holds OAuth 2.0 authorization requests as JWT Claims JWT [RFC7519] that holds OAuth 2.0 authorization requests as JWT
Set Claims Set
2.2. Request Object URI 2.2. Request Object URI
Absolute URI from which the Request Object (Section 2.1) can be Absolute URI from which the Request Object (Section 2.1) can be
obtained obtained
3. Request Object 3. 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 OAuth 2.0 authorization request. It contains request parameters for OAuth 2.0 authorization request. It contains
OAuth 2.0 [RFC6749] authorization request parameters including OAuth 2.0 [RFC6749] authorization request parameters including
extension parameters. It is a JSON Web Signature (JWS) [JWS] signed extension parameters. It is a JSON Web Signature (JWS) [RFC7515]
JWT [JWT] . The parameters are included as the top-level members of signed JWT [RFC7519] . The parameters are included as the top-level
JSON [RFC4627]. Parameter names and string values MUST be included members of JSON [RFC7159]. Parameter names and string values MUST be
as JSON strings. Numerical values MUST be included as JSON numbers. included as JSON strings. Numerical values MUST be included as JSON
It MAY include any extension parameters. This JSON [RFC4627] numbers. It MAY include any extension parameters. This JSON
constitutes the [JWT] Claims Set. [RFC7159] constitutes the [RFC7519] Claims Set.
The Request Object MAY be signed or unsigned (plaintext). When it is The Request Object MAY be signed or unsigned (plaintext). When it is
plaintext, this is indicated by use of the "none" algorithm [JWA] in plaintext, this is indicated by use of the "none" algorithm [RFC7518]
the JWS header. If signed, the Authorization Request Object SHOULD in the JWS header. If signed, the Authorization Request Object
contain the Claims "iss" (issuer) and "aud" (audience) as members, SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as
with their semantics being the same as defined in the JWT [JWT] members, with their semantics being the same as defined in the JWT
specification. [RFC7519] specification.
The Request Object MAY also be encrypted using JWE [JWE] after The Request Object MAY also be encrypted using JWE [RFC7516] after
signing, with nesting performed in the same manner as specified for signing, with nesting performed in the same manner as specified for
JWTs [JWT]. The Authorization Request Object MAY alternatively be JWTs [RFC7519]. The Authorization Request Object MAY alternatively
sent by reference using "request_uri" parameter. be sent by reference using "request_uri" parameter.
REQUIRED OAuth 2.0 Authorization Request parameters that are not REQUIRED OAuth 2.0 Authorization Request parameters that are not
included in the Request Object MUST be sent as a query parameter. If included in the Request Object MUST be sent as a query parameter. If
a required parameter is not present in neither the query parameter a required parameter is not present in neither the query parameter
nor the Request Object, it forms a malformed request. nor the Request Object, it forms a malformed request.
If the parameter exists in both the query string and the If the parameter exists in both the query string and the
Authorization Request Object, they MUST exactly match. Authorization Request Object, they MUST exactly match.
Following is the example of the JSON that constitutes the [JWT] Following is the example of the JSON that constitutes the [RFC7519]
Claims Set. Claims Set.
{ {
"redirect_url":"https://example.com/rp/endpoint_url", "redirect_url":"https://example.com/rp/endpoint_url",
"cliend_id":"http://example.com/rp/" "cliend_id":"http://example.com/rp/"
} }
The following is a non-normative example of a [JWT] encoded The following is a non-normative example of a [RFC7519] encoded
authorization request object. It includes extension variables such authorization request object. It includes extension variables such
as "nonce", "userinfo", and "id_token". Note that the line wraps as "nonce", "userinfo", and "id_token". Note that the line wraps
within the values are for display purpose only: within the values are for display purpose only:
JWT algorithm = HS256 JWT algorithm = HS256
HMAC HASH Key = 'aaa' HMAC HASH Key = 'aaa'
JSON Encoded Header = "{"alg":"HS256","typ":"JWT"}" JSON Encoded Header = "{"alg":"HS256","typ":"JWT"}"
JSON Encoded Payload = "{"response_type":"code id_token", JSON Encoded Payload = "{"response_type":"code id_token",
"client_id":"s6BhdRkqt3", "client_id":"s6BhdRkqt3",
skipping to change at page 5, line 50 skipping to change at page 5, line 50
Request as the value for the parameter called "request_uri". How the Request as the value for the parameter called "request_uri". How the
Request Object is registered at Request Object URI is out of scope of Request Object is registered at Request Object URI is out of scope of
this specification, but it MUST be done in a protected channel. this specification, but it MUST be done in a protected channel.
NOTE: the Request Object MAY be registered at the Authorization NOTE: the Request Object MAY be registered at the Authorization
Server at the client registration time. Server at the client registration time.
When the Authorization Server obtains the Request Object from Request When the Authorization Server obtains the Request Object from Request
Object URI, it MUST do so over a protected channel. If it is Object URI, it MUST do so over a protected channel. If it is
obtained from a remote server, it SHOULD use either HTTP over TLS 1.2 obtained from a remote server, it SHOULD use either HTTP over TLS 1.2
as defined in RFC5246 [RFC5246] AND/OR [JWS] with the algorithm as defined in [RFC5246] AND/OR [RFC7515] with the algorithm
considered appropriate at the time. considered appropriate at the time.
When sending the request by "request_uri", the client MAY provide the When sending the request by "request_uri", the client MAY provide the
sha256 hash as defined in FIPS180-2 [FIPS180-2]of the Request Object sha256 hash as defined in FIPS180-2 [FIPS180-2]of the Request Object
as the fragment to it to assist the cache utilization decision of the as the fragment to it to assist the cache utilization decision of the
Authorization Server. Authorization Server.
5. Authorization Request 5. Authorization Request
The client constructs the authorization request URI by adding the The client constructs the authorization request URI by adding the
skipping to change at page 7, line 40 skipping to change at page 7, line 40
Object was invalid. Object was invalid.
8. Security Considerations 8. Security Considerations
In addition to the all the security considerations discussed in OAuth In addition to the all the security considerations discussed in OAuth
2.0 [RFC6819], the following security considerations SHOULD be taken 2.0 [RFC6819], the following security considerations SHOULD be taken
into account. into account.
When sending the authorization request object through "request" When sending the authorization request object through "request"
parameter, it SHOULD be signed with then considered appropriate parameter, it SHOULD be signed with then considered appropriate
algorithm using [JWS]. The "alg=none" SHOULD NOT be used in such a algorithm using [RFC7515]. The "alg=none" SHOULD NOT be used in such
case. a case.
If the request object contains personally identifiable or sensitive If the request object contains personally identifiable or sensitive
information, the "request_uri" MUST be of one-time use and MUST have information, the "request_uri" MUST be of one-time use and MUST have
large enough entropy deemed necessary with applicable security large enough entropy deemed necessary with applicable security
policy. For higher security requirement, using [JWE] is strongly policy. For higher security requirement, using [RFC7516] is strongly
recommended. recommended.
9. Acknowledgements 9. Acknowledgements
Following people contributed to creating this document through the Following people contributed to creating this document through the
OpenID Connect 1.0 [openid_ab]. OpenID Connect 1.0 [openid_ab].
Breno de Medeiros (Google), Hideki Nara (TACT), John Bradley ( Ping Breno de Medeiros (Google), Hideki Nara (TACT), John Bradley ( Ping
Identity) <author>, Nat Sakimura (NRI) <author/editor>, Ryo Itou Identity) <author>, Nat Sakimura (NRI) <author/editor>, Ryo Itou
(Yahoo! Japan), George Fletcher (AOL), Justin Richer (MITRE), Edmund (Yahoo! Japan), George Fletcher (AOL), Justin Richer (MITRE), Edmund
skipping to change at page 8, line 24 skipping to change at page 8, line 24
In addition following people contributed to this and previous In addition following people contributed to this and previous
versions through The OAuth Working Group. versions through The OAuth Working Group.
David Recordon (Facebook), Luke Shepard (Facebook), James H. Manger David Recordon (Facebook), Luke Shepard (Facebook), James H. Manger
(Telstra), Marius Scurtescu (Google), John Panzer (Google), Dirk (Telstra), Marius Scurtescu (Google), John Panzer (Google), Dirk
Balfanz (Google), (add yourself). Balfanz (Google), (add yourself).
10. Revision History 10. Revision History
-02
o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers.
-01 -01
o Copy Edits. o Copy Edits.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS180-2] [FIPS180-2]
U.S. Department of Commerce and National Institute of U.S. Department of Commerce and National Institute of
Standards and Technology, "Secure Hash Signature Standards and Technology, "Secure Hash Signature
Standard", FIPS 180-2, August 2002. Standard", FIPS 180-2, August 2002.
Defines Secure Hash Algorithm 256 (SHA256) Defines Secure Hash Algorithm 256 (SHA256)
[JWA] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
json-web-algorithms (work in progress), July 2014.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress),
July 2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), July 2014.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in
progress), July 2014.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[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, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
January 2013. January 2013.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, May 2015.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, May 2015.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May
2015.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, May 2015.
11.2. Informative References 11.2. Informative References
[openid_ab] [openid_ab]
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", February 2014. C. Mortimore, "OpenID Connect Core 1.0", February 2014.
Authors' Addresses Authors' Addresses
Nat Sakimura (editor) Nat Sakimura (editor)
Nomura Research Institute Nomura Research Institute
 End of changes. 21 change blocks. 
50 lines changed or deleted 51 lines changed or added

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