Re: [OAUTH-WG] why are we signing?; OAuth 2.0 / Charter

On Tue, Dec 1, 2009 at 1:23 PM, Mike Malone  
<mjmalone@gmail.com> 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.

There is another way to do a multi-level delegation without revealing a client's secret. The method described in the draft
http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00
along with a use case for re-delegating authorization.
In my opinion, the multi-level delegation should be on a new charter. (This makes this message relevant to the thread with the subject "OAuth 2.0 / Charter")

> Mike
> 
Zachary
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 