Subject: [OAUTH-WG] Timely review request: pre-draft-17

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Jul 2011 22:09:17 -0700

I have started sharing my planned changes for 17:

https://github.com/hueniverse/draft-ietf-oauth

Change log:

https://github.com/hueniverse/draft-ietf-oauth/commit/24a48f99c204331264028
f66708427961a1bc102#diff-3

My main focus right now is to clarify client types, registration, and
identification, as well as tweak the registration requirements for
redirection URIs. This is still very raw. However, I would very much like
to get feedback about the following sections:

1.1.1.  Client Types
1.2.  Client Registration

2.1.1.  Redirection URI

In section 2.1.1, please note that it includes many new normative
requirements, but in practice, they mostly boil down to the requirement to
register a redirection URI for using the implicit grant type as well as
using the authorization code with a public client (new term for describing
client incapable of keeping secrets).

I have turned the spec around, making registered redirection URIs the
default, and using the parameter as an optional feature.

Feedback is very much appreciated as we only have a few more days before I
have to push out -17 and would like a few more eyes looking at the new
text before published.

I am still not ready to share changes to section 3. Also, I have a long
list of additional changes raised on the list.

Thanks,

EHL

---

From: Shane B Weeden <[email-masked]>
Date: Wed, 6 Jul 2011 06:24:36 +1000

Looking at the .txt version:

1. Line 260 s/authentication/authenticate

   OAuth defines two client types, based on their ability to maintain
   the confidentiality of their client credential, used to
   authentication with the authorization server:

2. Line 274 s/with with/with

   Before initiating the protocol, the client registers with with the

3. Line 508 s/denote/denotes

   the client.  The token denote an identifier used to retrieve the

4. In section 1.6, I still find it misleading to say:
   The refresh token is bound to the client it was issued to, and its usage
requires client authentication.
This still implies "public clients" can't use refresh tokens by way of the
authentication requirement. I now understand the language in section 3
regarding an authorization server's discretion with client authentication,
but I would propose either dropping ", and it's usage requires client
authentication" above, or changing it to:
    The refresh token is bound to the client it was issued to.
Authorization servers should require client authentication for private
clients when a refresh token is presented.

5. Is section 3.1 still [[Pending Consensus]] ?

6. Section 4.1.1 Authorization Request and section 4.2.1 Authorization
Request
To protect against CSRF I believe the state parameter should be REQUIRED,
unless someone can demonstrate a scenario where it is not used and CSRF is
avoided by other means.

Regards,
Shane.

From:	Eran Hammer-Lahav <[email-masked]>
To:	OAuth WG <[email-masked]>
Date:	05-07-11 03:13 PM
Subject:	[OAUTH-WG] Timely review request: pre-draft-17
Sent by:	[email-masked]

Change log:

1.1.1.  Client Types
1.2.  Client Registration

2.1.1.  Redirection URI

Thanks,

EHL

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Jul 2011 15:39:42 -0700

From: Shane Weeden <[email-masked]<mailto:[email-masked]>>
Date: Tue, 5 Jul 2011 13:24:36 –0700

