I'm concerned about prematurely standardizing something which we don't have deployment experience to guide. One of the things I like most about OAuth 2.0 is that we're largely not inventing new things. Rather learning from what others have done in the past.
My view is that redelegation should first be drafted and deployed as an extension. --David On Sun, May 9, 2010 at 10:20 PM, Eran Hammer-Lahav <[email protected]> wrote: > 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
