Hannes's WGLC Comments

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

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:

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.

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.

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.

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

Comments (1)