I think the reasoning given is valid. It's not necessarily a rogue OP or employee, but even a negligent employee who hands out a password.
Or someone who got hacked, etcetera. Until truly user-centric identity (your personal webserver living on your person, and all that) is here, decentralization is more by way of making sure that no single 3rd party can effectively withdraw its "user" tendrils back into the main blob and swallow back up your Identity. There's already been some discussion of that, since delegation enables us to switch to a new OP if the OP goes down or we decide we don't trust that OP anymore, but doesn't give us anything to do for when the *URI* (host) goes down (or is bought out, et all). Having a way to associate multiple OpenID's with the same account (at RP's) is one way of dealing with this, but to be effective when we actually *need* it, it needs to be done in advance - which means (if you look at the process) MultiAuth.
XRI would be another way - it would keep a global registry of deliberately unattractive hexadeximal strings (the iNumber) that noone (even geeks) would have any interest in seeking as a vanity handle, and then let users map their iNumbers to various domains (and more) they owned, or iNames.
I just took a very quick scan over the draft, but it does not seem to address the problem. Whoever serves the XRDS document could include two or more OPs that are not trustworthy and/or point to compromised URLs.
Yes, the host is still a weak point in OpenID's trust diagram. If you apply MultiAuth to hosts as well as OP's, though (not just the OP that both users happen to trust suddenly authenticating an attacker who claims to *be* both users), and a *RP* requires two or more URI's to be in use (still with different OP's) before granting access (at whatever level), attackers would need to compromise two hosts (one in each URI/OP pair) to gain access to the user's account at that RP.
-Shade _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
