Re: [OAUTH-WG] Delegation -- RE: SAML profile comments/questions from the SAML people

So, maybe you and Thomas can generalize that use case to rely on either 
mechanism?

Igor

Zeltsan, Zachary (Zachary) wrote:
> Igor,
>
> The intention of the draft draft-vrancken-oauth-redelegation was to specify a mechanism for doing exactly what Thomas has described:
>   
>> ... User#1/Client#1 asks for 
>> an access token (to a given resource) with the
>> intention of later handing over the access-token to 
>> a different User#2/Client#2
>>     
> The mechanism is design to support also the situation where
>   
>> User#2/Client#2 asks the Auth Server to "swap" (re-issue)
>> this token for a different client_id (User#3/Client#3)
>>     
>
> The difference is that the mechanism of the draft-vrancken-oauth-redelegation relies on the "temporary credentials" and "token credentials", which were used in OAuth 1.0, and not on the access tokens.
>
> Zachary
> -----Original Message-----
> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] 
> Sent: Tuesday, September 07, 2010 4:36 PM
> To: Thomas Hardjono; Zeltsan, Zachary (Zachary)
> Cc: Brian Campbell; oauth
> Subject: Re: [OAUTH-WG] Delegation -- RE: SAML profile comments/questions from the SAML people
>
> Thomas,
>
> It looks to me like the intention in this use case is similar to that of 
> the "multilegged OAuth" (later renamed to the politically-correct 
> "recursive delegation"). This use case has been published in Bart's and 
> Zachary's draft. which has expired now. This case has moved into the 
> overall use case compilation document.
>
> Zachary, maybe you could shed some light here?
>
> Igor
>
> Thomas Hardjono wrote:
>   
>> __________________________________________
>>
>>   
>>     
>>> -...
>>>       
>> What I meant to say is that User#1/Client#1 asks for 
>> an access token (to a given resource) with the
>> intention of later handing over the access-token to 
>> a different User#2/Client#2.
>>
>> Ideally, this model could be extensible where
>> User#2/Client#2 asks the Auth Server to "swap" (re-issue)
>> this token for a different client_id (User#3/Client#3).
>>
>> However, this bring us into space of role based access
>> control and permissions, which would somewhat complicate
>> the Oauth 2.0 authorization model :)
>>
>> /thomas/
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>   
>>     