This is a collection of (anonymized, paraphrased, amalgamated) comments on OpenID that we got in recent months from a number of potential enterprise adopters of OpenID. I figure sharing it might be useful for others who have the same questions, and of course the people in the OpenID community to make course corrections as needed. I've also added some brief comments of mine to respond. Note that I don't necessarily agree with all of these comments; but I believe it is important for us all to recognize these points of view if we want OpenID to be successful.

Perhaps OpenID's best facet is that it solves the discovery problem - the user's ID is owned canonically [controlled] by the owner of the domain portion of the URL. One could then easily use the SAML browser SSO protocol (which supports not only URL identifiers, but other kinds too) to cause SSO (and authentication, perhaps via smartcard, or whatever) to occur.

Absolutely. The reason why Yadis was created, and why it has become a fundamental facility of the URL-based identity stack, is to enable that kind of scenario: Different people/companies will like different parts of the OpenID stack, and not like others, and Yadis enables them to mix and match without breaking the basic architecture, or fragmenting it any more than absolutely necessary.

Of course, it would be desirable in the longer term not to have too many protocols doing the same thing; but in my view, there may be perfectly valid reasons for an adopter of URL-based identity to first only adopt the discovery (Yadis) part, with their own authentication protocol (standard or not), and support OpenID authentication later.

To be honest with you, I'm a little worried about this OpenID work - although there are many people/companies using OpenID in interesting ways, there are also some very odd things - an odd way of making specs.

We are in new territory here. Using a traditional standards process as a comparable, the OpenID "process" is odd, no question ;-) (I feel the need to put the term "process" in quotes...) For example, the Yadis specification was adopted by acclamation on the mailing list, without any real process, open-source style. There are conversation in progress to formalize this more, but so far, we've been remarkably successful without that formalization. Whether or how it will scale is anybody's guess, but the plan so far has been to fix things only when they are obviously broken, which seems like a good approach.

I have been following the discussion, but I am seriously wondering whether it is actually even possible for OpenID to take the next step beyond being a login/SSO mechanism for bloggers.

It already has in certain places. However, I think the basic strategy for OpenID (if there is an agreed one) is to first focus on this market segment is a valid one — it could turn into "Innovator's Dilemma" kind of dynamics between OpenID and other, more traditional identity technology stacks: crappy little toy Japanese cars moved up-market, too, and were very successful with that strategy.

For majority of users, they don't run their own servers so this leaves the role of an identity provider up another entity. For example let's take google's blogger service. For users on that server vast majority do not host their own blogs on their own servers. Thus they relegate the duty of identity provider to google and thus google is now the identity provider for large sets of users.

Yes. There is nothing wrong with this scenario at all.

There's this DTP [proposal], which looks like a re-invention of SOAP, XML Signature and XML Encryption (not to mention several other specifications). I don't think SOAP is the most wonderful thing ever, but I also do not see the need to reinvent most of the specs. that many of us spent the past 6 years working on.

As Scott Kveton recently pointed out, the DTP draft is "just a proposal", no more. I have my own reservations about this proposal, but then, the nice thing is that if you don't like to use it, don't! And if you want to compete with it using something SOAP-based or something else entirely, please do! Yadis lets you plug right in.

[My own reservations have to do with our believe that LID authenticated messaging, which we built into LID more than a year ago, solves basically the same use cases, but is much much simpler. I know the Jan Rain guys disagree with me, and that's fine. This is a great example of the "open innovation model" that we're using in this community. Both plug into Yadis, and adopters can choose to support none, one, the other, or both.]

That's not to mention the fact that my company would be wondering what I was doing if I were to spend more time on solving the same problems all over again.

The context here is potentially getting involved. My principal argument here would be that while the technologies may look to do similar things, the markets in which they are adopted are not. Whether or not to get involved in this community has more to do with which markets people/companies consider important, than the technology per se.

The idea of using URLs instead of email addresses opens up interesting possibilities. I played with this in the past, when spam was becoming a problem and sharing email addresses seemed like an increasingly unappealing proposition. Email addresses are "write-only" IDs (meaning you can only use them to write to somebody's inbox) while URLs are usually "read-only" which is less intrusive for the user.

On the other hand, I'm on the fence about the protocol details. There are already one too many authentication protocols and formats... it's difficult to justify yet another variation without first spelling out what is wrong with all the existing ones.

See my point about market segments above, and about adopting Yadis without OpenID authentication first.

It would be interesting to do a usability study comparing the standard login experience (name/credentials collected atomically) with one based on the OpenID flow. My guess is the slight inconvenience of typing out a longer ID would be outweighed by having clarity around which ID system is involved at all times. One of the challenges users consistently have is not recognizing the boundaries between different ID systems. Most websites use email address as username, which leads to great confusion when people expect that their AOL email/password should work at MSN which is prompting for email/password combination.

I'd be interested in the same thing, and I'd guess something similar!

If you have questions like those or any others and would like to discuss, feel free to get in touch. If you have done so already and not gotten a response from me yet — I know who you are and I apologize — eventually I will get around to it! Thanks for your patience.