draft-ietf-oauth-jwsreq-06.txt   draft-ietf-oauth-jwsreq-07.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: April 16, 2016 Ping Identity Expires: July 22, 2016 Ping Identity
October 14, 2015 January 19, 2016
OAuth 2.0 JWT Authorization Request OAuth 2.0 JWT Authorization Request
draft-ietf-oauth-jwsreq-06 draft-ietf-oauth-jwsreq-07
Abstract Abstract
The authorization request in RFC6749 utilizes query parameter The authorization request in OAuth 2.0 [RFC6749] utilizes query
serialization. This specification defines the authorization request parameter serialization, which means that parameters are encoded in
using JWT serialization. The request is sent by value through the URI of the request. This document introduces the ability to send
"request" parameter or by reference through "request_uri" parameter request parameters in form of a JSON Web Token (JWT) instead, which
that points to the JWT, allowing the request to be optionally signed allows the request to be signed and encrypted. using JWT
and encrypted. serialization. The request is sent by value or by reference.
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 April 16, 2016. This Internet-Draft will expire on July 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . 5
3. Request Object . . . . . . . . . . . . . . . . . . . . . . . 4 3. Request Object . . . . . . . . . . . . . . . . . . . . . . . 5
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 6 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 7
4.1. Passing a Request Object by Value . . . . . . . . . . . . 7 4.1. Passing a Request Object by Value . . . . . . . . . . . . 8
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 . . . . . 11 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 . . . . . . . . 12 5.3. Request Parameter Assembly and Validation . . . . . . . . 12
6. Authorization Server Response . . . . . . . . . . . . . . . . 12 6. Authorization Server Response . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The OAuth 2.0 specification [RFC 6749] defines the encoding of
requests and responses and in case of the authorization request query
parameter serialization has been chosen. For example, the parameters
'response_type', 'client_id', 'state', and 'redirect_uri' are encoded
in the URI of the request:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
The encoding in the URI does not allow application layer security
with confidentiality and integrity protection to be used. While TLS
is used to offer communication security between the client and the
resource server, TLS sessions are often terminated prematurely at
some middlebox (such as a load balancer). The use of application
layer security additionally allows requests to be prepared by a third
party so that a client application cannot request more permissions
than previously agreed. This offers an additional degree of privacy
protection.
Further, the request by reference allows to reduce the over-the-wire
overhead.
There are other potential formats that could be used for this purpose
instead of JWT. The JWT was chosen because of
1. its close relationship with JSON, which is used as OAuth's
response format;
2. its developer friendliness due to its textaual nature;
3. its relative compactness compared to XML;
4. its development status that it is an RFC and so is its associated
signing and encryption methods as [RFC7515] and [RFC7516].
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:
skipping to change at page 3, line 16 skipping to change at page 3, line 51
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 conformance status to then examines the signature and shows the conformance status to
the end-user, who would have some assurance as to the legitimacy the end-user, who would have some assurance as to the legitimacy
of the request when authorizing it. In some cases, it may even of the request when authorizing it. In some cases, it may even
be desirable to skip the authorization dialogue under such be desirable to skip the authorization dialogue under 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 desirable to reduced the size of transmitted request.
URLs: Some extensions may extend the URL. For example, the Since we are using application layer security, it may
client might want to send a public key with the request. substantially increase the size of the request particulary in the
case of using public key cryptography.
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
the private key does not have to reside on the client, the private key does not have to reside on the client,
simplifying programming. simplifying programming. Downside of it is that the signed
portion just become a token.
3. When the server wants the requests to be cacheable: The 3. When the server wants the requests to be cacheable: The
request_uri may include a SHA-256 hash of the file, as defined in request_uri may include a SHA-256 hash of the contents of the
FIPS180-2 [FIPS180-2], the server knows if the file has changed resources referenced by the Request URI. With this, the server
without fetching it, so it does not have to re-fetch a same file, knows if the resource has changed without fetching it, so it does
which is a win as well. not have to re-fetch the same content, which is a win as well.
This is explained in Section 4.2.
4. When the client wants to simplify the implementation without
compromising the security. If the request parameters go through
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
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.
This simplifies the implementation.
This capability is in use by OpenID Connect [OpenID.Core]. This capability is in use by OpenID Connect [OpenID.Core].
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
skipping to change at page 4, line 31 skipping to change at page 5, line 15
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 an OAuth 2.0 authorization request. It request parameters for an OAuth 2.0 authorization request. It
contains OAuth 2.0 [RFC6749] authorization request parameters contains OAuth 2.0 [RFC6749] authorization request parameters
including extension parameters. It is a JSON Web Signature (JWS) including extension parameters. The parameters are represented as
[RFC7515] signed JWT [RFC7519] . The parameters are represented as
the JWT claims. Parameter names and string values MUST be included the JWT claims. 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 [RFC7159] It MAY include any extension parameters. This JSON [RFC7159]
constitutes the JWT [RFC7519] Claims Set. constitutes the JWT Claims Set [RFC7519]. The JWS Claims Set is then
signed, encrypted, or signed and encrypted.
The Request Object MAY be signed or be an Unsecured JWS. When it is To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a
an unsecured JWS, this is indicated by use of the "none" algorithm JWS signed JWT [RFC7519]. If signed, the Authorization Request
JWA [RFC7518] in the JWS header. If signed, the Authorization Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
Request Object SHOULD contain the Claims "iss" (issuer) and "aud" as members, with their semantics being the same as defined in the JWT
(audience) as members, with their semantics being the same as defined [RFC7519] specification.
in the JWT [RFC7519] specification.
The Request Object MAY also be encrypted using JWE [RFC7516] and MAY To encrypt, JWE [RFC7516] is used. Note that JWE is always integrity
be encrypted without also being signed. If both signing and protected, so if only integrity protection is desired, JWS signature
encryption are performed, it MUST be signed then encrypted, with the is not needed.
result being a Nested JWT, as defined in JWT [RFC7519].
The Authorization Request Object MAY alternatively be sent by It can also be signed then encrypted. This is sometimes desired to
reference using the "request_uri" parameter. reduced the repudiation risk from the point of view of the receiver.
In this case, it MUST be signed then encrypted, with the result being
a Nested JWT, as defined in JWT [RFC7519].
The Authorization Request Object may be sent by value as described in
Section 4.1 or by reference as described in Section 4.2.
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 query parameters. If
a required parameter is not present in neither the query parameter a required parameter is missing from both the query parameters and
nor the Request Object, it forms a malformed request. the Request Object, the request is malformed.
"request" and "request_uri" parameters MUST NOT be included in "request" and "request_uri" parameters MUST NOT be included in
Request Objects. Request Objects.
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, the values in the Request Object takes Authorization Request Object, the values in the Request Object take
precedence. This means that if it intends to use a cached request precedence. This means that if it intends to use a cached request
object, it cannot include such parameters like "state" that is object, it cannot include parameters such as "state" that are
expected to differ in every request. It is fine to include them in 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. the request object if it is going to be prepared afresh every time.
The following is a non-normative example of the Claims in a Request The following is a non-normative example of the Claims in a Request
Object before base64url encoding and signing. Note that it includes Object before base64url encoding and signing. Note that it includes
extension variables such as "nonce", "userinfo", and "id_token". extension variables such as "nonce" and "max_age".
{ {
"iss": "s6BhdRkqt3", "iss": "s6BhdRkqt3",
"aud": "https://server.example.com", "aud": "https://server.example.com",
"response_type": "code id_token", "response_type": "code id_token",
"client_id": "s6BhdRkqt3", "client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb", "redirect_uri": "https://client.example.org/cb",
"scope": "openid", "scope": "openid",
"state": "af0ifjsldkj", "state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj", "nonce": "n-0S6_WzA2Mj",
"max_age": 86400, "max_age": 86400
"claims":
{
"userinfo":
{
"given_name": {"essential": true},
"nickname": null,
"email": {"essential": true},
"email_verified": {"essential": true},
"picture": null
},
"id_token":
{
"gender": null,
"birthdate": {"essential": true},
"acr": {"values": ["urn:mace:incommon:iap:silver"]}
}
}
} }
Signing it with the "RS256" algorithm results in this Request Object Signing it with the "RS256" algorithm results in this Request Object
value (with line wraps within values for display purposes only): value (with line wraps within values for display purposes only):
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
skipping to change at page 6, line 47 skipping to change at page 7, line 24
7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF 7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF
I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa
ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR
adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV
W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
"e":"AQAB" "e":"AQAB"
} }
4. Authorization Request 4. Authorization Request
The client constructs the authorization request URI by adding the The client constructs the authorization request URI by adding one of
following parameters to the query component of the authorization the following parameters but not both to the query component of the
endpoint URI using the "application/x-www-form-urlencoded" format: authorization endpoint URI using the "application/x-www-form-
urlencoded" format:
request REQUIRED unless "request_uri" is specified. The Request
Object (Section 3) that holds authorization request parameters
stated in the section 4 of OAuth 2.0 [RFC6749].
request_uri REQUIRED unless "request" is specified. The absolute request The Request Object (Section 3) that holds authorization
URL that points to the Request Object (Section 3) that holds request parameters stated in the section 4 of OAuth 2.0 [RFC6749].
authorization request parameters stated in the section 4 of OAuth
2.0 [RFC6749].
state RECOMMENDED. OAuth 2.0 [RFC6749] state. request_uri The absolute URL that points to the Request Object
(Section 3) that holds authorization request parameters stated in
the section 4 of OAuth 2.0 [RFC6749].
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:
GET /authorize?request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 GET /authz?request=eyJhbG..AlMGzw HTTP/1.1
Host: server.example.com Host: server.example.com
The value for the request parameter is abbreviated for brevity.
The authorization request object MAY be signed AND/OR encrypted. The authorization request object MAY be signed AND/OR encrypted.
When the "request" parameter is used, the OAuth 2.0 request parameter When the Request Object is used, the OAuth 2.0 request parameter
values contained in the JWT supersede those passed using the OAuth values contained in the JWT supersede those passed using the OAuth
2.0 request syntax. However, parameters MAY also be passed using the 2.0 request syntax. However, parameters MAY also be passed using the
OAuth 2.0 request syntax even when a Request Object is used; this OAuth 2.0 request syntax even when a Request Object is used; this
would typically be done to enable a cached, pre-signed (and possibly would typically be done to enable a cached, pre-signed (and possibly
pre-encrypted) Request Object value to be used containing the fixed pre-encrypted) Request Object value to be used containing the fixed
request parameters, while parameters that can vary with each request, request parameters, while parameters that can vary with each request,
such as state and nonce, are passed as OAuth 2.0 parameters. such as state and nonce, are passed as OAuth 2.0 parameters.
4.1. Passing a Request Object by Value 4.1. Passing a Request Object by Value
skipping to change at page 9, line 21 skipping to change at page 9, line 31
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. There The entire Request URI MUST NOT exceed 512 ASCII characters. There
are three reasons for this restriction. are three reasons for this restriction.
1. Many WAP / feature phones do not accept large payloads. The 1. Many WAP / feature phones do not accept large payloads. The
restriction are typically either 512 or 1024 ASCII characters. restriction are typically either 512 or 1024 ASCII characters.
2. The maximum URL length supported by Internet Explorer is 2083 2. The maximum URL length supported by older versions of Internet
ASCII characters. Explorer is 2083 ASCII characters.
3. On a slow connection such as 2G mobile connection, a large URL 3. On a slow connection such as 2G mobile connection, a large URL
would cause the slow response and using such is not advisable would cause the slow response and using such is not advisable
from the user experience point of view. 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
skipping to change at page 10, line 32 skipping to change at page 10, line 32
luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
4.2.1. URL Referencing the Request Object 4.2.1. URL Referencing the Request Object
The Client stores the Request Object resource either locally or The Client stores the Request Object resource either locally or
remotely at a URL the Server can access. This URL is the Request remotely at a URL the Authorization Server can access. This URL is
URI, "request_uri". the Request URI, "request_uri".
If the Request Object includes requested values for Claims, it MUST It is possible for the Request Object to include values that is to be
NOT be revealed to anybody but the Authorization Server. As such, revealed only to the Authorization Server. As such, the
the "request_uri" MUST have appropriate entropy for its lifetime. It "request_uri" MUST have appropriate entropy for its lifetime. It is
is RECOMMENDED that it be removed if it is known that it will not be RECOMMENDED that it be removed if it is known that it will not be
used again or after a reasonable timeout unless access control used again or after a reasonable timeout unless access control
measures are taken. measures are taken.
The following is a non-normative example of a Request URI value (with The following is a non-normative example of a Request URI value (with
line wraps within values for display purposes only): line wraps within values for display purposes only):
https://client.example.org/request.jwt# https://client.example.org/request.jwt#
GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
4.2.2. Request using the "request_uri" Request Parameter 4.2.2. Request using the "request_uri" Request Parameter
skipping to change at page 11, line 37 skipping to change at page 11, line 37
The following is a non-normative example of this fetch process: The following is a non-normative example of this fetch process:
GET /request.jwt HTTP/1.1 GET /request.jwt HTTP/1.1
Host: client.example.org Host: client.example.org
5. Validating JWT-Based Requests 5. Validating JWT-Based Requests
5.1. Encrypted Request Object 5.1. Encrypted Request Object
The Authorization Server MUST decrypt the JWT in accordance with the The Authorization Server MUST decrypt the JWT in accordance with the
JSON Web Encryption [RFC7516] specification. The result MAY be JSON Web Encryption [RFC7516] specification. If the result is a
either a signed or unsigned (plaintext) Request Object. In the signed request object, signature validation MUST be performed as
former case, signature validation MUST be performed as defined in defined in Section 5.2 as well.
Section 5.2.
The Authorization Server MUST return an error if decryption fails. The Authorization Server MUST return an error if decryption fails.
5.2. Signed Request Object 5.2. Signed Request Object
To perform Signature Validation, the "alg" Header Parameter in the To perform Signature Validation, the "alg" Header Parameter in the
JOSE Header MUST match the value of the "request_object_signing_alg" JOSE Header MUST match the value of the pre-registered algorithm.
set during Client Registration or a value that was pre-registered by The signature MUST be validated against the appropriate key for that
other means. The signature MUST be validated against the appropriate "client_id" and algorithm.
key for that "client_id" and algorithm.
The Authorization Server MUST return an error if signature validation The Authorization Server MUST return an error if signature validation
fails. fails.
5.3. Request Parameter Assembly and Validation 5.3. Request Parameter Assembly and Validation
The Authorization Server MUST assemble the set of Authorization The Authorization Server MUST assemble the set of Authorization
Request parameters to be used from the Request Object value and the Request parameters to be used from the Request Object value and the
OAuth 2.0 Authorization Request parameters (minus the "request" or OAuth 2.0 Authorization Request parameters (minus the "request" or
"request_uri" parameters). If the same parameter exists both in the "request_uri" parameters). If the same parameter exists both in the
Request Object and the OAuth Authorization Request parameters, the Request Object and the OAuth Authorization Request parameters, the
parameter in the Request Object is used. Using the assembled set of parameter in the Request Object is used. Using the assembled set of
Authorization Request parameters, the Authorization Server then Authorization Request parameters, the Authorization Server then
validates the request as specified in OAuth 2.0 [RFC6749]. validates the request as specified in OAuth 2.0 [RFC6749].
6. Authorization Server Response 6. Authorization Server Response
Authorization Server Response is created and sent to the client as in Authorization Server Response is created and sent to the client as in
Section 4 of OAuth 2.0 [RFC6749] . Section 4 of OAuth 2.0 [RFC6749] .
In addition, this document defines additional error values as In addition, this document uses these additional error values:
follows:
invalid_request_uri The "request_uri" in the Authorization Request invalid_request_uri The "request_uri" in the Authorization Request
returns an error or contains invalid data. returns an error or contains invalid data.
invalid_request_object The request parameter contains an invalid invalid_request_object The request parameter contains an invalid
Request Object. Request Object.
request_not_supported The Authorization Server does not support the request_not_supported The Authorization Server does not support the
use of the "request" parameter. use of the "request" parameter.
request_uri_not_supported The Authorization Server does not support request_uri_not_supported The Authorization Server does not support
use of the "request_uri" parameter. use of the "request_uri" parameter.
7. IANA Considerations 7. IANA Considerations
The request_object_signing_alg OAuth Dynamic Client Registration This specification requests no actions by IANA.
Metadata is pending registration by OpenID Connect Dynamic
Registration specification.
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 [RFC7515]. The "alg=none" SHOULD NOT be used in such algorithm using [RFC7515]. The "alg=none" SHOULD NOT be used in such
skipping to change at page 13, line 16 skipping to change at page 13, line 10
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 [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. (Affiliations at the time of the contribution is used.)
Michael B. Jones (Microsoft), Axel Nenker(DT), Sergey Beryozkin, Jim Sergey Beryozkin, Brian Campbell (Ping Identity), Michael B. Jones
Manico, (add yourself). (Microsoft), Jim Manico, Axel Nenker(DT), (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), Ryo Itou (Yahoo! Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou
Japan), George Fletcher (AOL), Justin Richer (MITRE), Edmund Jay (Yahoo! Japan), Edmund Jay (Illumila), Michael B. Jones
(Illumila), Michael B. Jones (Microsoft), (add yourself). (Microsoft), Breno de Medeiros (Google), Hideki Nara (TACT), Justin
Richer (MITRE), (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 Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer
(Telstra), Marius Scurtescu (Google), John Panzer (Google), Dirk (Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke
Balfanz (Google), (add yourself). Shepard (Facebook), (add yourself).
10. Revision History 10. Revision History
-07
o Changed the abbrev to OAuth JAR from oauth-jar.
o Clarified sig and enc methods.
o Better English.
o Removed claims from one of the example.
o Re-worded the URI construction.
o Changed the example to use request instead of request_uri.
o Clarified that Request Object parameters takes precedence
regardless of request or request_uri parameters were used.
o Generalized the language in 4.2.1 to convey the intent more
clearly.
o Changed "Server" to "Authorization Server" as a clarification.
o Stopped talking about request_object_signing_alg.
o IANA considerations now reflect the current status.
o Added Brian Campbell to the contributers list. Made the lists
alphabetic order based on the last names. Clarified that the
affiliation is at the time of the contribution.
o Added "older versions of " to the reference to IE uri length
limitations.
o Stopped talking about signed or unsigned JWS etc.
o 1.Introduction improved.
-06 -06
o Added explanation on the 512 chars URL restriction. o Added explanation on the 512 chars URL restriction.
o Updated Acknowledgements. o Updated Acknowledgements.
-05 -05
o More alignment with OpenID Connect. o More alignment with OpenID Connect.
 End of changes. 40 change blocks. 
121 lines changed or deleted 169 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/