Interesting client delegation (delegation 2X) usecase (Twitter)

[Allen Tom]

Here’s an interesting use case where a client wants to delegate its credentials to another client.

Here’s original blog post that describes this scenario:
http://mehack.com/OAuth-echo-delegation-in-identity-verificatio

The use case is that a Twitter Client (Tweetie) wants to upload a photo to TwitPic (a photo sharing website). The Twitter client has the user’s Twitter credentials, and now wants to delegate them to TwitPic. TwitPic needs the user’s credentials because it wants  to know who the user is.

If we were to use OAuth-WRAP for this scenario, Tweetie could just pass a WRAP Access Token to TwitPic. In WRAP, the Access Token is a short lived credential. TwitPic can use the Access Token, and it would eventually expire. TwitPic does not need to know Tweetie’s consumer secret, nor does it need Tweetie’s Refresh Token (the permanent credential).

We could improve the situation by defining an interface for a client to explicitly request a delegated access token before it passes it to delegated client. For example, Tweetie could tell Twitter that it wanted a really short lived credential to give to TwitPic. It might be desirable for the delegated access token to have reduced scopes.

Allen

[Brian Eaton]

On Fri, Feb 12, 2010 at 2:20 PM, Allen Tom <at...@yahoo-inc.com> wrote:
> Here’s original blog post that describes this scenario:
> http://mehack.com/OAuth-echo-delegation-in-identity-verificatio

I read the mehack post. It is a cool use case.

> TwitPic can use the Access Token, and it would eventually
> expire. TwitPic does not need to know Tweetie’s consumer secret, nor does it
> need Tweetie’s Refresh Token (the permanent credential).

This is awesome. =)

> The use case is that a Twitter Client (Tweetie) wants to upload a photo to
> TwitPic (a photo sharing website). The Twitter client has the user’s Twitter
> credentials, and now wants to delegate them to TwitPic. TwitPic needs the
> user’s credentials because it wants  to know who the user is.

This is one where we need to be careful. Here's an example of a good
way to use this:
1) Tweetie passes OAuth access token to twitpic
2) Twitpic uses access token to upload photos

Here's an example of a broken way to use this:
1) Tweetie passes OAuth access token to twitpic.
2) Twitpic uses Twitter access tokens to authenticate the user.
3) Twitpic holds a wide variety of data on the user's behalf (e.g.
contact list, calendar, photos)
4) Every time Twitter hands out a Twitter access token for a user,
they also handed out access all of the user's data hosted at Twitpic.
The Twitter access token also grants access to the user's Twitpic
contact list, calendar, and photos.

It's unclear to me that users clicking "OK" on the Twitter approval
page will realize that they are handing out access to *all* of their
Twitpic data as well.

If Twitpic really wants to use Twitter for authentication, some sort
of an optimized federated login approval process might be a better
choice.

> We could improve the situation by defining an interface for a client to
> explicitly request a delegated access token before it passes it to delegated
> client. For example, Tweetie could tell Twitter that it wanted a really
> short lived credential to give to TwitPic. It might be desirable for the
> delegated access token to have reduced scopes.

Yep.

Cheers,
Brian

[George Fletcher]

On 2/16/10 11:05 AM, Brian Eaton wrote:

On Fri, Feb 12, 2010 at 2:20 PM, Allen Tom <at...@yahoo-inc.com> wrote:
> Here’s original blog post that describes this scenario:
> http://mehack.com/OAuth-echo-delegation-in-identity-verificatio

I read the mehack post.  It is a cool use case.

+1 Figuring out a way to get downstream delegation is an important use case

> TwitPic can use the Access Token, and it would eventually
> expire. TwitPic does not need to know Tweetie’s consumer secret, nor does it
> need Tweetie’s Refresh Token (the permanent credential).

This is awesome. =)

My only problem here is that any interaction between TwitPic and Twitter that uses the AccessToken from Tweetie will look like it's an interaction between Tweetie and Twitter. Is this really what we want?

> The use case is that a Twitter Client (Tweetie) wants to upload a photo to
> TwitPic (a photo sharing website). The Twitter client has the user’s Twitter
> credentials, and now wants to delegate them to TwitPic. TwitPic needs the
> user’s credentials because it wants  to know who the user is.

This is one where we need to be careful.  Here's an example of a good
way to use this:
1) Tweetie passes OAuth access token to twitpic
2) Twitpic uses access token to upload photos

Here's an example of a broken way to use this:
1) Tweetie passes OAuth access token to twitpic.
2) Twitpic uses Twitter access tokens to authenticate the user.
3) Twitpic holds a wide variety of data on the user's behalf (e.g.
contact list, calendar, photos)
4) Every time Twitter hands out a Twitter access token for a user,
they also handed out access all of the user's data hosted at Twitpic.
The Twitter access token also grants access to the user's Twitpic
contact list, calendar, and photos.

It's unclear to me that users clicking "OK" on the Twitter approval
page will realize that they are handing out access to *all* of their
Twitpic data as well.

