That is similar to what we are doing at TweetPhoto and it is working out fine.
Feel free to check out what we are doing: http://groups.google.com/group/tweetphoto/web/oauth-signin Third-party apps share with us their app's consumer key and secret. We receive the same level of access to the third-party app using our photo sharing service. When two companies work together and are partners there needs to be a level of trust. Furthermore, developers can change their consumer secret at any time so their is no real issue with this method. There are a few integrations coming out soon with this method in place. Please let us know your thoughts and if you have any questions. Sean On Feb 11, 10:05 am, Brian Smith <br...@briansmith.org> wrote: > 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