Brian: I agree with your comments if native apps are not going to be supported in OAuth v2.
my -1 is towards dropping native app support, and your suggestion was the easiest thread to comment on. On 2011-03-07, at 7:15 AM, Brian Campbell wrote: > I don't disagree with any of that, Dick. But in the absence of any > specific solution or recommendation from the WG regarding native apps, > I am simply asking that the somewhat misleading text be removed from > the framework spec. > > On Sun, Mar 6, 2011 at 3:12 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >> -1 >> >> Many sites are using OAuth (or something like it) in native apps now. >> >> One of the objectives of having a standard is to bring best practices and >> standardization to how to solve a problem rather than "a million freakin >> unique snowflakes" where developers have to learn and code each mechanism to >> enable authorization to a native app. Brian's suggested wording may make >> sense in the context of where OAuth is now -- but it signals that the WG has >> been unable to solve what I think many viewed as an important aspect of the >> WG. >> >> fwiw: I think a number of important constituents have opted out of the >> dialogue. An unfortunate situation. >> >> On 2011-03-02, at 6:05 AM, Brian Campbell wrote: >> >>> 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 >> >> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