Doesn't this require TwitPic to honor all AccessTokens issued by Twitter regardless of who they were issued to? Couldn't TwitPic leverage the issuedTo concept and require user consent? Something along the lines of ... "Do you want to allow Tweetie to publish photos into your TwitPic account?" I know this is what I'd prefer. Then I could revoke that consent at some later time.

It probably requires signed SWTs with an issuedTo field to really work though.

Maybe I missed the point:)

If Twitpic really wants to use Twitter for authentication, some sort
of an optimized federated login approval process might be a better
choice.

> We could improve the situation by defining an interface for a client to
> explicitly request a delegated access token before it passes it to delegated
> client. For example, Tweetie could tell Twitter that it wanted a really
> short lived credential to give to TwitPic. It might be desirable for the
> delegated access token to have reduced scopes.

Yep.

There are some ugly issues in the "reduce scope" statement, but there is huge value is solving this problem. As a user, I want to authorized all the systems necessary to carry out a task. So if I want to print an image, I'd like "auto-consent" to be given for that transaction regardless of how many systems are required but not necessarily for future transactions.

Cheers,
Brian

--
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Brian Eaton]

On Tue, Feb 16, 2010 at 9:01 AM, George Fletcher
<george....@corp.aol.com> wrote:
> My only problem here is that any interaction between TwitPic and Twitter
> that uses the AccessToken from Tweetie will look like it's an interaction
> between Tweetie and Twitter. Is this really what we want?

In my humble opinion, yes. Tweetie should be able to use umpteen
systems to fulfill it's goal of posting a picture, and there is no
reason that Twitter needs to involve itself in each and every one of
those systems.

Given that I don't speak for any of the systems in the Tw* ecosystem,
take that with a grain of salt.

> Doesn't this require TwitPic to honor all AccessTokens issued by Twitter
> regardless of who they were issued to? Couldn't TwitPic leverage the
> issuedTo concept and require user consent? Something along the lines of ...
> "Do you want to allow Tweetie to publish photos into your TwitPic account?"
> I know this is what I'd prefer. Then I could revoke that consent at some
> later time.
>
> It probably requires signed SWTs with an issuedTo field to really work
> though.

Interesting angle. That would work.

The nice thing about the mehack proposal is that it basically treats
the access token like the user's twitter password, and as a
consequence has lots of the same benefits and flaws as password
authentication. Deeper inspection of tokens, or full-fledged
federated auth for Twitpic, is significantly more complicated.

Cheers,
Brian

[Allen Tom]

Ah, so now the problem is that Twitpic needs to authenticate Tweetie, since
Twitpic itself might have protected resources that might be OK to share with
Tweetie, but not to any other random Twitter app that happens to have an
Access Token for the user?

I guess the easiest solution would be for Twitter to have an API that
returns the Consumer Key for the access token? Twitpic could call this API
to ensure that it's using a delegated access token from Tweetie, and not
from some other app.

Would that work?
Allen

[Brian Eaton]

On Tue, Feb 16, 2010 at 12:51 PM, Allen Tom <at...@yahoo-inc.com> wrote:
> I guess the easiest solution would be for Twitter to have an API that
> returns the Consumer Key for the access token? Twitpic could call this API
> to ensure that it's using a delegated access token from Tweetie, and not
> from some other app.

I think it would work (though there are fundamental questions about
whether Twitpic wants to deal only with Tweetie, or if they really do
want to accept access tokens for any consumer). I think it's
conceptually the same as George's proposal to use SWT tokens, but with
out any key management required. Instead the tokens require online
validation.

It still doesn't get you much scoping of resources at Twitpic. If
Twitpic wants separate access control on, say, calendar vs photos,
they need another answer.

Cheers,
Brian

[George Fletcher]

On 2/16/10 3:51 PM, Allen Tom wrote:

Ah, so now the problem is that Twitpic needs to authenticate Tweetie, since
Twitpic itself might have protected resources that might be OK to share with
Tweetie, but not to any other random Twitter app that happens to have an
Access Token for the user?

Right, plus it would be nice if the user had some form of consent choice. I can see two options, ask the user up front, or auto-approve and allow the user to revoke later if they care. Both have pros and cons.

I guess the easiest solution would be for Twitter to have an API that
returns the Consumer Key for the access token? Twitpic could call this API
to ensure that it's using a delegated access token from Tweetie, and not
from some other app.

This would work, but I'm not sure how TwitPic would know Tweetie's consumer key from SomeRandomApp's consumer key. Twitter might have to reply with some data about the consumer key that TwitPic could show to the user (see above). So I don't know if it has to be Tweetie's consumer key but some value that TwitPic can compare against in the future.

I do think that would work.

Of course, this extra call (TwitPic->Twitter) could be avoided if Tweetie asked for a delegation token and Twitter encoded all this information in "delegation token" itself (i.e. add an issuedTo parameter to the token).

Thanks,
George

Would that work?
Allen


On 2/16/10 8:05 AM, "Brian Eaton" <bea...@google.com> wrote:

