Subject: Re: [OAUTH-WG] Draft 16 comment

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Jul 2011 10:30:31 -0700

Section 3:

   In addition, the authorization server MAY allow unauthenticated
   access token requests when the client identity does not matter (e.g.
   anonymous client) or when the client identity is established via
   other means.  For readability purposes only, this specification is
   written under the assumption that the authorization server requires
   some form of client authentication.  However, such language does not
   affect the authorization server's discretion in allowing

   unauthenticated client requests.

From: Shane Weeden <[email-masked]<mailto:[email-masked]>>
Date: Sun, 22 May 2011 21:40:22 -0700
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Draft 16 comment

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth