Re: [OAUTH-WG] why are we signing?

In addition to the use case Mike gave, I have seen at least two other 
use cases of having the "proxy" sign the URL and then present over HTTP.
1. an iGoogle gadget that wants to launch an iframe with a URL that 
carries specific identity & authorized rights
2. a rich/desktop application want to launch a browser in an 
authenticated/authorized state (i.e. client-to-browser SSO)

I also haven't seen anyone bring up the "restricted device" use case 
yet:) I do work with a product team that refuses to use SSL because of 
the memory, load time, and CPU requirements. Curious if any in the 
mobile device environment see the requirement of SSL an issue? 
Potentially not given most devices these days have a browser.

Thanks,
George

Mike Malone wrote:
> On Tue, Dec 1, 2009 at 8:52 AM, John Panzer <jpanzer@google.com> wrote:
>   
>> On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone <mjmalone@gmail.com> wrote:
>>     
>>> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt <Dick.Hardt@microsoft.com>
>>> wrote:
>>>       
>>>> On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote:
>>>>         
>>>>> I for one, see great value in offering some form of crypto-based
>>>>> security for cases where TLS is not suitable.
>>>>>           
>>>> Are these use cases enumerated somewhere?
>>>>         
>>> I'm not completely opposed to the TLS route, but since you asked...
>>> off the top of my head, here are a couple drawbacks to using TLS
>>> instead of signing:
>>>  - Bigger burden on developers who need to debug this stuff (i.e.,
>>> you can't sniff your own traffic to debug requests & responses).
>>>  - Properly setting up TLS can be complicated and expensive. For
>>> developers who don't have a lot of ops skills the barrier may be too
>>> high.
>>>  - You can no longer pass around signed URLs as another level of
>>> delegation (a use case that I use regularly for making XHR & POST
>>> requests from the browser). This could be a non-issue if some other
>>> mechanism for fourth-party delegation existed.
>>>
>>>       
>> Can you elaborate on the above?  For OAuth, signatures (bound to a
>> particular Consumer Secret that can't be leaked to subcontractors) is a
>> barrier to multi-level delegation.
>>     
>
> Right, but you can do poor-man's delegation by signing a URL and
> passing it off to a third (er, fourth) party to use. I've seen this
> most often with web apps, where the app (the OAuth Consumer) wants to
> make a request to the Provider directly from the browser (e.g.,
> POSTing a large file). They can't sign the URL in javascript without
> compromising the Consumer Secret, so the the URL is signed server side
> and passed to the browser for use.
>
> Mike
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>   