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. Regards, Brian From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Tuesday, February 09, 2010 9:23 PM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] A proposal for delegation in OAuth identity verification 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 http://mehack.com/a-proposal-for-delegation-in-oauth-identity-v-0 let's continue to tear this apart. On Tue, Feb 9, 2010 at 8:43 PM, Harshad RJ <harshad...@gmail.com> 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 <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 http://hrj.wikidot.com -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
