draft-ietf-oauth-jwsreq-02.txt   draft-ietf-oauth-jwsreq-03.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: November 30, 2015 Ping Identity Expires: January 6, 2016 Ping Identity
May 29, 2015 July 05, 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-02 draft-ietf-oauth-jwsreq-03
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 November 30, 2015. This Internet-Draft will expire on January 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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:
1. When it is detected that the User Agent does not support long 1. When it is detected that the User Agent does not support long
URLs: Some extensions may extend the URL. For example, the URLs: Some extensions may extend the URL. For example, the
client might want to send a public key with the request. client might want to send a public key 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 at the place where the Authorization Server can access.
or other process, so that the private key does not have to reside This may just be done by a client utility or other process, so
on the client, simplifying programming. that the private key does not have to reside on the client,
simplifying programming.
3. When the server wants the requests to be cache-able: 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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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) [RFC7515] extension parameters. It is a JSON Web Signature (JWS) [RFC7515]
signed JWT [RFC7519] . The parameters are included as the top-level signed JWT [RFC7519] . The parameters are included as the top-level
members of JSON [RFC7159]. Parameter names and string values MUST be members of JSON [RFC7159]. Parameter names and string values MUST be
included as JSON strings. Numerical values MUST be included as JSON included as JSON strings. Numerical values MUST be included as JSON
numbers. It MAY include any extension parameters. This JSON numbers. It MAY include any extension parameters. This JSON
[RFC7159] constitutes the [RFC7519] Claims Set. [RFC7159] constitutes the JWT [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 [RFC7518] plaintext, this is indicated by use of the "none" algorithm JWA
in the JWS header. If signed, the Authorization Request Object [RFC7518] in the JWS header. If signed, the Authorization Request
SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
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 Request Object MAY also be encrypted using JWE [RFC7516] 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 [RFC7519]. The Authorization Request Object MAY alternatively JWT [RFC7519]. The Authorization Request Object MAY alternatively be
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 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, the values in the Request Object takes
precedence. This means that if it intends to use a cached request
object, it cannot include such parameters like "state" that is
expected to differ in every request. It is fine to include them in
the request object if it is going to be prepared afresh every time.
Following is the example of the JSON that constitutes the [RFC7519] 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 [RFC7519] encoded The following is a non-normative example of a [RFC7519] encoded
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
-03
o Fixed the non-normative description about the advantage of static
signature.
o Changed the requement for the parameter values in the request
iteself and the request object from 'MUST MATCH" to 'Req Obj takes
precedence.
-02 -02
o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. 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
 End of changes. 9 change blocks. 
15 lines changed or deleted 29 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/