The term most frequently used for "delegator" is "relying party." What you
call the service provider is most frequently called the "identity provider."
What you call the consumer is usually called the "subject." See OpenID,
InfoCard, and other similar specifications for example usage of these terms.


The subject does not want just *anybody* to verify his identity; he only
wants the *relying party* to be able to verify his identity. So, the subject
needs to be able to identify the relying party in the string he signs. Then
the identity provider needs to be able to verify that the relying party is
the one making the request, so the relying party needs to sign the request
with its OAuth credentials.


The subject doesn't want the relying party to have access to the entire
response from the account/verify_credentials request as if he had given the
relying party read access to his account. I am not sure if
account/verify_credentials returns sensitive information (information only
available to apps that have been authorized by the user) yet, but I think it
is likely in the future that it will do so. It would be prudent to have
delegation use a different resource designed specifically for delegation.

Also, it would be great if the consumer could require the delegator to also
use TLS when verifying the identity. Maybe OAuth Wrap/2.0 will mandate HTTPS
for this?


Careful attention needs to be paid to whether or not it is safe to expose
something the subject has signed to the relying party in OAuth WRAP/2.0, if
WRAP/2.0 is designed to have this information always protected from third
parties with TLS.





[] On Behalf Of Raffi
Sent: Tuesday, February 09, 2010 9:23 PM
Subject: Re: [twitter-dev] A proposal for delegation in OAuth identity


hi all.


thanks so much for the conversation so far!  its been great.  i've taken a
bunch of the comments and incorporated them into a newer version


let's continue to tear this apart.


On Tue, Feb 9, 2010 at 8:43 PM, Harshad RJ <> wrote:

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 <> 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



Raffi Krikorian
Twitter Platform Team

Harshad RJ

Raffi Krikorian
Twitter Platform Team

Reply via email to