[OAUTH-WG] Review of draft-ietf-oauth-jwsreq-06

[Hannes Tschofenig <[e-mail]>]

Hi Nat, Hi John,

thanks for the work on this document. I have started my review and
wanted to post a few thoughts about the abstract and the introduction.

I have some wording suggestions for the abstract. Here is the current
abstract:

"
   The authorization request in RFC6749 utilizes query parameter
   serialization.  This specification defines the authorization request
   using JWT serialization.  The request is sent by value through
   "request" parameter or by reference through "request_uri" parameter
   that points to the JWT, allowing the request to be optionally signed
   and encrypted.
"

Here is my new proposal:


"
The authorization request in OAuth 2.0 utilizes query parameter
serialization, which means that parameters are encoded in the URI of the
request. This document introduces the ability to send
request parameters in form of a JSON Web Token (JWT) instead, which
allows the request to be signed and encrypted. The request is sent by
value or by reference.

We call the 'JWT Authorization Request' extension JAR.
"

1. Introduction

I would expect the following structure of this section.

 a) A description on how things are done today. Here is a proposal:

"
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
"

 b) Why are we making changes / additions? What is wrong with the
current way of doing things?

Here is a proposal:
"
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.
"

The request by reference allows to reduce the over-the-wire overhead.

 c)  What is the solution (at a high level) described in the document?

"
   The parameters "request" and "request_uri" are introduced as
   additional authorization request parameters for the OAuth 2.0
   [RFC6749] flows.  The "request" parameter is a JSON Web Token (JWT)
   [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0
   authorization request parameters.  The JWT [RFC7519] can be passed to
   the authorization endpoint by reference, in which case the parameter
   "request_uri" is used instead of the "request".
"

You may want to explain why you have chosen the JWT format rather than
something else, such as the CBOR format.

I have a few comments regarding the benefits of the <request by
reference>. You write:


   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
       URLs: Some extensions may extend the URL.  For example, the
       client might want to send a public key with the request.

[Hannes] I believe what you are trying to say in this section is that
the use of the reference reduces the size of the transmitted request
since the use of application layer security, and public
key cryptography in particular, substantially increases the size.

   2.  Static signature: The client can make a signed Request Object and
       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
       the private key does not have to reside on the client,
       simplifying programming.

[Hannes] The downside of this approach is that it is vulnerable to reply
protection and the signature only becomes a token. Another downside is
that the developer(?) has to place the JWT at
some server first.

   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
       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,
       which is a win as well.

[Hannes] I believe that this is a by-product of item #2. I am not sure
what the hash of the file means here.


   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.

[Hannes] Could you  explain this threat a bit more? Is this aspect
related to some prior OAuth work, such as PKCE?

Ciao
Hannes