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
