Re: [twitter-dev] A proposal for delegation in OAuth identity verification
Raffi Krikorian wrote: 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. First, what I wrote about subject was misleading: the user--not the consumer--is the subject. i hear all this - it just gets a bit complicated with because we are conflating this with our oauth situation. This doesn't really have much to do with OAuth, because you are not trying to allow delegation of credentials--that is, you are not trying to allow the consumer app to let the relying party use the consumer app's OAuth access token to read/write the user's account. perhaps its time to move to an oauth + openID hybrid system. I don't know if OpenID really solves this problem well, especially for apps that aren't webapps. 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. i think this is again a general case vs a twitter case. i think in the general case, the delegator would call some endpoint that would simply verify the identity through a HTTP code (2xx for success, 4xx for failure). twitter, as a special case, sends along the user object [as] part of it? account/verify_credentials discloses information that is private. For example, the HTTP header of account_verify_credentials discloses information about how frequently the user accesses twitter (the rate limit headers). If the user hasn't previously authorized (via OAuth) the delegator (relying party) to have read access to his account, then the delegator (relying party) shouldn't be able to get this information. Also, I think you should plan ahead for the case where account/verify_credentials returns even more sensitive information. If you were going to reuse an existing resource, I'd reuse users/show.format?user_id=username instead. But, AFAICT, it's much better to create a new resource for this purpose, and pretty easy to do so. I think the following would be a better protocol: Consumer to Relying Party: Give me RP-SIGNED-TOKEN, a nonce signed with your OAuth credentials for the relying party'sidentity verification service. Relying Party to Consumer: Here is the token RP-SIGNED-TOKEN. (This is done using whatever protocol the consumer and the relying party agree to use.) Consumer to Identity Provider: Here's RP-SIGNED-TOKEN. Give me IP-SIGNED-TOKEN, which is (RP-SIGNED-TOKEN, screen_name) signed with a signature that the relying party can verify is from the identity provider. Identity Provider to Consumer: I verified that the token was signed by the relying party identified by RP_ID. Here is IP-RP-SIGNED-TOKEN. (This is an OAuth-protected transaction using the consumer's credentials). Consumer to Relying Party: Here is IP-RP-SIGNED-TOKEN.Relying Party to Consumer: OK, let's continue on with whatever we need to do. (This is done using whatever protocol the consumer and the relying party want to use.) Notice in particular: (a) each server only has to process one request, (b) the relying part and the identity provider never have to communicate directly with each other, (c) the consumer (user) can control the level of security used in all the communication (e.g. TLS for everything), (d) IP-RP-SIGNED-TOKEN can be used as the assertion in the OAuth 2.0/WRAP assertion profile, if the relying party is using OAuth WRAP to authenticate the user, (e) the user and the identity provider can both restrict which consumers can sign into which relying parties for which users using this mechanism. Regards, Brian
Re: [twitter-dev] A proposal for delegation in OAuth identity verification
account/verify_credentials discloses information that is private. For example, the HTTP header of account_verify_credentials discloses information about how frequently the user accesses twitter (the rate limit headers). If the user hasn't previously authorized (via OAuth) the delegator (relying party) to have read access to his account, then the delegator (relying party) shouldn't be able to get this information. Also, I think you should plan ahead for the case where account/verify_credentials returns even more sensitive information. If you were going to reuse an existing resource, I'd reuse users/show.format?user_id=username instead. But, AFAICT, it's much better to create a new resource for this purpose, and pretty easy to do so. oh - most certainly. at some point, or maybe with the launch of something like oauth echo, we could have a different endpoint that just provided the screen name, or something like that. the endpoint that the delegator users on the service provider is up to different implementations. in the twitter case, we very may well deal with account/verify_credentials -- we only show user objects there, which are discoverable by other public means. I think the following would be a better protocol: Consumer to Relying Party: Give me RP-SIGNED-TOKEN, a nonce signed with your OAuth credentials for the relying party'sidentity verification service. Relying Party to Consumer: Here is the token RP-SIGNED-TOKEN. (This is done using whatever protocol the consumer and the relying party agree to use.) Consumer to Identity Provider: Here's RP-SIGNED-TOKEN. Give me IP-SIGNED-TOKEN, which is (RP-SIGNED-TOKEN, screen_name) signed with a signature that the relying party can verify is from the identity provider. Identity Provider to Consumer: I verified that the token was signed by the relying party identified by RP_ID. Here is IP-RP-SIGNED-TOKEN. (This is an OAuth-protected transaction using the consumer's credentials). Consumer to Relying Party: Here is IP-RP-SIGNED-TOKEN.Relying Party to Consumer: OK, let's continue on with whatever we need to do. (This is done using whatever protocol the consumer and the relying party want to use.) Notice in particular: (a) each server only has to process one request, (b) the relying part and the identity provider never have to communicate directly with each other, (c) the consumer (user) can control the level of security used in all the communication (e.g. TLS for everything), (d) IP-RP-SIGNED-TOKEN can be used as the assertion in the OAuth 2.0/WRAP assertion profile, if the relying party is using OAuth WRAP to authenticate the user, (e) the user and the identity provider can both restrict which consumers can sign into which relying parties for which users using this mechanism. in general, i really like this mechanism. from just a usability standpoint, however, it means that the consumer has to make a few calls simply to perform one action -- they have to call Twitter and then the service provider. on top of that, a real world example would have them: 1. call the delegator to get a token; 2. send that token to twitter to get another token; 3. call the delegator with that received token to perform the action; and then 4. (outside this protocol) call twitter to post the status update after that action has been performed. another possible problem i have with it is that it assumes that the identity provider can sign something in a way that the delegator can verify it? oh - i suppose that may be the case -- we could use the consumer secret of the protected resource/delegator. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] A proposal for delegation in OAuth identity verification
On Wed, Feb 10, 2010 at 1:39 PM, Brian Smith br...@briansmith.org wrote: The subject does not want just **anybody** to verify his identity; he only wants the **relying party** to be able to verify his identity. If I understand correctly, a URL signed using OAuth can be accessed successfully only once, because of the oauth-nonce parameter. Or atleast, it is possible to implement such a restriction at the identity provider's end. -- Harshad RJ http://hrj.wikidot.com
Re: [twitter-dev] A proposal for delegation in OAuth identity verification
The subject does not want just **anybody** to verify his identity; he only wants the **relying party** to be able to verify his identity. If I understand correctly, a URL signed using OAuth can be accessed successfully only once, because of the oauth-nonce parameter. Or atleast, it is possible to implement such a restriction at the identity provider's end. yup - that's the case. the nonce prevents the call from being used twice, and you can't delay verification (to an extent) because the timestamp on the signature will fall out of bounds. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] A proposal for delegation in OAuth identity verification
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. i hear all this - it just gets a bit complicated with because we are conflating this with our oauth situation. perhaps its time to move to an oauth + openID hybrid system. 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. in the general case, i completely understand this, in the twitter case, however, i'm not so sure? either way, as i said, i believe this in the general case, and i will modify to account for this. 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. i think this is again a general case vs a twitter case. i think in the general case, the delegator would call some endpoint that would simply verify the identity through a HTTP code (2xx for success, 4xx for failure). twitter, as a special case, sends along the user object ass part of it? 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? that's going towards the oauth 2.0/wrap world. when i write this up to account for oauth 2.0/wrap, i'll note that ssl is required. this has been great! -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] A proposal for delegation in OAuth identity verification
Hi Raffi, Very pleased that this went out... I've been pushing for this on this list for quite a while now... Let us know if you need any help in any way... As a side note - TweetPhoto has claimed on this list that they have some sort of oAuth delegation live?? I haven't played with it yet, but perhaps someone who has can comment on what it actually is that they've done? Thanks, Michael. On Tue, Feb 9, 2010 at 4:13 PM, 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
Re: [twitter-dev] A proposal for delegation in OAuth identity verification
Very pleased that this went out... I've been pushing for this on this list for quite a while now... Let us know if you need any help in any way... i think the biggest thing is just to comment on it, or let me know that it makes sense. this is relatively easy for us to implement, but we want to make sure its right before go forth. As a side note - TweetPhoto has claimed on this list that they have some sort of oAuth delegation live?? I haven't played with it yet, but perhaps someone who has can comment on what it actually is that they've done? tweetphoto has a notion of delegation - http://code.google.com/p/tweetphoto-api-objective-c/ the main difference, however, is that they require that the client's consumer key be shared with them -- that breaks the security model of oauth a bit. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
RE: [twitter-dev] A proposal for delegation in OAuth identity verification
In the example, would the user have to grant TwitPic access to his account? I would like to be able to assure TwitPic about the user's identity without the user having to grant TwitPic any read or read/write access to his account. Why does the delegator need to send the service provider x_request_method, x_request_url, x_request_parameters, and x_request_authorization? For example, why does Twitter need to know what the user is doing with TwitPic? It seems like an unnecessary disclosure of information that should stay between the consumer and the delegator. The end-user might want to authenticate using his Twitter credentials without telling Twitter what he's doing. Instead, the consumer should just sign some constant||timestamp||nonce||expiration_date with their Twitter access token/secret, since that's all Twitter needs to verify the end-user's possession of the Twitter access token. The delegator should be responsible for securing its own service (e.g. against replay). In particular, the delegator should be able to use this service, even if the delegator doesn't otherwise use OAuth for protecting its own resources, and even if the consumer isn't communicating with the delegator over HTTP (think WebSockets, SPDY, etc.). Regards, Brian Raffi Krikorian wrote: http://mehack.com/a-proposal-for-delegation-in-oauth-identity-v http://mehack.com/a-proposal-for-delegation-in-oauth-identity-v
Re: [twitter-dev] A proposal for delegation in OAuth identity verification
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
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.comwrote: 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
