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. Phil Sent from my phone. On 2012-11-30, at 2:31, Sergey Beryozkin <sberyoz...@gmail.com> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
