You text does not mention what will be a common use case, where the native app
uses the password grant to fetch a refresh and access token. Whether or not an
app can keep a secret, it's better to have it store the token than the
username/password pair.
From:
9. Native Applications
A native application is a client which is installed and executes on the
end-user's device (i.e. desktop application, native mobile application, etc.).
Native applications may require special consideration related to security,
platform capabilities, and overall end-user e
Yep. Invalid grant is the right error code.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Campbell
> Sent: Tuesday, June 28, 2011 9:05 AM
> To: George Fletcher
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Resource Owner Pass
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
invalid_grant seems like the appropriate error as the username and
password are the grant in the context of the Resource Owner Password
Credentials flow/grant type.
On Tue, Jun 28, 2011 at 9:47 AM, George Fletcher wrote:
>
> I'm working on spec'ing out a use of the Resource Owner Password Credent
I'm working on spec'ing out a use of the Resource Owner Password
Credentials flow and in trying to map out possible error cases, realized
that there is no good error for the case that the resource owner's
password credentials are invalid. Section 4.3 of draft 16 references
section 5.2 for error
+1 for (1)
As pointed out in another posting
(http://www.ietf.org/mail-archive/web/oauth/current/msg06723.html), I think we
have consensus on the patterns for native app implementation. So in my opinion,
we need to adjust the client authentication part to fit.
In my opinion, the authz server c
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 refr
>> Keep in mind that the first priority is still the OAuth 2.0 main spec,
>> so let's wrap that up. We're aiming for working-group last call on
>> that within the month.
>
> Does "within the month" mean "by the end of June"? :)
Yes; we're very aggressive, here in OAuth land.
On the other hand, m
