Phil Windley has summarized an e-mail conversation between himself and myself, on the question of multi-protocol identity implementations.

So far, I believe MyLID.net (Sign up!), the hosted identity service that we are running at NetMesh, and its equivalent InfoGrid LID software implementation, are the only multi-protocol, user-centric identity implementations there are: they support LID, OpenID and Yadis in the same, tightly integrated package. So Phil ponders whether or not multi-protocol implementations will become common-place, and whether it is more likely that Relying Parties become multi-protocol, or identity providers.

Among other things, he writes:

• There will be hundreds of identity providers and I'll have accounts at dozens of them. Still, I don't want to pick which identity provider I choose to use for a particular task according to what protocol they speak (that should be below the radar) but rather according to other "business" criteria. I may choose to use my Amazon account sometimes and my BYU account other times.
• As a relying party, I don't want to have to worry about which scheme to use. In fact, I care more about what conclusions I can draw from the authentication protocol used and the data it provides than I care about the specific protocol...
• Relying parties will want to support multiple authentication schemes and need software and systems to do it.
• Identity providers will compete to support as many as possible in order to be as "full service" as possible.

I guess I agree with all of these conclusions. The history of TV or even power chords is a great example: different standards evolved in different sub-markets, but instead of one sub-market suddenly switching from 110V to 230V (or vice versa), or from PAL to NTSC, modern TV sets understand all of those and the user can simply "plug in" their device without worrying about what's underneath.

This is of course a vision we want to help achieve for user-controlled identity, which is why we have implemented all these protocols in the NetMesh code base already, and why we (and I myself personally) am so engaged in driving convergence ...