draft-ietf-oauth-jwsreq-05.txt   draft-ietf-oauth-jwsreq-06.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: January 23, 2016 Ping Identity Expires: April 16, 2016 Ping Identity
July 22, 2015 October 14, 2015
OAuth 2.0 JWT Authorization Request OAuth 2.0 JWT Authorization Request
draft-ietf-oauth-jwsreq-05 draft-ietf-oauth-jwsreq-06
Abstract Abstract
The authorization request in OAuth 2.0 utilizes query parameter The authorization request in RFC6749 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 by value through
parameter or by reference through "request_uri" parameter that points "request" parameter or by reference through "request_uri" parameter
to the JWT, allowing the request to be optionally signed and that points to the JWT, allowing the request to be optionally signed
encrypted. and 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 January 23, 2016. This Internet-Draft will expire on April 16, 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 2, line 20 skipping to change at page 2, line 20
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 4 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 4
2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 4 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 4
3. Request Object . . . . . . . . . . . . . . . . . . . . . . . 4 3. Request Object . . . . . . . . . . . . . . . . . . . . . . . 4
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 6 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 6
4.1. Passing a Request Object by Value . . . . . . . . . . . . 7 4.1. Passing a Request Object by Value . . . . . . . . . . . . 7
4.2. Passing a Request Object by Reference . . . . . . . . . . 8 4.2. Passing a Request Object by Reference . . . . . . . . . . 8
4.2.1. URL Referencing the Request Object . . . . . . . . . 10 4.2.1. URL Referencing the Request Object . . . . . . . . . 10
4.2.2. Request using the "request_uri" Request Parameter . . 10 4.2.2. Request using the "request_uri" Request Parameter . . 10
4.2.3. Authorization Server Fetches Request Object . . . . . 10 4.2.3. Authorization Server Fetches Request Object . . . . . 11
5. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 11 5. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 11
5.1. Encrypted Request Object . . . . . . . . . . . . . . . . 11 5.1. Encrypted Request Object . . . . . . . . . . . . . . . . 11
5.2. Signed Request Object . . . . . . . . . . . . . . . . . . 11 5.2. Signed Request Object . . . . . . . . . . . . . . . . . . 11
5.3. Request Parameter Assembly and Validation . . . . . . . . 11 5.3. Request Parameter Assembly and Validation . . . . . . . . 12
6. Authorization Server Response . . . . . . . . . . . . . . . . 11 6. Authorization Server Response . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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)
[RFC7519] 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 [RFC7519] can be passed to authorization request parameters. The JWT [RFC7519] can be passed to
the authorization endpoint by reference, in which case the parameter the 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 [RFC7519] as the request encoding instead of query Using JWT [RFC7519] as the request encoding instead of query
parameters has several advantages: parameters has several advantages:
1. The request can be signed so that an integrity check can be 1. The request can be signed so that an integrity check can be
implemented. If a suitable algorithm is used for the signing, implemented. If a suitable algorithm is used for the signing,
then it will provide a good evidence of the approver. then it will provide verification of the client making the
request.
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.
3. The request may be signed by a third party attesting that the 3. The request may be signed by a third party attesting that the
authorization request is compliant to certain policy. For authorization request is compliant to certain policy. For
example, a request can be pre-examined by a third party that all example, a request can be pre-examined by a third party that all
the personal data requested is strictly necessary to perform the the personal data requested is strictly necessary to perform the
process that the end-user asked for, and statically signed by process that the end-user asked for, and statically signed by
that third party. The client would then send the request along that third party. The client would then send the request along
with dynamic parameters such as state. The authorization server with dynamic parameters such as state. The authorization server
then examines the signature and show the end-user the conformance then examines the signature and show the conformance status to
status to the end-user, who would have some assurance as to the the end-user, who would have some assurance as to the legitimacy
legitimacy of the request when authorizing it. In some cases, it of the request when authorizing it. In some cases, it may even
may even be desirable to skip the authorization dialogue under be desirable to skip the authorization dialogue under such
such circumstances. circumstances.
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 can make a signed Request Object and 2. Static signature: The client can make a signed Request Object and
put it at a place that the Authorization Server can access. This put it at a place that the Authorization Server can access. This
may just be done by a client utility or other process, so that may just be done by a client utility or other process, so that
skipping to change at page 9, line 15 skipping to change at page 9, line 15
passed as OAuth 2.0 parameters. passed as OAuth 2.0 parameters.
Servers MAY cache the contents of the resources referenced by Request Servers MAY cache the contents of the resources referenced by Request
URIs. If the contents of the referenced resource could ever change, URIs. If the contents of the referenced resource could ever change,
the URI SHOULD include the base64url encoded SHA-256 hash as defined the URI SHOULD include the base64url encoded SHA-256 hash as defined
in FIPS180-2 [FIPS180-2] of the referenced resource contents as the in FIPS180-2 [FIPS180-2] of the referenced resource contents as the
fragment component of the URI. If the fragment value used for a URI fragment component of the URI. If the fragment value used for a URI
changes, that signals the server that any cached value for that URI changes, that signals the server that any cached value for that URI
with the old fragment value is no longer valid. with the old fragment value is no longer valid.
The entire Request URI MUST NOT exceed 512 ASCII characters. The entire Request URI MUST NOT exceed 512 ASCII characters. There
are three reasons for this restriction.
1. Many WAP / feature phones do not accept large payloads. The
restriction are typically either 512 or 1024 ASCII characters.
2. The maximum URL length supported by Internet Explorer is 2083
ASCII characters.
3. On a slow connection such as 2G mobile connection, a large URL
would cause the slow response and using such is not advisable
from the user experience point of view.
The contents of the resource referenced by the URL MUST be a Request The contents of the resource referenced by the URL MUST be a Request
Object. The scheme used in the "request_uri" value MUST be "https", Object. The scheme used in the "request_uri" value MUST be "https",
unless the target Request Object is signed in a way that is unless the target Request Object is signed in a way that is
verifiable by the Authorization Server. The "request_uri" value MUST verifiable by the Authorization Server. The "request_uri" value MUST
be reachable by the Authorization Server, and SHOULD be reachable by be reachable by the Authorization Server, and SHOULD be reachable by
the Client. the Client.
The following is a non-normative example of the contents of a Request The following is a non-normative example of the contents of a Request
Object resource that can be referenced by a "request_uri" (with line Object resource that can be referenced by a "request_uri" (with line
skipping to change at page 12, line 45 skipping to change at page 13, line 18
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 [RFC7516] is strongly policy. For higher security requirement, using [RFC7516] is strongly
recommended. recommended.
9. Acknowledgements 9. Acknowledgements
Follwoing people contributed to the creation of this document in Follwoing people contributed to the creation of this document in
OAuth WG. OAuth WG.
John Bradley (Ping Identity), Michael B. Jones (Microsoft), Nat Michael B. Jones (Microsoft), Axel Nenker(DT), Sergey Beryozkin, Jim
Sakimura (NRI), (add yourself). Manico, (add yourself).
Following people contributed to creating this document through the Following people contributed to creating this document through the
OpenID Connect 1.0 [OpenID.Core]. OpenID Connect 1.0 [OpenID.Core].
Breno de Medeiros (Google), Hideki Nara (TACT), John Bradley ( Ping Breno de Medeiros (Google), Hideki Nara (TACT), Ryo Itou (Yahoo!
Identity) <author>, Nat Sakimura (NRI) <author/editor>, Ryo Itou Japan), George Fletcher (AOL), Justin Richer (MITRE), Edmund Jay
(Yahoo! Japan), George Fletcher (AOL), Justin Richer (MITRE), Edmund (Illumila), Michael B. Jones (Microsoft), (add yourself).
Jay (Illumila), Michael B. Jones (Microsoft), (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. Revision History 10. Revision History
-06
o Added explanation on the 512 chars URL restriction.
o Updated Acknowledgements.
-05 -05
o More alignment with OpenID Connect. o More alignment with OpenID Connect.
-04 -04
o Fixed typos in examples. (request_url -> request_uri, cliend_id -> o Fixed typos in examples. (request_url -> request_uri, cliend_id ->
client_id) client_id)
o Aligned the error messages with the OAuth IANA registry. o Aligned the error messages with the OAuth IANA registry.
 End of changes. 15 change blocks. 
27 lines changed or deleted 44 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/