You can find the idea of re-delegation on http://tools.ietf.org/id/draft-vrancken-oauth-redelegation-01.txt
About the main concern that Eran is indicating, my view is that at the time the user is authorizing the request giving authority to the client to act on behalf of the user, the approval is clearly documented on the web server. This could be done by giving the following options to the user: - The client may act on behalf of the user for every other possible client - The user could select the clients that may get authorization by that client. This could be similar to indicate some kind of scope in standard OAuth. Best regards, Bart -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eran Hammer-Lahav Sent: maandag 10 mei 2010 7:20 To: Dick Hardt; OAuth WG ([email protected]) Subject: Re: [OAUTH-WG] delegating access to another client Re-delegation is something people asked for since we started talking about OAuth. There is also a draft I-D about it. This is explicitly out of scope for the core spec (but not something that should stop us from having a discussion). The main concern is how should the resource owner express their approval for such arrangement? EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Dick Hardt > Sent: Sunday, May 09, 2010 7:34 PM > To: OAuth WG ([email protected]) > Subject: [OAUTH-WG] delegating access to another client > > Twitter has an interesting use case that may become common: one client > needs to delegate access to another client. Similar to the 'modify' method > where the scope of the access token can be modified, the 'delegate' method > allows a client to request delegation to another client (the delegate). Here > is > some proposed copy for the request: > > type > REQUIRED. The parameter value MUST be set to delegate > > client_id > REQUIRED. The client identifier as described in Section 3.4. > > client_secret > REQUIRED if the client was issued a secret. The client secret. > > refresh_token > REQUIRED. The refresh token associated with the client. > > delegate_id > REQUIRED. The client identifier of the delegate > > scope > OPTIONAL. The scope the client is requesting for the delegate. > > secret_type > OPTIONAL. The access token secret type as described by Section 8.3. > If omitted, the authorization server will issue a bearer token (an access > token > without a matching secret) as described by Section 8.2. > > 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. > > Do people think this is worth adding to the spec? It seems to be a simple > addition and allows us to standardize what is emerging as a common > capability. > > -- Dick > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
