Email Address to URL Transformation

[SitG Admin]

>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