although we are the ones who are pushing this into our ecosystem right now, i agree with david on this one -- i'm happy to take the lead in drafting this (i have some sketches of it working in the oauth 1.0a world for a one time use -- http://mehack.com/oauth-echo-delegation-in-identity-verificatio), but i think this should be an extension.
On Tue, May 11, 2010 at 2:31 AM, David Recordon <record...@gmail.com> wrote: > 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 <e...@hueniverse.com> > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > >> Of Dick Hardt > >> Sent: Sunday, May 09, 2010 7:34 PM > >> To: OAuth WG (oauth@ietf.org) > >> 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 > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > 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 > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
