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
