+1 Best regards,
Huilan LU CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Richer, Justin P. > Sent: Monday, March 07, 2011 8:54 AM > To: Torsten Lodderstedt; Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: > Re: Draft -12 feedback deadline) > > Agree with Torsten - having the mention in just that one > place doesn't make sense. It should be removed or replicated > throughout, but I think we might want a paragraph addressing > native apps more deeply in the introduction. We don't want to > give the (incorrect) impression that the implicit flow is the > only or even preferred flow for native apps. > > -- Justin > ________________________________________ > From: [email protected] [[email protected]] On > Behalf Of Torsten Lodderstedt [[email protected]] > Sent: Monday, March 07, 2011 5:00 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: > Re: Draft -12 feedback deadline) > > Hi Dick, > > I agree with you, the OAuth standard should offer clear > patterns for native apps. > > All native apps I'm familiar with use the authorization code, > which is because of its support for refresh tokens. But the > current text of the spec only suggests to use the implict > grant flow to implement native apps whereas previous versions > mentioned authz code and password flow as well. So in my > opinion, the text is misleading to developers. And that's not > only a feeling since I already meet people, which have been > misguided :-(. > > I think at least the misleading words shall be removed. > Better would be to come up with a consensus after a > discussion in the group. > > regards, > Torsten. > > Am 06.03.2011 23:12, schrieb Dick Hardt: > > -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 > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
