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. 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 protected] https://www.ietf.org/mailman/listinfo/oauth
