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

From: [email-masked]
Date: Tue, 19 Jan 2016 01:43:31 -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           : OAuth 2.0 JWT Authorization Request
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-07.txt
	Pages           : 16
	Date            : 2016-01-19

Abstract:
   The authorization request in OAuth 2.0 [RFC6749] 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.  using JWT
   serialization.  The request is 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-07

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

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: Tue, 19 Jan 2016 18:55:11 +0900

Hi. 

Took much longer than I anticipated but I finally applied the comments I
received during the WGLC. 

When broken down, there were 44 comments that needed to be dealt with. 

I have accepted most of them. There are a few discussion points, and a few
rejects. 

I am now making the list of those, but as I am going into a meeting now, it
will not be available before tomorrow. 

For a preview, you can go and see them in
https://bitbucket.org/Nat/oauth-jwsreq/issues?status=new&status=open. There
are two sets of comments provided by Mike and Brian as of the time of this
writing. They have unresolved comments. I have recorded my dispositions
there so if you are so inclined, please have a look. 

I will pull out those points as separate issues in the tracker so that they
can be individually tracked. 

Cheers, 

Nat Sakimura

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

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 19, 2016 6:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-07.txt

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.

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Jan 2016 03:02:19 +0000

And, here is the list of remaining issues that needs discussion.

#9: Section 3 - parameter name conflict with Proof-of-Posession.
<https://bitbucket.org/Nat/oauth-jwsreq/issues/9/section-3-parameter-name-conflict-with>

... the Authorization Request Object SHOULD contain the Claims "iss"
(issuer) and "aud" (audience) as members ...'

However, that will produce a parameter name conflict with the "aud"
parameter from OAuth 2.0 Proof-of-Possession: Authorization Server to
Client Key Distribution.

Seems like draft-ietf-oauth-pop-key-distribution will need to change its
parameter name (aud in JWT is pretty well established). And shouldn't
draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim Names
(at least iss and aud but maybe exp and others) as authorization request
OAuth parameters?

(Brian Campbell)

Need to settle on what is to be done before making changes.

#8: Section 3, it is unclear whether the Request Object can be a JWE only
or if a JWS is always used
<https://bitbucket.org/Nat/oauth-jwsreq/issues/8/section-3-it-is-unclear-whether-the>

(Brian Campbell)

I think we wanted always do JWS and then JWE, but I am not sure. Please
discuss.

#7: Section 8, second paragraph: Delete the security considerations
paragraph about not using "alg":"none".
<https://bitbucket.org/Nat/oauth-jwsreq/issues/7/section-8-second-paragraph-delete-the>

Section 8, second paragraph: Delete the security considerations paragraph
about not using "alg":"none". Using an Unsecured JWS is no worse than
sending the parameters the usual way.

(Mike Jones)

Propose Reject. It is no worse, but it is better to sign. Thus, it is using
"SHOULD" but not "MUST".