We need more text explaining exactly how the state parameter should be used to prevent CSRF if we are going to make it required (I don't have a position on the actual proposal). Otherwise, including it with a fixed value satisfy the requirement without adding any value (just wasting bandwidth).

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 01:01:26 -0700

I finished the major part of -17, adding a new Client registration section and folding client authentication into it. This new text attempts to directly address:

* client authentication requirements
* define client types with regard to keeping secrets
* set registration requirements
* properly explain client identifier
* replace client credentials with a more generic client authentication (in terms used throughout the document)
* provide a comprehensive discussion of redirection URIs (this is where the few normative changes are)
* tweak the implicit and authorization code intros to better reflect reality ('optimized for')
* separate client identifier from client authentication (keep binding requirement)

Normative changes (this should be verified):

* require client authentication for private clients (previously implied)
* require redirection endpoint registration for implicit grant and all for public clients requests
* remove client_id as a required parameter from the token endpoint (now back to being part of the client_secret pair)

The draft includes other changes like new error codes, but I'll list those when the draft is published. I still have about 32 more items on my list to apply before publishing, but the major changes are done.

You can always find the latest here:

Early review of the following sections would be GREALY appreciated:

2.  Client Registration
    2.1.  Client Types
    2.2.  Registration Requirements
    2.3.  Client Identifier
    2.4.  Client Authentication
        2.4.1.  Client Password
        2.4.2.  Other Authentication Methods
    2.5.  Unregistered Clients

3.1.2.  Redirection URI

3.2.1.  Client Authentication

-17 will be published by Friday at which point I will leave it to the chairs to decide if they still want to initiate WGLC or give the draft a few days of informal review.

EHL

> -----Original Message-----
> From: Eran Hammer-Lahav
> Sent: Monday, July 04, 2011 10:09 PM
> To: OAuth WG
> Subject: Timely review request: pre-draft-17
> 
> identification, as well as tweak the registration requirements for redirection
> URIs. This is still very raw. However, I would very much like to get feedback
> about the following sections:
> 
> 1.1.1.  Client Types
> 1.2.  Client Registration
> 
> 2.1.1.  Redirection URI
> 
> 
> register a redirection URI for using the implicit grant type as well as using the
> authorization code with a public client (new term for describing client
> incapable of keeping secrets).
> 
> have to push out -17 and would like a few more eyes looking at the new text
> before published.
> 
> I am still not ready to share changes to section 3. Also, I have a long list of
> additional changes raised on the list.
> 
> Thanks,
> 
> EHL
> 
> 
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jul 2011 09:48:59 -0400

On Thu, Jul 7, 2011 at 4:01 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> -17 will be published by Friday at which point I will leave it to
> the chairs to decide if they still want to initiate WGLC or give
> the draft a few days of informal review.

Working-group last call can cover all reviews of this.  It's a less
formal thing than IETF last call, which the IESG will initiate
later... and we can recycle the document and do another WGLC if it
turns out that we got something so seriously wrong that it's
necessary.

And I'd like to take this opportunity to say that the chairs are happy
with the progress, and we thank everyone for the careful reviews, and
for working together to get this work wrapped up.

Barry, as chair

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 23:48:33 -0700

Almost done with -17.

I have sent a few emails to the list with open questions and requests. I will include as many of the replies as I can before publishing tomorrow or Saturday.

My remaining task is to try and move as much of the normative text (MUST, SHOULD) out of the security consideration section and into the relevant sections where the actual component is discussed. I also need to review all the normative language and make sure it is consistent (found a few MUST in one spot and SHOULD in another).

Changes not discussed fully on the list are marked with [[ Pending Consensus ]].

EHL

> Sent: Thursday, July 07, 2011 1:01 AM
> To: OAuth WG
> Subject: RE: Timely review request: pre-draft-17
> 
> I finished the major part of -17, adding a new Client registration section and
> folding client authentication into it. This new text attempts to directly
> address:
> 
> * remove client_id as a required parameter from the token endpoint (now
> back to being part of the client_secret pair)
> 
> The draft includes other changes like new error codes, but I'll list those when
> the draft is published. I still have about 32 more items on my list to apply
> before publishing, but the major changes are done.
> 
> -17 will be published by Friday at which point I will leave it to the chairs to
> decide if they still want to initiate WGLC or give the draft a few days of
> informal review.
> 
> EHL
> 
> 
> > redirection URIs. This is still very raw. However, I would very much
> > like to get feedback about the following sections:
> >
> > 1.1.1.  Client Types
> > 1.2.  Client Registration
> >
> > 2.1.1.  Redirection URI
> >
> >
> > requirements, but in practice, they mostly boil down to the
> > requirement to register a redirection URI for using the implicit grant
> > type as well as using the authorization code with a public client (new
> > term for describing client incapable of keeping secrets).
> >
> > Feedback is very much appreciated as we only have a few more days
> > before I have to push out -17 and would like a few more eyes looking
> > at the new text before published.
> >
> > I am still not ready to share changes to section 3. Also, I have a
> > long list of additional changes raised on the list.
> >
> > Thanks,
> >
> > EHL
> >
> >
> >