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.


Reply via email to