+1

Am 02.03.2011 15:05, schrieb Brian Campbell:
I propose that the "or native applications" text be dropped from the
first paragraph in section 4.2 Implicit Grant  [1].

There is clearly some disagreement about what is most appropriate for
mobile/native applications and many, including myself, don't feel that
the implicit grant works well to support them (due to the lack of a
refresh token and need to repeat the authorization steps).  I
understand that the text in section 4 is non-normative, however, I
feel that the mention of native apps in 4.2 biases thinking in a
particular way (it's already led to one lengthy internal discussion
that I'd rather not have again and again).  I believe it'd be more
appropriate for the draft to remain silent on how native apps should
acquire tokens and leave it up to implementations/deployments to
decide (or an extension draft as Marius has proposed).

The "or native applications" text in is also somewhat inconsistent
with the text in the following sentence that talks about the
authentication of the client being based on the user-agent's
same-origin policy.

Removing those three words is a small change but one that I feel would
be beneficial on a number of fronts.

Thanks,
Brian


[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2

On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav<[email protected]>  wrote:
Feel free to propose alternative preamble for the implicit and authorization 
code sections, describing the characteristics of what they are good for. It 
should fit in a single paragraph. Such a proposal would fit right in with last 
call feedback to -13.

EHL

-----Original Message-----
From: Marius Scurtescu [mailto:[email protected]]
Sent: Wednesday, February 16, 2011 1:39 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline

On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav
<[email protected]>  wrote:
The reason why we don't return a refresh token in the implicit grant is
exactly because there is no client authentication...

Not sure that's the main reason. AFAIK it is because the response is sent
through the user-agent and it could leak.


These are all well-balanced flows with specific security properties. If you
need something else, even if it is just a tweak, it must be considered a
different flow. That doesn't mean you need to register a new grant type, just
that you are dealing with different implementation details unique to your
server.

The Authorization Code flow, with no client secret, is perfectly fine for Native
Apps IMO.

Marius
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to