Tony said a new text is coming. Once that is posted, I'll ask the list for a hum.
EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, June 16, 2011 2:00 AM To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org Subject: AW: Updated text for Native Apps In my perception, the main concern raised at the F2F was the absent of the implicit grant in the text. That's what Chuck added including a discussion of the pros and cons. Most of the discussion in the thread you referred to was about refresh tokens support in the implicit grant type, which was caused by an additional question by Chuck. This would be a fundamental change to the protocol and we had a lively discussion about this idea. In the end, I have not seen a proposal to add this feature to the spec. This discussion is independent of the native apps text Chuck proposed (http://www.ietf.org/mail-archive/web/oauth/current/msg06444.html) and I have not seen any objection on this text. I therefore consider this a consensous. So please consider the proposed text for the next revision of the draft. regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Mittwoch, 15. Juni 2011 19:35 An: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org Betreff: Re: [OAUTH-WG] Updated text for Native Apps That's an odd way of looking at it. I'm looking at over 30 responses to the text with clear disagreement on how native applications should be deployed using different grant types. To say that there is consensus to the text, but not to the other comments objecting to it is ignoring the lack of consensus... If you think you can propose a new text that will be endorsed by the group, please go ahead. But the F2F action item carries no weight if the list doesn't like what is suggested. What is clear from the discussion is that we have some unresolved issues around refresh tokens and client authentication which are at the heart of advising about native applications. It would be impossible to make recommendations without resolving these issues first (and once we do, I would argue no additional text would be needed). EHL From: Anthony Nadalin [mailto:tony...@microsoft.com] Sent: Wednesday, June 15, 2011 10:24 AM To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org Subject: RE: Updated text for Native Apps Not seeing what you write about below, I think that the basic text that was discussed at the F2F has consensus around the guidance (with some changes that were discussed and Chuck provided), I think that some of the other thoughts people have thrown out don't. I disagree with dropping the text as there is not consensus to do that, since there was an action item to put text back in. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, June 15, 2011 10:19 AM To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org Subject: RE: Updated text for Native Apps This working group has failed, for well over a year, to reach any sort of consensus regarding which grant types are suitable for a given client type. There was no draft between 00 and 16 in which we had agreement on the definition of client types, or the exclusivity of any flow to any given type. Trying to reach such a conclusion is a waste of time. The main reason for this is lack of deployment experience. We have pretty good experience with some cases like a server-based client capable of keeping secrets, and browser-based clients executing fully visible source code. We clearly do not even have a clear definition of what is a native application and the recent attempt to define a native application client type seems to cause more confusion than help. While there is clearly an expectation that the specification will offer guidance to native application developers, I have yet to see any such text gaining consensus. My suggestion is to drop this attempt, but if a new text gain consensus, I'll incorporate it. EHL From: Anthony Nadalin [mailto:tony...@microsoft.com]<mailto:[mailto:tony...@microsoft.com]> Sent: Wednesday, June 15, 2011 10:10 AM To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org<mailto:oauth@ietf.org> Subject: RE: Updated text for Native Apps Since Torsten and I had the action item to propose text we will update the text based upon the list and give you back an update From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On Behalf Of Eran Hammer-Lahav Sent: Wednesday, June 15, 2011 9:33 AM To: Chuck Mortimore; oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Updated text for Native Apps Is there an updated text based on the long thread? EHL From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On Behalf Of Chuck Mortimore Sent: Tuesday, May 31, 2011 10:37 AM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] Updated text for Native Apps Minor updates for section 9 based upon feedback from the list -cmort ---------------- 9. Native Applications A native application is a client which is installed and executes on the end-user's device (i.e. desktop application, native mobile application). Native applications require special consideration related to security, platform capabilities, and overall end-user experience. The following are examples of how native applications may utilize OAuth: o Initiate an Authorization Request using an external user-agent: The native application can capture the response from the authorization server using a variety of techniques such as the use of a redirection URI identifying a custom URI scheme (registered with the operating system to invoke the native application as handler), manual copy-and-paste, running a local webserver, browser plug-ins, or by providing a redirection URI identifying a server-hosted resource under the native application's control, which in turn makes the response available to the native application. o Initiate an Authorization Request using an embedded user-agent: The native application obtains the response by directly communicating with the embedded user-agent. Techniques include monitoring state changes emitted during URL loading, monitoring http headers, accessing the user-agent's cookie jar, etc. When choosing between launching an external user-agent and an embedding a user-agent, native application developers should consider the following: o External user-agents may improve completion rate as the end-user may already have an active session with the authorization server removing the need to re-authenticate, and provide a familiar user-agent user experience. The end-user may also rely on extensions or add-ons to assist with authentication (e.g. password managers or 2-factor device reader). o Embedded user-agents may offer an improved end-user flow, as they remove the need to switch context and open new windows. o Embedded user-agents pose a security challenge because end-users are authenticating in an unidentified window without access to the visual protections offered by many user-agents. Embedded user-agents educate end-user to trust unidentified requests for authentication (making phishing attacks easier to execute). When choosing between implicit and authorization code grant types, the following should be considered: o Native applications that use the authorization code grant type flow SHOULD do so without client password credentials, due to their inability to keep those credentials confidential. o Native applications that use the implicit grant type may offer optimized performance in some scenarios due to reduced network requests o The implicit grant type does not return a refresh token
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
