draft-ietf-oauth-jwsreq-00.txt   draft-ietf-oauth-jwsreq-01.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: February 26, 2015 Independent Expires: May 16, 2015 Ping Identity
August 25, 2014 November 12, 2014
Request by JWS ver.1.0 for OAuth 2.0 Request by JWS ver.1.0 for OAuth 2.0
draft-ietf-oauth-jwsreq-00 draft-ietf-oauth-jwsreq-01
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 thorugh "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.
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 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 February 26, 2015. This Internet-Draft will expire on May 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 3 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 3
2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 3 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 3
3. Request Object . . . . . . . . . . . . . . . . . . . . . . . 4 3. Request Object . . . . . . . . . . . . . . . . . . . . . . . 4
4. Request Object URI . . . . . . . . . . . . . . . . . . . . . 5 4. Request Object URI . . . . . . . . . . . . . . . . . . . . . 5
5. Authorization Request . . . . . . . . . . . . . . . . . . . . 6 5. Authorization Request . . . . . . . . . . . . . . . . . . . . 6
6. Authorization Server Response . . . . . . . . . . . . . . . . 7 6. Authorization Server Response . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
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 body holds the JSON encoded OAuth 2.0 authorization [JWT] whose JWT Claims Set holds the JSON encoded OAuth 2.0
request parameters. The [JWT] can be passed to the authorization authorization request parameters. The [JWT] can be passed to the
endpoint by reference, in which case the parameter "request_uri" is authorization endpoint by reference, in which case the parameter
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 [JWT] as the request encoding instead of query parameters has
several advantages: 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 is useful such as: There are a few cases that request by reference are useful such as:
1. When it is detected that the User Agent does not suport long 1. When it is detected that the User Agent does not support long
URLs: It is entirely possible that some extensions may extend the URLs: Some extensions may extend the URL. For example, the
URL. For example, the client might want to send a public key client might want to send a public key with the request.
with the request.
2. Static signature: The client may make a signed Request Object and 2. Static signature: The client may make a signed Request Object and
put it on the client. This may just be done by a client utility put it on the client. This may just be done by a client utility
or other process, so that the private key does not have to reside or other process, so that the private key does not have to reside
on the client, simplifying programming. on the client, simplifying programming.
3. When the server wants the requests to be cacheable: The 3. When the server wants the requests to be cache-able: The
request_uri may include a sha256 hash of the file, as defined in request_uri may include a sha256 hash of the file, as defined in
FIPS180-2 [FIPS180-2], the server knows if the file has changed FIPS180-2 [FIPS180-2], the server knows if the file has changed
without fetching it, so it does not have to re-fetch a same file, without fetching it, so it does not have to re-fetch a same file,
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
skipping to change at page 3, line 41 skipping to change at page 3, line 43
"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 JSON object JWT [JWT] that holds OAuth 2.0 authorization requests as JWT Claims
in its body 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) [JWS] signed
JWT [JWT] . The parameters are included as the top level members of JWT [JWT] . The parameters are included as the top-level members of
JSON [RFC4627]. Parameter names and string values MUST be included JSON [RFC4627]. Parameter names and string values MUST be included
as JSON strings. Numerical values MUST be included as JSON numbers. as JSON strings. Numerical values MUST be included as JSON numbers.
It MAY include any extension parameters. This JSON [RFC4627] It MAY include any extension parameters. This JSON [RFC4627]
constitues the body of the [JWT]. constitutes the [JWT] 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 [JWA] in
the JWS header. If signed, the Authorization Request Object SHOULD the JWS header. If signed, the Authorization Request Object SHOULD
contain the Claims "iss" (issuer) and "aud" (audience) as members, contain the Claims "iss" (issuer) and "aud" (audience) as members,
with their semantics being the same as defined in the JWT [JWT] with their semantics being the same as defined in the JWT [JWT]
specification. specification.
The Request Object MAY also be encrypted using JWE [JWE] after The Request Object MAY also be encrypted using JWE [JWE] 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 [JWT]. The Authorization Request Object MAY alternatively be
sent by reference using "request_uri" parameter. 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 or a required parameter is not present in neither the query parameter
the Request Object, it forms a malformed request. nor the Request Object, it forms a malformed request.
If the parameter exists both in 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 which consitutes the body of the Following is the example of the JSON that constitutes the [JWT]
[JWT]. 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 [JWT] 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:
skipping to change at page 5, line 31 skipping to change at page 5, line 31
SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO
iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI
HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zI HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zI
jp7Im5hbWUiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiO jp7Im5hbWUiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiO
m51bGwsInZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sI m51bGwsInZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sI
mZvcm1hdCI6InNpZ25lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvM mZvcm1hdCI6InNpZ25lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvM
jkxMTUiOiIyIn19.2OiqRgrbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY jkxMTUiOiIyIn19.2OiqRgrbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY
4. Request Object URI 4. Request Object URI
Instead of sending the Request Object in a OAuth 2.0 authorization Instead of sending the Request Object in an OAuth 2.0 authorization
request directly, this specification allows it to be obtained from request directly, this specification allows it to be obtained from
the Request Object URI. Using this method has an advantage of the Request Object URI. Using this method has an advantage of
reducing the request size, enabling the caching of the Request reducing the request size, enabling the caching of the Request
Object, and generally not requiring integrity protection through a Object, and generally not requiring integrity protection through a
cryptographic operation on the Request Object if the channel itself cryptographic operation on the Request Object if the channel itself
is protected. is protected.
The Request Object URI is sent as a part of the OAuth Authorization The Request Object URI is sent as a part of the OAuth Authorization
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
skipping to change at page 6, line 37 skipping to change at page 6, line 37
The client directs the resource owner to the constructed URI using an The client directs the resource owner to the constructed URI using an
HTTP redirection response, or by other means available to it via the HTTP redirection response, or by other means available to it via the
user-agent. user-agent.
For example, the client directs the end-user's user-agent to make the For example, the client directs the end-user's user-agent to make the
following HTTPS request (line breaks are for display purposes only): following HTTPS request (line breaks are for display purposes only):
GET /authorize?request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 GET /authorize?request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com Host: server.example.com
The autorization request object MAY be signed AND/OR encrypted. The authorization request object MAY be signed AND/OR encrypted.
Upon receipt of "request_uri" in the request, the authorization Upon receipt of "request_uri" in the request, the authorization
server MUST send a GET request to the "request_uri" to retrieve the server MUST send a GET request to the "request_uri" to retrieve the
authorization request object unless it is already cached at the authorization request object unless it is already cached at the
Authorization Server. Authorization Server.
If the response was signed AND/OR encrypted, it has to be decoded If the response was signed AND/OR encrypted, it has to be decoded
accordingly before being processed. accordingly before being processed.
Then, the Authorization Server MUST reconstruct the complete client Then, the Authorization Server MUST reconstruct the complete client
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 [JWS]. The "alg=none" SHOULD NOT be used in such a
case. 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 [JWE] 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 ( Breno de Medeiros (Google), Hideki Nara (TACT), John Bradley ( Ping
Independent) <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
Jay (Illumila), (add yourself). Jay (Illumila), (add yourself).
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. References 10. Revision History
10.1. Normative References -01
o Copy Edits.
11. 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- [JWA] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
json-web-algorithms (work in progress), July 2014. json-web-algorithms (work in progress), July 2014.
skipping to change at page 9, line 15 skipping to change at page 9, line 21
[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.
10.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
1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg.
Chiyoda-ku, Tokyo 100-0005 Chiyoda-ku, Tokyo 100-0005
Japan Japan
Phone: +81-3-5533-2111 Phone: +81-3-5533-2111
Email: n-sakimura@nri.co.jp Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/ URI: http://nat.sakimura.org/
John Bradley John Bradley
Independent Ping Identity
Casilla 177, Sucursal Talagante Casilla 177, Sucursal Talagante
Talagante, RM Talagante, RM
Chile Chile
Phone: +44 20 8133 3718 Phone: +44 20 8133 3718
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/ URI: http://www.thread-safe.com/
 End of changes. 25 change blocks. 
38 lines changed or deleted 44 lines changed or added

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