Lifespan of this delegation token could be: - One time usage of token - Time or numbers of usage given to the AS when the delegation has been asked.
If the access of the client is revoked, all the delegate tokens should be also revoked. I have implemented a couple of scenarios for recursive delegation. If you use a minimal library for OAuth1 that handles only the signatures and the building of the requests, nothing has to be changed to the original library. You must only depending on your implementation have 2 or 3 extra endpoints to handle the flow, or incorporate it with some extra parameters or logic in the original endpoints. For clarity, I used extra endpoints. -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: dinsdag 11 mei 2010 1:20 To: Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] delegating access to another client On Sun, May 9, 2010 at 7:34 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > There a couple of choices for the flows for how a successful delegation is > conveyed to the delegate. The AS could return a delegation code that is > similar to a verification code and the delegate acquires an access token > similar to 3.6.2 > Alternatively, the AS could return an delegation token that is used similar > to a refresh token to obtain an access token and refresh token. How about lifespan? When does the token expire? And can the client request a shorter expiration? Can the client request revocation of the delegate's token? What are the semantics around revocation? If a client has their access revoked, is the delegate access revoked as well? > Do people think this is worth adding to the spec? Maybe. > The main concern is how should the resource owner express their approval for > such arrangement? I don't think this is a fundamental problem. The client already has the authority they are delegating, and they could expose a proxy service to share that data with fourth-parties. Dick is describing a cleaner (and possibly more secure?) way to do that. It's up to clients and service providers to figure out user expectations and set appropriate policies on when data can be shared with fourth parties.. Cheers, Brian _______________________________________________ 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
