Here's my list, in no particular order:
- OpenID is a mystery to anyone who isn't a geek, and also to many geeks.
- The extent of OpenID's positive (or negative) influence on user signup rates, or anything else, is unproven. The technology brings no clear benefit on day zero. Nobody can tell you what the return on investment is.
- OpenID used to be about the promise of one-textfield signup. But, oops, if you want to speak to the user again you also have to ask for an email: two textfields. If you want to make sure the email is valid you need to mail out a confirmation link. At which point do the advantages of OpenID wash out? There is no usability data.
- There are security questions, but few answers. The number of free variables, and the fact that nobody bothers to attack a system with no significant userbase, makes these issues hard to pin down. It is certainly true that a less-than-perfectly-competent provider can render OpenID very insecure.
- OpenID, as proposed, introduces a dependency between your code and the code running on hundreds of providers scattered across the net. You have no control over these providers, they have no legal obligation to you, and your site's uptime is completely dependent on their uptime.
- There is no standard OpenID provider implementation, so there is no way to know at any time which of your users' identities might have been compromised by insecure or unpatched software. There is no way to run automated tests between your code and that of every provider. If you do find a bug in a third-party-provider's code, you have to beg them to fix it, or beg a subset of your users to switch providers.
Yeah, I know, there's a standard. There are standards for email, too. Find a forty-year-old email admin and ask them how easy it was to make all the mail servers on the net conform to those standards.
- Your users probably don't understand OpenID very well, so when they have login troubles they will complain to you. You can't fix many of these problems, but they will not know that. Your $20-an-hour tech support person may not know, either: is your site at fault, or the provider's site? Even your $100-an-hour back-end programmer may have to spend twenty minutes figuring it out. Then, if it's the provider's fault, that fact has to work its way back up the support chain to the user, who will be confused and unhappy. Multiply the cost of such an incident by the number of confused users. Estimate the number of users who will be confused. By OpenID. Better go looking for another round of investment.
- Finally, an OpenID provider owns a subset of your users -- it may not own them outright, if you've been shrewd enough to capture email addresses, but it certainly owns them as much as you do. The provider can redirect the users, show targeted ads to them on the login page, allow your competitors to bid on them. It can do all this with perfect knowledge of when, where, and how often your users log in to your site and most of the other sites on the net.
---
Now, a lot of these problems go away if you give up on the "Open" part of OpenID and restrict your users to a certain subset of "trusted" providers. Like, say, Clickpass. You can sleep well at night knowing that the Clickpass folks are smart, that they fix their bugs and answer their mail, that if something goes wrong for a user there's only two places the bug can be (your site or Clickpass), that their security has been audited, that they have a decent privacy policy, and that they've done their best to make it all so simple that a monkey can understand it. Then, after Clickpass has become successful, they'll be bought by Microsoft, renamed to "Passport II: Electric Boogaloo", and everyone will live happily ever after.