I posted a response on the blog which I am copy-pasting here:

If the intention is to just delegate identity, this can be achieved more
easily with what is available today:

The Consumer, prepares a verify-credentials HTTP request, signed with its
OAuth token, and passes this URL to the delegator, which in turn will simply
issue this request on the consumer's behalf.

Since a signed request doesn't contain the token-secrets, this is pretty
safe to the consumer as well as end user.

Some more thoughts:

   - Perhaps the plan is to scale this workflow to action delegation. In
   which case it makes sense to introduce the new flow.
   - The term delegator is confusing. Shouldn't it be delegatee or something

On Wed, Feb 10, 2010 at 5:43 AM, Raffi Krikorian <ra...@twitter.com> wrote:

> hi all.
> i apologise that i'm running behind on getting these out, but i've put out
> the first in a series of blog posts regarding what twitter is doing with
> oauth moving forward -- this one, specifically, is a RFC around "delegation
> in OAuth identity verification".  a total mouthful, i know, so it may help
> to think about it in a concrete example:
> You're an OAuth enabled Twitter client, and you've already authorized your
>> user.  You user wants to use a media providing service like TwitPic.
>>  TwitPic, currently, asks for the username and password of your user so it
>> can store the photo on behalf of the Twitter user.  You don't have that
>> username and password, so how do you give the ability to TwitPic to verify
>> the identity of your user?
> that being said, please check out
> http://mehack.com/a-proposal-for-delegation-in-oauth-identity-v.
> thanks!
> --
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi

Harshad RJ

Reply via email to