[OAUTH-WG] multi-level delegation (was: Re: why are we signing?; OAuth 2.0 / Charter)

[Peter Saint-Andre <[e-mail]>]

<hat type='chair'/>

On 12/2/09 9:15 AM, Zeltsan, Zachary (Zachary) wrote:
> On Tue, Dec 1, 2009 at 1:23 PM, 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.
> 
> 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")

Without getting into the whole issue of re-chartering (yet), I do think
it would be helpful to have more discussion about the draft you mention
(because we know that multi-level delegation, formerly known as
"four-legged auth", is something that people are interested in). Feel
free to start a separate thread about that, or reply to this message.

Peter

--
Peter Saint-Andre
https://stpeter.im/