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

[Mike Malone <[e-mail]>]

On Tue, Dec 1, 2009 at 10:34 AM, John Panzer <[e-mail]> wrote:
> On Tue, Dec 1, 2009 at 10:22 AM, Mike Malone <[e-mail]> wrote:
>>
>> 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.
>
> That's the reverse (proxy authorization) -- the client is relying on the
> proxy to do the signing, and the proxy has to figure out based on other
> stuff (browser cookies, magic incantations) whether _its_ client is
> authorized.  This is the OAuth Proxy model.

Yea sort of. It's proxying the signing, but it's not proxying the
actual request.

> I thought you were talking about being able to get user consent for service
> X to do something, but then service X sub-contracts out some of the work to
> service Y, perhaps run by a separate organization.  Y can call-back to X to
> do its work, neatly defeating some of the purpose of sub-contracting work
> out as everything flows through X anyway.  Or X could hand a signed URL to
> Y, but then Y can only deal with what was actually signed, and can't vary
> the parameters, again defeating much of the purpose of subcontracting.
>  Also, isn't there a nonce in there?  So Y can only make one call with that
> URL before returning to the well.

All true. The use case where this becomes incredibly useful (despite
the limitations you mentioned) is for allowing file uploads from the
browser without the Consumer proxying everything. Since OAuth doesn't
sign a multipart/form-data body you can vary that without a problem.
And since the file upload typically takes some time, asking the
Consumer for a signed URL for each request isn't much of a burden.

> It'd be much better to (in an extension!) be able to say "Give me a token
> just like the one I have, but read-only, and only valid for 3 minutes, and
> I'm going to let another service use it" and get a restricted token to hand
> off to a sub-contractor[1].

Yes. I want that.

> In any case, I don't see how signing the URL helps with doing something
> along these lines, and I think if it does anything at all it hurts (because
> of inclusion of things like nonces and timestamps).  Yeah, there are some
> basic use cases for it, like getting access to a read-only feed (capability
> URLs) but those can be accomplished quite as well and more simply with
> bearer tokens IMHO.

Yea, an extension would be nice. I guess what I'm saying is that
whatever we do moving forward should at least keep the basic level of
delegation we have, however naive and broken it is, because it's
useful.

> John
> [1] I am going on strike and refusing to go beyond "third party" as there
> are actually an infinite number of parties and use cases here and I can't
> keep them straight any more.

Thank god.

Mike