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

From: [email-masked]
Date: Wed, 03 Aug 2016 20:54:57 -0700

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/

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 4 Aug 2016 12:59:05 +0300

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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 4 Aug 2016 13:14:38 +0300

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

---

From: "Nat Sakimura" <[email-masked]>
Date: Thu, 4 Aug 2016 20:00:22 +0900

Hi Vladimir, 

Thanks for the quick response and review. 

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?

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

```

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:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, August 4, 2016 6:59 PM
To: [email-masked]
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

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

```
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).

```

```

```

Cheers,

Vladimir

-- 
Vladimir Dzhuvinov

---

From: "Nat Sakimura" <[email-masked]>
Date: Thu, 4 Aug 2016 20:08:29 +0900

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

--

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

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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 4 Aug 2016 23:15:03 +0300

Hi Nat,

> Or, do you have any specific use case for keeping "alg=none" for the

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.

> I should remove the statement in 5.2.1., as it just meant to have repeated
I see.

> protected so that network attacker cannot observe. 
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?

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 5 Aug 2016 09:09:08 +0300

> The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
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

---

From: "Nat Sakimura" <[email-masked]>
Date: Fri, 5 Aug 2016 18:19:08 +0900

Hi Vladimir, 

See inline: 

> -----Original Message-----
> From: Vladimir Dzhuvinov [mailto:[email-masked]]
> Sent: Friday, August 5, 2016 5:15 AM
> To: Nat Sakimura <[email-masked]>; [email-masked]
> > 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,
> > Parameter" and the statement about allowing alg=none in Request Object
> > that are passed by value sneaked in there.

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. 
> On the 2nd condition - do you mean encrypting the JWT, 

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. 

> Connect
confusion
> 5.2 is