>
>
> Here's an example of a broken way to use this:
> 1) Tweetie passes OAuth access token to twitpic.
> 2) Twitpic uses Twitter access tokens to authenticate the user.
> 3) Twitpic holds a wide variety of data on the user's behalf (e.g.
> contact list, calendar, photos)
> 4) Every time Twitter hands out a Twitter access token for a user,
> they also handed out access all of the user's data hosted at Twitpic.
> The Twitter access token also grants access to the user's Twitpic
> contact list, calendar, and photos.
>
> It's unclear to me that users clicking "OK" on the Twitter approval
> page will realize that they are handing out access to *all* of their
> Twitpic data as well.
>

--
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george....@corp.aol.com
AOL Inc.                          Home: gffl...@aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

[Dirk Balfanz]

On Tue, Feb 16, 2010 at 9:01 AM, George Fletcher <george....@corp.aol.com> wrote:

Is there such a thing as a "TwitPic account"? Aren't the pictures all public, and TwitPic needs the Twitter credential to post a tweet to twitter that links back to one of those public images? I guess I'm not much of a TwitPic user. Let's just make sure we try to solve the actual use case, not the what-if-twit-pic-also-had-user-data use case.

Dirk.

[Allen Tom]

Hi Dirk -

That’s why it might be useful to have an API for Tweetie to request a delegated access token for TwitPic. The delegated access token can indicate that it was generated using Tweetie’s credentials to be given to TwitPic.

Regarding George’s suggestion to have an IssuedBy/IssuedTo field in the delegated access token – that makes sense too, although that would require the access tokens to use SWT.

Allen

On 2/16/10 1:12 PM, "Dirk Balfanz" <dirk.b...@gmail.com> wrote:

 

My only problem here is that any interaction between TwitPic and Twitter that uses the AccessToken from Tweetie will look like it's an interaction between Tweetie and Twitter. Is this really what we want?

[Dirk Balfanz]

On Tue, Feb 16, 2010 at 1:22 PM, Allen Tom <at...@yahoo-inc.com> wrote:

Hi Dirk -

That’s why it might be useful to have an API for Tweetie to request a delegated access token for TwitPic. The delegated access token can indicate that it was generated using Tweetie’s credentials to be given to TwitPic.

Actually, I played with it a little bit and it turns out there is user data on twitpic. They remember which picture goes with which user, and allow you to delete (only) the photos that are yours (independently of deleting the tweets that refer to them).

Dirk.

 

Regarding George’s suggestion to have an IssuedBy/IssuedTo field in the delegated access token – that makes sense too, although that would require the access tokens to use SWT.

Allen

On 2/16/10 1:12 PM, "Dirk Balfanz" <dirk.b...@gmail.com> wrote:

 

My only problem here is that any interaction between TwitPic and Twitter that uses the AccessToken from Tweetie will look like it's an interaction between Tweetie and Twitter. Is this really what we want?

Is there such a thing as a "TwitPic account"? Aren't the pictures all public, and TwitPic needs the Twitter credential to post a tweet to twitter that links back to one of those public images? I guess I'm not much of a TwitPic user. Let's just make sure we try to solve the actual use case, not the what-if-twit-pic-also-had-user-data use case.

[raffi]

to be specific, its to delegate identity verification, not delegation
of authority.

(thanks for cross posting! it was on my todo list, but haven't gotten
around to it yet).

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

[Abraham Williams]

On Tue, Feb 16, 2010 at 13:12, Dirk Balfanz <dirk.b...@gmail.com> wrote:

Is there such a thing as a "TwitPic account"? Aren't the pictures all public, and TwitPic needs the Twitter credential to post a tweet to twitter that links back to one of those public images? I guess I'm not much of a TwitPic user. Let's just make sure we try to solve the actual use case, not the what-if-twit-pic-also-had-user-data use case.

There is. TwitPic accounts let you manage your photos, comment and tweet photos. Using Echo TwitPic would not be able to act as the user. They would just store the photo under the users account on TwitPic and return the URL to Tweetie to post to Twitter.

Abraham

--
Abraham Williams | Community Advocate | http://abrah.am
Project | Out Loud | http://outloud.labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.
Sent from Seattle, WA, United States

[Raffi Krikorian]

to be specific, its to delegate identity verification, not delegation of authority :P

(thanks for cross posting!  it was on my todo list, but haven't gotten around to it yet).

--

You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Allen Tom]

Hi Raffi -

It does sound like your specific use case is to enable Tweetie to assert to TwitPic who the user is. The OAuth-Echo proposal defined a mechanism for Tweetie to generate the HTTP Authorization header and pass it to TwitPic so that TwitPic can call the verify_credentials API to determine who the user is.

A very nice property of the Echo proposal is that Tweetie is able to delegate to TwitPic a single API call. I think we can generalize this approach by defining an interface for an application to limit the scope of the delegated access token. For instance, Tweetie could request from Twitter a Delegated Access Token for the “verify_credentials” scope and then pass it to TwitPic.  I think this would be mostly equivalent to the Echo proposal.

Allen

On 2/12/10 2:21 PM, "Raffi Krikorian" <ra...@twitter.com> wrote: