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
