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
