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

From: [email-masked]
Date: Wed, 12 Nov 2014 20:07:29 -0800

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

        Title           : Request by JWS ver.1.0 for OAuth 2.0
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-01.txt
	Pages           : 9
	Date            : 2014-11-12

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

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:
http://tools.ietf.org/html/draft-ietf-oauth-jwsreq-01

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

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: Nat Sakimura <[email-masked]>
Date: Thu, 13 Nov 2014 13:11:54 +0900

This is just a copy edit. 

It is a very short spec, which gives you integrity for the request. 
It has been used in OpenID Connect. 
The real text is only 4 pages long. Please read and comment. 

Nat

On Wed, 12 Nov 2014 20:07:29 -0800
[email-masked] wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Web Authorization
> Protocol Working Group of the IETF.
> 
>    serialization.  This specification defines the authorization
> request using JWT serialization.  The request is sent through
> "request" parameter or by reference through "request_uri" parameter
> that points to the JWT, allowing the request to be optionally signed
> and encrypted.
> 
> 
> 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.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Sakimura ([email-masked])
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 13 Nov 2014 09:45:02 +0000

Hi

Very nice. Can it become drat-oauth-jwsreqres ?
I know spop-04 has been released, we'll update our implementation as 
needed, but if an optional signing of a request is of interest, why 
can't be signing of the response be of interest too ?

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 27 Nov 2014 17:55:09 +0000

Hi

Should the text require that a "client_id" parameter is always included 
as a query parameter too ?

If it is only inside a 'request' parameter then how the server would 
identify a client specific key that can be used to validate the signature ?

Or is the idea that if it is JWS and no client_id query parameter is 
available then a client id is extracted first, the key is identified and 
then the signature is validated ?

Also, a simple example how an optional file hash is specified when a 
request_uri is used would be useful

Many thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Nov 2014 16:22:27 -0300

In sec 6 of openID Connect core we have.

So that the request is a valid OAuth 2.0 Authorization Request, values for the response_type and client_id parameters MUST be included using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0. The values for these parameters MUST match those in the Request Object, if present.

So we should add that in to this text to make it clear that it must still be a well formed OAuth 2 request. 

In Connect we do allow for the possibility that a 3rd party might sign a request object.  

An example was that in some jurisdictions it may be a 3rd party like a privacy commissioner that signs the request object so that the IdP know that the RP is allowed to request those claims.

The processing by the AS is validate the signature based on the "iss"  (typically the client) Compare the client_id to the iss and see if the iss is authoritative for value of the client_id claim (typically one to one).  Compare the client_id claim value with the query parameter client_id value and reject if not the same.  (you could do that first if you want)

The idea of the hash is that allows the AS discover if the content of the request file has changed without getting it.

The example from connect is:

  https://client.example.org/request.jwt#GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

The server needs to remember the full URI of the request object and refetch it when the fragment changes.

Without the fragment the AS would need to rely on http:caching and at-least to a HEAD each time.

That section can be expanded.

John B.

> On Nov 27, 2014, at 2:55 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi
> 
> Should the text require that a "client_id" parameter is always included as a query parameter too ?
> 
> If it is only inside a 'request' parameter then how the server would identify a client specific key that can be used to validate the signature ?
> 
> Or is the idea that if it is JWS and no client_id query parameter is available then a client id is extracted first, the key is identified and then the signature is validated ?
> 
> Also, a simple example how an optional file hash is specified when a request_uri is used would be useful
> 
> Many thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 27 Nov 2014 21:04:10 +0000

Hi John
> So we should add that in to this text to make it clear that it must still be a well formed OAuth 2 request.
Thanks for the clarification, I did assume, while prototyping the 
client_id was available as a dedicated query parameter too
> That section can be expanded.
Very nice explanation above, thanks, sorry I did not do my home work and 
reviewed the connect text :-).

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Nov 2014 18:09:34 -0300

The Connect text is lacking detail on why you might have different values for "iss" and client_id.   We should cover that in more detail in this.

That is one good thing about going back and focusing on a specific part of the spec to pull it out into a separate spec is that it raises questions, that might have been glossed over in the larger context.

John B.

> On Nov 27, 2014, at 6:04 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi John
> Thanks for the clarification, I did assume, while prototyping the client_id was available as a dedicated query parameter too
> Very nice explanation above, thanks, sorry I did not do my home work and reviewed the connect text :-).
> 
> Thanks, Sergey
> 
>> John B.
>> 
>> 
>>