Thanks for the response Eran, that helps clarify things. I'm hoping to have some in-person discussions with some Googlers tomorrow to hopefully sort out the technical details of these flows. Will report back to the list with any findings.
-----Original Message----- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, April 15, 2010 10:47 AM To: Luke Shepard; OAuth WG Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks On 4/14/10 10:32 AM, "Luke Shepard" <lshep...@facebook.com> wrote: > Sorry, I missed this thread. It dovetails with my objections raised in the > other thread (³Combining the native application and user-agent flows²) > > The question of whether OAuth should support custom URL protocols seems a bit > academic. In practice, major providers will probably allow them if there is > demand from developers. The goal of this group is to establish a pragmatic, > widely adopted authentication protocol not to wage a IETF campaign against > browser vendors to force compliance to standards. It's not a question of an "IETF campaign" but of what an IETF specification can say about it. WRAP explicitly mentions custom URI schemes which is something we cannot do in an IETF spec because clearly violates IETF standards. The questions are "do we want to mention custom URI schemes? Do we think it is a useful pattern?" and I suspect the answer is yes given how widely this technique is used on the iPhone and other platforms. So then the question is how to do this within the context of an IETF specification or leave it for people to figure out on their own (or in books and articles). Creating a scheme for this isn't hard and is one simple way to accomplish the same thing. It also allows us to mention how it is done today and encourage people to seek the other way when possible. This is how we make progress in standards (document the bad practice and offer better solutions). > Additionally, in my email I laid out a few ways for an entirely client app to > handle a callback without using custom protocols. For instance: > - Use a scheme like ³about:blank² (does that count as a custom scheme > or is it supported by the IETF?) There is a proposed RFC for 'about:' but it seems stuck due to lack of authors time. > - Host a static callback themselves. For many apps it¹s much easier to > host a single, static callback than a dynamic server endpoint. I assume you mean host a fixed document on a server. > - Use a callback hosted by the provider (i.e., > http://facebook.com/universal_callback Sure, as long as it doesn't end up as an open redirector with the known security issues. > In practice, this is how desktop and mobile clients work to access Facebook > today. The Native Application flow is basically like the third option above > (callback hosted by provider), but without the flexibility of the first two. > We should just get rid of that flow and use the ³User-agent² flow. (I would > prefer something like ³Client-side App flow² but I understand that the naming > here is pretty difficult) If we end up with one flow, I am sure I can come up with another name. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
