Re: [OAUTH-WG] Draft 16 comment

I know I have harped on that too many times previously, but just for the 
purpose of counting "votes,"  I think that option 2) is NOT an option. 
(Vote: -2 for 2)

That leaves option 1) as a must as far as I am concerned.

Igor

On 6/28/2011 6:26 AM, Mark Mcgloin wrote:
> The question below remains unanswered in relation to native apps being able
> to use grant type auth code to utilize refresh tokens. Which of these is
> the best option
>
> 1) Change oauth spec so client credentials are optional when requesting
> access token for grant type 'authorization_code' and for refresh token
> requests
> 2) Edit section 9 on security considerations to remove any references to
> native apps using auth code
>
> The difficulty with option 1 is how do you then prevent attackers using a
> legitimate client identifier. If we change the spec to say the client
> SHOULD pre-register it's redirect-uri, would that suffice?
>
>
> Regards
> Mark
>
> oauth-bounces@ietf.org wrote on 23/05/2011 05:40:22:
>
>> From:
>>
>> Shane B Weeden<sweeden@au1.ibm.com>
>>
>> To:
>>
>> oauth@ietf.org
>>
>> Date:
>>
>> 23/05/2011 06:26
>>
>> Subject:
>>
>> [OAUTH-WG] Draft 16 comment
>>
>> Sent by:
>>
>> oauth-bounces@ietf.org
>>
>>
>> First, I'd like to add my support for Brian Eaton's comments on Draft 16.
>> They actually helped clarify the comment I have below....
>>
>>
>> I found section 9 to be in contradiction to a part of section 6. In
>> particular in section 9:
>>
>>   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.
>>
>> In section 6 the specification is quite clear that client authentication
> is
>> REQUIRED for the use of refresh tokens:
>>
>>     The authorization server MUST validate the client credentials, ensure
>>     that the refresh token was issued to the authenticated client,
>>     validate the refresh token, and verify that the resource owner's
>>     authorization is still valid.
>>
>>
>> My  understanding is that refresh tokens are being used as a kind of
>> long-lived, rolling "instance secret" for the native application and
>> represent the grant authorized by the end user during initial
> establishment
>> of the authorization code which is used to get the first refresh token.
>>
>> It seems to me this use case needs to be allowed for in the wording of
>> section 6.
>>
>> Regards,
>> Shane.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth