Subject: [OAUTH-WG] delegating access to another client

From: Dick Hardt <[email-masked]>
Date: Sun, 9 May 2010 19:34:09 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 22:20:16 -0700

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-masked] [mailto:[email-masked]] On Behalf
> Of Dick Hardt
> Sent: Sunday, May 09, 2010 7:34 PM
> To: OAuth WG ([email-masked])
> 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
> 	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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Vrancken, Bart bv (Bart)" <[email-masked]>
Date: Mon, 10 May 2010 10:27:34 +0200

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-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: maandag 10 mei 2010 7:20
To: Dick Hardt; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] delegating access to another client

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 May 2010 16:20:26 -0700

> 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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 10 May 2010 17:10:13 -0700

> request a shorter expiration?

I would expect these to be contained in the scope requested.

> access revoked, is the delegate access revoked as well?

Had not considered revocation by the client. I have no answer to these questions right now. :)

-- Dick

---

From: David Recordon <[email-masked]>
Date: Mon, 10 May 2010 18:31:46 -0700

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

---

From: "Vrancken, Bart bv (Bart)" <[email-masked]>
Date: Tue, 11 May 2010 10:20:26 +0200

Lifespan of this delegation token could be:
 - One time usage of token
 - Time or numbers of usage given to the AS when the delegation has been asked.

If the access of the client is revoked, all the delegate tokens should be also revoked.

I have implemented a couple of scenarios for recursive delegation. If you use a minimal library for OAuth1 that handles only the signatures and the building of the requests, nothing has to be changed to the original library. You must only depending on your implementation have 2 or 3 extra endpoints to handle the flow, or incorporate it with some extra parameters or logic in the original endpoints. For clarity, I used extra endpoints.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: dinsdag 11 mei 2010 1:20
To: Dick Hardt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] delegating access to another client

Maybe.

Cheers,
Brian

---

From: Raffi Krikorian <[email-masked]>
Date: Tue, 11 May 2010 09:38:40 +0100

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 <[email-masked]> 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).
> >

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi