A balance of power: Identity based on DIStrust

[SitG Admin]

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
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

I should note that the answer I propose to the first question would
only work for sites the user had logged into in the past, and that it
would presume that the RP had kept track of which Identities the user
previously authenticated with.

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general