Subject: [OAUTH-WG] Draft -16

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 18 May 2011 16:42:43 -0700

Draft -16 should show up in a few minutes. This will be the last draft before the meeting next week and the reference document for discussion. If you plan to attend the meeting, this is a required reading.

Changes since -15:

-          New security consideration section (closes issue #7)

-          Reintroduced native application section (closes issues #13)

-          Reworked section 3 (client authentication) to restore HTTP Basic as the recommended scheme.

-          Removed [[ pending consensus ]] labels off error extensibility (closes issues #10 and #11)

-          Added note about username and password being UTF-8 encoded

-          Clarified that extension grant types must use section 5 responses

-          Minor language fixes, new abstract

The only open issues remaining are some missing security consideration sections and language encoding for error_description.

I will do my best to make -17 the last working group draft before final WG last call.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 18 May 2011 16:44:43 -0700

I forgot to mention (the obvious) that the chairs will follow up on each open issue with their own notes and will do the actual determination with regard to closing issues.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, May 18, 2011 4:43 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft -16

Changes since -15:

EHL

---

From: Doug Tangren <[email-masked]>
Date: Wed, 18 May 2011 22:09:31 -0400

Followup questions from draft 16

1. On storing user password for the resource owner creds flow. If the client
stores a access token along with the refresh token [1] to refresh it, there
should be no need to store the users password as mentioned here [2] right?

2. What value does adding the client password to a basic auth encoded header
with duplicated client_id info add? [3]

3. Is the mentioned error returned to the client on token expiration
supposed to result in a 401 status? Is invalid_token_error the error
identifier? I don't see that in any of the error name registries.

4. "Request and response parameters MUST NOT repeat more than once, unless
noted otherwise."[5] Why let them be repeated at all? That requires the
server to do extra work ensuring that anything repeated contains the
consistent and identical values.

5. Utf8 denotation. [6] I noticed that the owner creds flow specifies utf8
encoding. Is there an implicit assumption that all other parameters in the
protocol are also utf8 encoded or were they special cased because they
are foreign data flowed into the protocol not created by the server?

6. Native modified usage of the auth code flow - "Native applications SHOULD
use the authorization code grant type flow without client password
credentials (due to their inability to keep the credentials confidential) to
obtain short-lived access tokens, and use refresh tokens to maintain access"
[7]

The issue was brought up earlier that clients the implicit flow should not
be issued a refresh token because there'd be no way for the server to
identify the client without the client secret. Here its suggested they do
just that. Does this mean there may be a step added in the implicit flow in
the future that will enable the client to refresh their access token without
involving the user if the user has already chosen to authorize the app?

Those are some of the things that jump out at me. I'll read if a few more
times so see if anything else comes up.

I'm happy to see this is all coming together! This is great work.

[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.3
[2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12
[3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1
[4]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-1.5
[5]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.2
[6]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.2
[7]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9

-Doug Tangren
http://lessis.me

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 May 2011 17:41:49 +0200

Hi Doug,

Am 19.05.2011 04:09, schrieb Doug Tangren:
> 1. On storing user password for the resource owner creds flow. If the 
> client stores a access token along with the refresh token [1] to 
> refresh it, there should be no need to store the users password as 
> mentioned here [2] right?

Yes. That's what meant with "It reduces the overall risk of storing 
username and password in the client".

>
> 2. What value does adding the client password to a basic auth encoded 
> header with duplicated client_id info add? [3]

The goal is a cleaner protocol design. The protocol design separates 
client identification as part of the flow (URI parameter) and originator 
authentication. While the client_id parameter is required, the 
authentication can be omitted (unauthenticated access) or performed 
using other authentication mechanisms. And such mechanisms not 
neccessarily use client_id's. Moreover, the spec just says, "The 
authorization server MUST ensure the two identifiers belong to the same 
client". So the client_id's (request parameter and header) may differ.

<someone else should answer questions 3-5, pls.>

>
> 6. Native modified usage of the auth code flow - "Native
> applications SHOULD use the authorization code grant type
> flow without client password credentials (due to their
> inability to keep the credentials confidential) to obtain short-lived
> access tokens, and
> use refresh tokens to maintain access" [7]
>
> The issue was brought up earlier that clients the implicit flow should 
> not be issued a refresh token because there'd be no way for the server 
> to identify the client without the client secret. Here its suggested 
> they do just that. Does this mean there may be a step added in the 
> implicit flow in the future that will enable the client to refresh 
> their access token without involving the user if the user has already 
> chosen to authorize the app?

The text recommends to use the authorization code grant type not the 
implicit grant.

regards,
Torsten.
>
> Those are some of the things that jump out at me. I'll read if a few 
> more times so see if anything else comes up.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth