Re: [OAUTH-WG] Native applications capable of handling callbacks

[Luke Shepard <[e-mail]>]

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-mail]] 
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" <[e-mail]> 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