On Sun, May 9, 2010 at 7:34 PM, Dick Hardt <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
