Interesting discussion going on on Chris’ blog about OpenID & usability. There are many aspects I’d like to discuss, but it’s 11:34pm and “tomorrow” I have a conference call at 7:00am (sometimes the fact that the Earth is round DOES suck: sorry, Cristoforo): hence I better pick carefully. Ah, did you read the disclaimer that says that my opinions are just mine and do not necessarily reflect the positions of my company? Before linking & flaming repeat it mantra-style a few times :-)

• I am fascinated by the difficulty of articulating why one OpenID provider should be chosen over another: the credit card metaphor is really a good attempt of rationalizing, however IMHO it still doesn’t solve at the root. In the end what you can do with a credit card is the same regardless of the provider, payments: what changes is how convenient is doing business with a certain provider, but that’s not inherent to the main function (you pay a monthly fee for a credit card, but also for an insurance; the calling center may be the same for both; etc). The rationale for this metaphor is solid, since for how it is prevalently used today OpenID does provide one main function: outsourced credentials verification. I am not saying that the protocol cannot do more, it can: but the most common usage is a RP asking an OpenID provider if a certain user has indeed an account at the provider’s, and if he/she successfully logged in. For the RP that’s the usual returning user verification, minus the credentials verification & maintenance. That’s MECHANICS. If the OpenID provider happens to be an entity with whom the subject has a relationship apart from simply having an OpenID account there, for example it’s a bank or a mobile operator or a hospital, then you have more than simple outsourcing of credentials verification & maintenance. Being able to present an OpenID token issued by such an entity is not just a matter of having performed a successful authentication, it also gives information about your identity of bank customer, customer of a given wireless provider or patient of a certain hospital. There is NO STRUGGLE in understanding how you would differentiate among those OpenIDs, since in general the kind of RP you are approaching would give you a context for deciding who you want to be there. Of course things would not always as clear as the above scenarios, however you can imagine that there could be more general purpose OpenID providers (your ISP, your webmail, etc) that you’d use for less crisp cases: however they’d be one of the types, rather than the norm.
  If your OpenID provider does nothing but the OpenID provider, then I agree that the differentiation moves to the quality of service rather than the nature of the service: in the end, the semantic of presenting an OpenID token is just demonstrating a successful authentication and in term of the scenarios it enables there’s really no big differentiation in picking an operator or the other in term of intrinsic capabilities. I don’t want to play too much with words, but IMHO with pure-play OpenID provider you don’t really trade identities (ie sets of attributes describing some aspects of yourself) but rather accounts. Again, I am not talking about the protocol capabilities but of their classic usage to date.
  Again IMHO, pure-play OpenID providers are “artificial” entities that are necessary for bootstrapping the ecosystem: in fact, I believe that their emergence can be predicted by the justifiable parties law, there is a need for infrastructure for performing a certain function hence thos eentities emerge. Once and if the protocol will be established, I would expect that entities with a pre-existing relationships with subjects will become providers as well, and in so doing giving a chance to their customers to express their affiliation in easy, standard, convenient way. Being a big believer of the potential of the metasystem, I think that the above will happen not just for OpenId but for all the protocols which allow the above (WS-Trust, WS-Federation, SAML…). Again for the law of justifiable parties, I would expect that in such a phase only a few pure-play OpenID providers would remain since the widespread adoption among entities whose core business is not just account maintenance would provide a better match in many transactions. If today I want to sign in in a health-related RP with OpenID, I have to choose a pure-play provider: if I’d have the ability of obtaining an OpenID or any other token from my medical insurance, however, chances are that it would be convenient to use the latter since that would likely bring advantages (like asserting my insurance status).
  Note that in the above I resisted to the temptation of pulling claims in the conversation: those would have been a booster in the “account vs identity” differentiation.
• OpenID “Nascar” effect. The problem described here is very well known in the context of enterprise identity management, and that’s called “home realm discovery”. If I have many federated partner, in the general case I have no way of knowing the affiliation of the user that is currently visiting my site: is he from partner A or B? Sometimes it’s possible to pick the user affiliation automatically, hence the system can take care of all the necessary redirect and you get the oh-so-precious SSO and the business decision makers love. Sometimes that’s not possible: often the “solution” is a drop-down box on the RP pages where the user can pick his affiliation, and from then on the normal authentication flow follows. In internet & consumer scenarios, things get worse:
• On the internet you don’t have a home realm. This is really a basic, basic point but you’d e surprised by how many people won’t connect the dots. When you sit at your workstation at your desk at work, everything you do is under the motherly wing of your zaibatsu: if you navigate to the pages of a federated partner, your identity of employee of company X enshrouds you and can be used for SSOing you in.
  On the internet you don’t have a unique, incontrovertible identity. Rather, you have a relationship with many different entities and, if you are lucky, such a relation can be expressed by a token of some sort that you can present to RPs for asserting which persona you want to be there. Which one will you choose? Who knows. Maybe there is one you want to use more often than usual, and maybe for convenience many users would like to just have one that is used semi-automatically everywhere they go: and while I understand such a desire, I believe that we cannot IMPOSE it (consent, anyone?).
• The internet grows like a coral reef. There are RPs that will want to limit the pool of trusted providers to a certain set that meets some kind of bar. There will be other RPs that are just interested in outsourcing account management and just need a moniker for every user, so that they can keep their customization profile, regardless of the reliability of the provider. In the latter case, the hypothetical drop-down would continually grow and the RP would simply not have enough information to know if on the other side of the reef a new provider just blossomed. No, the drop-down approach on the internet would be very elitist and probably favor the top providers.
  

The nice part about the home real discovery is that it has a simple & elegant solution, which happens to work well on the internet too: information cards. Let’s make the easy case, and RP that just want to get a token from you regardless of from where you’ll obtain it. Let’s say that you are affiliated to 3 different providers: for each of them you have a card. The RP just need to specify that it needs a token made in a certain way: once you’ll land on his pages, all the cards that satisfy the requirements will light up. The same will happen to everybody else, regardless of from where they are obtaining their tokens: the RP does not need to worry about providing any drop-down. In other words, you are relieving the RP from providing UI that takes into account the affiliations of all possible users while relying on who already have the right information, the user (helped by the card selector). In enterprise scenarios this works beautifully. A business ISV offering federated access to their S+S application would just ask for a token made in a certain way: employees of company A will see their A card light up, while employees of B will see B cards just because that’s what the users have in their respective selectors. This would beautifully support the “universal” button that Chris describes, and in fact that’s easy to do with cardspace today.

Alrighty, I ended up spending one hour on the above; and I didn’t even touch the phishing parts! I’ll have to set up firecrackers together with the usual alarm in the smartphone. I usually don’t comment on those topics, because I am painfully aware of the fact that I am not as deep as I would like to be on the OpenID topic: however the above is more pure architecture than anything else. And again, remember the disclaimer! This is me blathering late at night, not a spokesperson. If you comment or link to here, please say “Vittorio writes…” or “that hairy character writes…” and avoid cheap shots at my company by saying “a Microsoft employees writes…”. Healthy discussion!!! :-)