Re: [OAUTH-WG] Draft -16

Hi Doug,

Am 19.05.2011 04:09, schrieb Doug Tangren:
> 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?

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.
>
> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth