[OpenID] A balance of power: Identity based on DIStrust

SitG Admin sysadmin at shadowsinthegarden.com
Sat Jul 12 00:48:50 PDT 2008


I've been thinking about privacy, and for a moment I blanked out on 
the fact that we have this feature called "Delegation" now, which 
lets us outsource the authentication to a site other than the one our 
Identity is being hosted on. This doesn't really provide any 
*security* since the ID-hosting site can still temporarily redirect 
RP's to an OP of it's choice, bypassing the security at a user's 
designated OP, and then it can even make matters *worse* by giving 
that delegated-to OP the opportunity to masquerade as the user. So, 
we have 3 parties here who can act as the user, and 2 of them could 
be any number of employees with the ability to make changes. The only 
benefits I see delegation providing are outsourcing (in case the 
ID-hosting site can't run, or isn't running, a Provider themselves) 
and privacy (the ID-hosting site can't track which RP's are checking 
the user's authenticity with an external OP).

(Now, the ID-hosting site *can* look for User-Agent strings 
associated with common OpenID libraries, and check for requests to 
every user's Identity page, looking up the IP addresses of probable 
RP's to find out what site they were coming from. To mitigate this, I 
suggest an extension to OpenID whereby the lookup of an Identity page 
to discover the OpenID headers can *itself* be outsourced - this 
wouldn't help with timing, though, so the ID-hosting site could still 
(potentially) keep track of *when* a user was authenticating to a new 
service, and how often they used their OpenID elsewhere.)

While a single rogue employee (or boss, or IT sysadmin) may be able 
to leverage the resources of their entire company, their influence 
outside that sphere should be limited. Not only is there the expected 
difficulty of feeling out potential companions in crime, but some of 
these other companies will be *competitors*. I'm not thinking of the 
compounded effect here (where prospective co-conspirators are looked 
upon with more than the usual suspicion, because they're not usually 
friendly anyway), though this can be a factor; I'm looking at the 
typical effect of this, where rivals don't *trust* one another (even 
where misuse/abuse of information isn't the issue) because the 
"proper" use of information could still work against *your* company. 
I'm assuming we can count on the idea that giving any advantage to 
the competition will evoke a strong adverse reaction; indeed, that's 
part of the problem with gaining acceptance for OpenID so far.

The idea I'm toying with now is whether it's possible to *exploit* 
this atmosphere of distrust (which is ironic, since usually we speak 
about exploiting TRUST, not its opposite) by requiring users to 
authenticate with multiple (competing) Identity sites. The rated 
"Strength" of a user's Identity would be proportionate to the number 
of such sites they had authenticated as - since, presumably, it would 
be increasingly more difficult to persuade the people at all these 
rival companies to cooperate with each other for such a purpose! 
(Especially with the advantage they could gain by *exposing* their 
rivals in an attempt.)

One question is how to prevent someone at an ID-hosting company from 
simply registering accounts with other ID-hosting companies, all 
pointing (for real) to the same malicious OP they temporarily 
redirect Consumers to on the user's actual Identity page. This fits 
in neatly with my observation on how existing practices can 
(potentially) easily implement this sort of security in the real 
world; (some) OP's already allow you to "claim" different sites and 
link them all together under your profile, so it should be easy 
enough to have the OP challenge the user for credentials just once 
for all their URI's. Since the OP has all those Identities, it can 
send them (or a selected subset of them, for privacy) along to the RP 
for verification (checking that the indicated pages actually have 
OpenID headers pointing to that OP), providing the user with the 
convenience of not having to enter them.

Another question is how to prevent OP's from posing as the user. 
This, thankfully, seems far less tricky; let the user specify 
multiple OP's in their OpenID headers and then challenge *each* of 
them, increasing OP Strength accordingly (since presumably the 
different OP companies wouldn't be cooperating, either). This would, 
of course, essentially toss privacy out the window (since *several* 
OP's would know your OpenID activity), but it might be different if 
*all* the OP's were good about the privacy of their users (and 
*would* be different if you didn't care about privacy!), so it seems 
comparable to other (existing) threats to privacy present in OpenID 
already.

Persuading companies to embrace a system that openly acknowledges 
"None of us trust one another, so let's accept it and tell the user 
to like us because we don't require the user to trust *only* us." 
could well be the most difficult part of this idea to implement :)

-Shade


More information about the general mailing list