[OpenID] On the portability of identifiers

[SitG Admin]

>If anyone is interested in discussing this further, please let me know.

YES!!!
http://openid.net/pipermail/general/2008-July/005115.html
Indeed, this is where my "follow-up" post (the one I've put on hold 
until after the elections, when I'll be free to work on it) was 
(almost) at, and I've been meaning to finish that for a while now :(

>One way of solving this is to have more then one identifier -- 
>essentially an identifier set -- so that if you lose control of one 
>identifier, you have not lost control of the identifier set.

The same applies for your provider of that identity going out of business.

>If the set has three identifiers, then you only need to present two 
>of them to show it is you, and then you can substitute a new 
>identifier so that you again have a redundant set.

RP's should also let the user, at signup or any point thereafter 
(when authenticated with a majority of their set), increase the 
minimum number of identifiers that are required for making changes - 
so that, if a user who once had only 3 identifiers gradually acquires 
2 more, they can say "Okay, now we need THREE identifiers to make 
changes.", and still enjoy fault-tolerance if suddenly TWO of them 
were to go down or become hostile.

RP's could also allow settings for customized access based on 
specific identifiers. For instance, if I log in with my work ID, 
don't show me the personal E-mail's! Anyone who steals the work ID 
would find damage control measures already in place - but it's more 
than that. Think invisible filtering to help you focus on just the 
important stuff (using *your* webmail account for everything, even 
though you run several "identities" through it and actually use POP3 
for your personal stuff), with a sanitized data set for anyone 
peeking over your shoulder (no more worrying about whether some 
private aspect of your personal life is visible on the screen at any 
one moment, capturable by spyware (that may be installed/run by the 
company!), provided your RP coded its privacy protections correctly).

Getting your workplace to support you+work at company.com seems easy 
enough (it's practically an employee perk! "With us, you don't need 
to keep track of one more E-mail address, you can use your old one." 
- with the appropriate alliances to have OpenID webmail providers 
readily available to the user that hasn't seen any before), but I've 
read that not all mail clients can *send* to this kind of address, 
and for a business with large numbers of users it may be a 
deal-breaker to have addresses that actual (as well as potential) 
customers wouldn't be able to use.

>An implementation of this would be to have two URLs and one 
>public/private key pair. The URLs each contain a document that 
>references the other URLs as well as contains the public key.

There's also the strict "vanilla" implementation where an XRDS file 
(location found at each URI) specifies other URI's. Reduced effect on 
privacy (though you can still list your work URI in the home XRDS 
file, and omit the home URI from the work XRDS file, knowing that 
you'll never need another point of authentication while you're using 
the work URI), but doesn't require the RP to integrate/support this 
kind of crypto.

>In a world of opaque identifiers and smart clients, this all can be 
>transparent to the user. They just saw they want to log in with a 
>particular identifier set.

For now, the problem is (only!) with presenting the user that list of 
identifiers. But the problems here are privacy (try one identifier, 
see them all, or at least another), not implementation, which we can 
already handle transparently:

If we know which identifiers the user wants to authenticate with, we 
can send them off to the first, and, the moment they return, 
immediately dispatch them to the second. If the second gracefully 
fails (automatically (via checkid_immediate) or by the user's choices 
there), the user was sent back with information on that refusal and 
we move on to the third. We can remember the list of identifiers from 
their last login (and they need to provide a majority authentication 
before adding more identifiers, anyway), and either present them with 
a list of identifiers they've used before ("Click the checkmark boxes 
by identifiers you want to use *this* time." would let users specify 
identifiers they wish to *avoid* using, either because it's down or 
if they don't wish to have that OP know about their login this time), 
or silently keep track ourselves.

-Shade