[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt

[i***@ietf.org]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

Title : OAuth 2.0 JWT Authorization Request (JAR)
Authors : Nat Sakimura
John Bradley
Filename : draft-ietf-oauth-jwsreq-08.txt
Pages : 21
Date : 2016-08-03

Abstract:
The authorization request in OAuth 2.0 [RFC6749] utilizes query
parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authentciated. Because of
these weaknesses, several attacks to the protocol have now been put
forward.

This document introduces the ability to send request parameters in a
JSON Web Token (JWT) instead, which allows the request to be JWS
signed and/or JWE encrypted so that the integrity, source
authentication and confidentiallity property of the Authorization
Request is attained. The request can be sent by value or by
reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[Vladimir Dzhuvinov]

Thanks Nat.

It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID
Connect in regard to

1. alg:none request JWTs being no longer permitted

2. HTTPS request_uri's becoming always required, though there is
confusion about that (see below).


I don't know if this is intentional.



Quoting the original Connect spec on alg:none:

http://openid.net/specs/openid-connect-core-1_0.html#RequestObject

```
The Request Object MAY be signed or unsigned (plaintext). When it is
plaintext, this is indicated by use of the none algorithm [JWA]
<http://openid.net/specs/openid-connect-core-1_0.html#JWA> in the JOSE
Header.
```


There is also confusion about the requirement to have HTTPS, which in
5.2 is conditionally required, and in 5.2.1 always required (the 5.2.1
edit appeared in -08).

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2

```

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",
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server.
```


https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1

```

The URL MUST be HTTPS URL.

```


Cheers,

Vladimir

[Vladimir Dzhuvinov]

I would like to propose a slight change of the spec title.


From

*OAuth 2.0 JWT Authorization Request*


to

*JSON Web Token (JWT) Secured OAuth 2.0 Authorization Request*


The current title is not particularly descriptive, and may even read as
if the spec is about requesting a JWT.


Thanks,


Vladimir

[Nat Sakimura]

Hi.



I am open to change, but I would like to have a nice abbreviation as well.



What about the following?



The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
(JAR)



Best,



Nat



--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender and delete this e-mail.



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, August 4, 2016 7:15 PM
To: ***@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt



I would like to propose a slight change of the spec title.



From

OAuth 2.0 JWT Authorization Request



to

JSON Web Token (JWT) Secured OAuth 2.0 Authorization Request



The current title is not particularly descriptive, and may even read as if
the spec is about requesting a JWT.



Thanks,



Vladimir

[Vladimir Dzhuvinov]

Post by Nat Sakimura
Hi.
I am open to change, but I would like to have a nice abbreviation as well.
What about the following?
The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
(JAR)

This is a good suggestion, I find this more descriptive, and it fits the
title pattern of RFC 6749 and RFC 6750.

JWT should probably be spelled in full though (this seems to be the
practice).

Vladimir

Post by Nat Sakimura
Best,
Nat
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
Sent: Thursday, August 4, 2016 7:15 PM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
I would like to propose a slight change of the spec title.
From
OAuth 2.0 JWT Authorization Request
to
JSON Web Token (JWT) Secured OAuth 2.0 Authorization Request
The current title is not particularly descriptive, and may even read as if
the spec is about requesting a JWT.
Thanks,
Vladimir

[Nat Sakimura]

Hi Vladimir,



Thanks for the quick response and review.

Post by Vladimir Dzhuvinov
1. alg:none request JWTs being no longer permitted

I think it is a bug of the OpenID Connect Core 1.0.



Request Object itself can be alg=none in OAuth JAR draft 08 as well.



If alg=none, it MUST NOT be passed by value using `request` parameter.

It is fine to be that way as long as you pass it by reference.



Like OAuth JAR draft-08, OpenID Connect used to have a section dedicated to
"Request Object" if I remember correctly. However, during the re-factoring,
it was subsumed in "5.5. Requesting Claims using the "claims" Request
Parameter" and the statement about allowing alg=none in Request Object that
are passed by value sneaked in there.



I am going to file a bug report for OpenID Connect on this.



Or, do you have any specific use case for keeping "alg=none" for the
"passing by value" case?

Post by Vladimir Dzhuvinov
2. HTTPS request_uri's becoming always required, though there is confusion

about that (see below).
I should remove the statement in 5.2.1., as it just meant to have repeated
what it was said in 5.2.



I should also add further condition in 5.2. so that it becomes:



```

unless the target Request Object is signed in a way that is

verifiable by the Authorization Server and the channel is

protected so that network attacker cannot observe.

```



What do you think?



Nat



--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender and delete this e-mail.



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, August 4, 2016 6:59 PM
To: ***@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt



Thanks Nat.

It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Connect
in regard to

1. alg:none request JWTs being no longer permitted

2. HTTPS request_uri's becoming always required, though there is confusion
about that (see below).



I don't know if this is intentional.



Quoting the original Connect spec on alg:none:

http://openid.net/specs/openid-connect-core-1_0.html#RequestObject

```
The Request Object MAY be signed or unsigned (plaintext). When it is
plaintext, this is indicated by use of the none algorithm
<http://openid.net/specs/openid-connect-core-1_0.html#JWA> [JWA] in the JOSE
Header.
```


There is also confusion about the requirement to have HTTPS, which in 5.2 is
conditionally required, and in 5.2.1 always required (the 5.2.1 edit
appeared in -08).

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2

```

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",
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server.
```


https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1

```

The URL MUST be HTTPS URL.

```


Cheers,

Vladimir

[Vladimir Dzhuvinov]

Hi Nat,

Post by Nat Sakimura

Post by Vladimir Dzhuvinov
1. alg:none request JWTs being no longer permitted

I think it is a bug of the OpenID Connect Core 1.0.
Request Object itself can be alg=none in OAuth JAR draft 08 as well.
If alg=none, it MUST NOT be passed by value using `request` parameter.
It is fine to be that way as long as you pass it by reference.
Like OAuth JAR draft-08, OpenID Connect used to have a section dedicated to
"Request Object" if I remember correctly. However, during the re-factoring,
it was subsumed in "5.5. Requesting Claims using the "claims" Request
Parameter" and the statement about allowing alg=none in Request Object that
are passed by value sneaked in there.
I am going to file a bug report for OpenID Connect on this.
Or, do you have any specific use case for keeping "alg=none" for the
"passing by value" case?

An "alg:none" request object has no value if it's passed by value, so
yes, in that sense we can call it a bug.

The only potential use case I see for "alg:none" is clients that can't
handle crypto but may be able to pass the JWT via a HTTPS URL (perhaps
preregistered).


BTW, I don't see request URI registration mentioned, and this is quite a
significant feature, especially in dynamic scenarios.

Post by Nat Sakimura

Post by Vladimir Dzhuvinov
2. HTTPS request_uri's becoming always required, though there is confusion

about that (see below).
I should remove the statement in 5.2.1., as it just meant to have repeated
what it was said in 5.2.

I see.

Post by Nat Sakimura
```
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server and the channel is
protected so that network attacker cannot observe.
```
What do you think?

On the 1st condition - HMAC - protected or signed request object to
ensure authenticity - ok, this is a must if the JWT is fed via plain
HTTP, to ensure the parameters cannot be tampered with.

On the 2nd condition - do you mean encrypting the JWT, or something else?

Post by Nat Sakimura
Nat
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
Sent: Thursday, August 4, 2016 6:59 PM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
Thanks Nat.
It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Connect
in regard to
1. alg:none request JWTs being no longer permitted
2. HTTPS request_uri's becoming always required, though there is confusion
about that (see below).
I don't know if this is intentional.
http://openid.net/specs/openid-connect-core-1_0.html#RequestObject
```
The Request Object MAY be signed or unsigned (plaintext). When it is
plaintext, this is indicated by use of the none algorithm
<http://openid.net/specs/openid-connect-core-1_0.html#JWA> [JWA] in the JOSE
Header.
```
There is also confusion about the requirement to have HTTPS, which in 5.2 is
conditionally required, and in 5.2.1 always required (the 5.2.1 edit
appeared in -08).
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2
```
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",
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server.
```
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1
```
The URL MUST be HTTPS URL.
```
Cheers,
Vladimir

[Nat Sakimura]

Hi Vladimir,

-----Original Message-----
Sent: Friday, August 5, 2016 5:15 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
Hi Nat,

Post by Nat Sakimura

Post by Vladimir Dzhuvinov
1. alg:none request JWTs being no longer permitted

I think it is a bug of the OpenID Connect Core 1.0.
Request Object itself can be alg=none in OAuth JAR draft 08 as well.
If alg=none, it MUST NOT be passed by value using `request` parameter.
It is fine to be that way as long as you pass it by reference.
Like OAuth JAR draft-08, OpenID Connect used to have a section dedicated
to "Request Object" if I remember correctly. However, during the
re-factoring,
it was subsumed in "5.5. Requesting Claims using the "claims" Request
Parameter" and the statement about allowing alg=none in Request Object
that are passed by value sneaked in there.
I am going to file a bug report for OpenID Connect on this.
Or, do you have any specific use case for keeping "alg=none" for the
"passing by value" case?

An "alg:none" request object has no value if it's passed by value, so
yes, in that sense we can call it a bug.
The only potential use case I see for "alg:none" is clients that can't
handle crypto but may be able to pass the JWT via a HTTPS URL (perhaps
preregistered).
BTW, I don't see request URI registration mentioned, and this is quite a
significant feature, especially in dynamic scenarios.

It is obscure, I agree. The scenario was there from the beginning,
and I made sure that it is permissible from the very beginning.
The following sentences in 5.2.1 is talking about this.

```
The Client stores the Request Object resource either locally or
remotely at a URL the Authorization Server can access.
```

Then, in Section 10.3, it goes:

```
(c) Authorization Server is providing an endpoint that provides a
Request Object URI in exchange for a Request Object.
[...snip...]

(d) A third party, such as a Trust Framework Provider, provides an
endpoint that provides a Request Object URI in exchange for a
Request Object.
```

BTW, I found a bug in 10.3. (d). The reference (b) in
the paragraph 1 should be (c) instead.

Perhaps I should mention these possibilities in the Intro and
5.2.

More significant change would be to define an API to do it, e.g.,

swagger: '2.0'
info:
version: "1.0.0"
title: Request Registration Endpoint Example
description: |
An example for how to use Request Registration Endpoint.
host: as.example.com
schemes:
- https
securityDefinitions:
basicAuth:
type: basic
description: HTTP Basic Authentication. Works over `HTTPS`
paths:
/v1/requestObjects/:
post:
security:
- basicAuth: []
responses:
200:
description: Request Uri
schema:
$ref: #/definitions/RequestURIResponse
examples:
application/json: |-
{
"request_uri": "file://mc.example.com/aFwfo9w",
}
default:
description: Unexpected Error
schema:
$ref: "#/definitions/Error"

Though it is possible to define something like this in this spec.,
I would rather do it as a separate spec.

Post by Nat Sakimura

Post by Vladimir Dzhuvinov
2. HTTPS request_uri's becoming always required, though there is

confusion

Post by Nat Sakimura
about that (see below).
I should remove the statement in 5.2.1., as it just meant to have repeated
what it was said in 5.2.

I see.

Post by Nat Sakimura
```
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server and the channel is
protected so that network attacker cannot observe.
```
What do you think?

On the 1st condition - HMAC - protected or signed request object to
ensure authenticity - ok, this is a must if the JWT is fed via plain
HTTP, to ensure the parameters cannot be tampered with.
On the 2nd condition - do you mean encrypting the JWT,
or something else?

For example, the Authorization Server (AS) may provide
a Request Object registration service which returns
a HTTP `request_uri` which is only accessible by the AS.

Post by Nat Sakimura
Nat
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.

Dzhuvinov

Post by Nat Sakimura
Sent: Thursday, August 4, 2016 6:59 PM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
Thanks Nat.
It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID

Connect

Post by Nat Sakimura
in regard to
1. alg:none request JWTs being no longer permitted
2. HTTPS request_uri's becoming always required, though there is confusion
about that (see below).
I don't know if this is intentional.
http://openid.net/specs/openid-connect-core-1_0.html#RequestObject
```
The Request Object MAY be signed or unsigned (plaintext). When it is
plaintext, this is indicated by use of the none algorithm
<http://openid.net/specs/openid-connect-core-1_0.html#JWA> [JWA] in

the JOSE

Post by Nat Sakimura
Header.
```
There is also confusion about the requirement to have HTTPS, which in

5.2 is

Post by Nat Sakimura
conditionally required, and in 5.2.1 always required (the 5.2.1 edit
appeared in -08).
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2
```
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",
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server.
```
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1
```
The URL MUST be HTTPS URL.
```
Cheers,
Vladimir

--

--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.