Re: [OAUTH-WG] Facebook, OAuth, and WRAP

[Brent Goldman <[e-mail]>]

On Nov 24, 2009, at 10:40 PM, Mike Malone wrote:

> On Tue, Nov 24, 2009 at 10:15 PM, John Panzer <[e-mail]>  
> wrote:
>> On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone <[e-mail]>  
>> wrote:
>>>
>>> On Tue, Nov 24, 2009 at 10:57 AM, David Recordon
>>> <[e-mail]> wrote:
>>>>
>>>> The largest issue in Facebook moving to OAuth 1.0 (and yes,  
>>>> Eran's new
>>>> RFC is awesome) is the increase in the number of HTTP requests that
>>>> developers will need to make in comparison to our current  
>>>> authentication
>>>> mechanism.
>>>
>>> The OAuth _flow_ (in a browser) requires a couple additional  
>>> requests
>>> compared to Facebook Connect (in a browser). But Facebook Connect is
>>> really a different beast since it relies on the Browser and  
>>> Javascript
>>> to magically set cookies cross domain and whatnot. I agree that it's
>>> non-trivial to extend OAuth to cover this use case (we've sort of  
>>> done
>>> it at Six Apart and the flow is clunky and complicated). And even if
>>> you figure out how to make the flow work you can't really make
>>> requests purely on the client side without compromising your  
>>> consumer
>>> secret.
>>>
>>> That said, as far as I can tell, using OAuth for delegated
>>> communication via an intermediary (a web app or iPhone app, for
>>> example) should be doable for Facebook. The only real differences I
>>> see between OAuth and WRAP for this use case are:
>>>  * WRAP requires SSL instead of signing URLs
>>
>> Aside: If an SP specified OAuth PLAINTEXT signature mode, and used  
>> https:
>> URLs for its API, would there be any effective difference between  
>> OAuth and
>> WRAP for that SP?  (Best as I can tell the only difference would be a
>> mandated %26 character in the OAuth blob you pass in to get access,  
>> but I
>> may be missing something.)
>
> Yea, they're more or less the same. That's one use case for PLAINTEXT
> OAuth. You still have a "signature" though, it's just the base64'd
> signature base string.

If they're more or less the same (besides the difference you  
mentioned), then why not also create an SSL signature mode which  
leaves out the oauth_signature param? If SSL mode is this essentially  
the same as WRAP, why not actually make this the bridge between the  
two specs?