One objection was "we don't want to outsource the security of our users to some unknown OpenID provider". His response is: "Do you have a 'I forgot my password, email me a new one' link? Then you're outsourcing the security of your users to some unknown email provider."
Until he said that, I had not really seen it that way. But he's right. "Email me a new password" has exactly the same data flow and security model as OpenID, only with a crappy and slow user experience.
While browing the OpenID wiki a bit, I discovered that there is now an HTTP Auth mode for OpenID. I've added patching that feature into cURL on my todo list. Have to make user there is also a matching Apache module mod_auth_openid to test against.
Someone has hacked together a quick and dirty translator portal between OpenID and XMPP (aka Jabber aka GTalk). It would be nice if the various Jabber providers added this to their respective web presences.
SourceForge has a discussion going asking for community interest in adding support for OpenID. I, of course, weighed in that they should.
It's kind of ironic that the Mailman servers that the OpenID project uses, don't use OpenID. Mailman should be one of the primary targets in having people write and submit a patch to add the feature. (Next should be BugZilla.)
OAuth is a related technology to OpenID. It's just barely getting off the ground, but I think that it will get traction and acceptance much faster.
To get OpenID spread, we need to get lots of small site operators to start supporting it, and most of them are just running their site with a precanned CMS. Getting each one to change is a slow retail one-at-a-time slog.
But OAuth isnt for small sites. It's for bigger system that provide online APIs to their service. Right now, most of the web-service providers that realize that this is important, have their own hand-rolled solution. Flickr Client Service registration, AOL OpenAuth, etc. All the sorts of things were you have to get a an application key so that some client will work with some web service, or so that you can allow some web service A to do something with some other web service B on your behalf, without having to actually give web service A your password to B.
Many of the people who designed/wrote/support the existing per-service protocols were at the BOF, and everyone wants to stop supporting their own custom stuff. There is not likely to be much if any pushback from management or marketing depts either, because maintaining one's own client client auth protocol gives no competative advantage, no "customer lockin", and makes it less likely that people will write clients or foreign service interfaces to your own service.
I'm having a vision of a convergence of OpenID, OAuth, and Atom. Once you can say "This is who I am", "You are allowed to do this for me", and "Here is what I want you to to send/post/do", and nearly every browser, cellphone, PDA, and display client understand the protocols to do so...