Subject: Re: [OAUTH-WG] review: draft-richer-oauth-chain-00.txt

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 05 Dec 2012 16:09:33 +0000

Hi
On 30/11/12 16:36, Phil Hunt wrote:
> Two things.
>
> 1. I think access_token would be a bit confusing in some contexts even though thats what it is. However it is likely a foreign access token. "chain" is also shorter.
>
> 2. Regarding refresh, any idea on the use case? My impression is that if anything lifetime should be shorter than the current access token. All cases i have been looking at tend to be closer to single use -->  which has led o feedback that a single leg solution would be better for same domain cases.
>
If 2. refers to my comment re adding another optional parameter to the 
refresh grant: I thought, that the case of the immediate client issuing 
a down-scoping request with the help of the refresh grant is very 
similar to the RS issuing its own down-scoping request, with the only 
difference being that the proposed redelegate grant additionally 
introduces an access_token parameter.

My comment was only about the possibility of using the common processing 
path for both cases: if the scope is there it is a down-scoping request 
and if the access token parameter is there too then it must be a 
redelegate one.

However may be it is bad idea :-) to overload refresh grant further and 
having another dedicated grant type will work better longer term if some 
more parameters can be possibly added

thanks. Sergey

> Phil
>
> Sent from my phone.
>
> On 2012-11-30, at 2:31, Sergey Beryozkin<[email-masked]>  wrote:
>
>> On 30/11/12 10:25, Ebling, Sebastian wrote:
>>> Hi Phil,
>>>
>>> Some comments on draft-richer-oauth-chain-00.txt:
>>>
>>> Section 3.1.
>>> - I dislike the name of the grant type. "redelegate" is the use case but not the grant presented to the AS from RS1. I suggest to use "access_token" according to other grant types like authorization_code, password, refresh_token.
>> Interesting. What about adding one more optional parameter to "refresh_grant" ?
>>
>> thanks, Sergey
>>
>>> Section 3.2
>>> "As this access token is bound to an existing access token, the authorization server MUST NOT issue a refresh token."
>>>  From our operating experience [1] it may be useful to issue a refresh token in some cases.
>>>
>>> Example:
>>> RS1 may be a batch processing system that must be able to access RS2 some hours later to fulfill the originary request from the Client. The access tokens (AS to C and AS to RS1) may have expired when the job starts from the queue. Issuing a refresh token enables RS1 to obtain a fresh access token (AS to RS1).
>>> AS may limit the duration of the refresh token for such clients (RS1).
>>>
>>> Regards
>>>
>>> Sebastian
>>>
>>> [1] I'm a colleague of Torsten Lodderstedt at Deutsche Telekom, responsible for the system life cycle of our Secure Token Service. We have already implemented a very similar custom grant type for service chaining at Deutsche Telekom.
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth