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 <e...@hueniverse.com> 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:mscurte...@google.com] >> 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 >> <e...@hueniverse.com> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
