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 <[email protected]> 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 <[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
