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<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
