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

[Mike Malone <[e-mail]>]

On Tue, Dec 1, 2009 at 8:52 AM, John Panzer <[e-mail]> wrote:
> On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone <[e-mail]> wrote:
>>
>> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt <[e-mail]>
>> 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