I do not create big websites, so I'm mainly a user of openid and it's various implementations. I use openid here in SO, and I like it because I'm using my gmail account for everything (I plan to exit gmail in the future, but now I'm using it for everything), so I don't have to remember another login/account.
So, in my naive user mind, I think using openid is simple: you have a lot of providers, when a user tries to login, your app asks his/her provider: "is this person able to login?", the provider returns "this user is valid" with some data (some may return more data than others) or just doesn't return anything if it was an unsuccesfull login for example.
I was planning to use openid in a future website. In my mind, I think I would be using some kind of lib that could "abstract" this for me: your user logins with providers, your app doesn't know each one, and this lib returns a unique identifier from a username from a provider. For example: [email protected] is used to login. It has a unique id in the lib, returned after a hash calculation or something, and your app uses this for everything.
In my application, I would try to deal only with this id created by an openid libm taht would handle facebook, twitter, gmail and such. Maybe this lib has a table with a provider name, and when a person first logins to your site, you have a row in database saying "this unique id is from twitter". In theory, this seems to work in my mind.
...but after reading Openid is a Nightmare, I'm starting to think if it really would be a good idea even trying to find such a lib that would work so perfectly.
Since everyone (openid providers) now has it's own login mechanism, instead of worrying about only one system (my own, I were to create my own login mechanism) - now I have to worry about dozens of systems - and openid was supposed to address exactly that. Now, I need a huge lib I'm envisioning to abstract this whole mess.
Does a library like the one I described exist? If so, is it possible to create an application that at least tries to behave like a really "openid" dream?
(I know openid is not the same as facebook auth and such... but from an end user perspective, it's the same IMHO, "use the same login across websites". I want to abstract the login process even if the protocol wasn't made just for that. For a lot of services, you just need to know if someone is who she is claiming to be.)
Libraries do exist (such as DotNetOpenAuth), but these usually only abstract the protocol and spec for you - your application still has to be aware of the individual providers (and their quirks).
One of the biggest problems with OpenId/OpenAuth in my opinion is that many providers do things slightly differently: Some of them will give you the info you ask for, some will not. Some of them respond to Simpleregistration/Claim, some of them respond to AttributeExchange/Fetch. Some use a general url for logging on, some require one with the username incorporated.
There are many subtle differences, which make OpenId a lot weaker than it should be. Ideally it should have been a system that I (as a website owner) can implement, and feel confident that I now support any user that has an account with an OpenId provider. The reality is quite different. And you are always going to have to track your user with your own ids, even if you use OpenId for authentication.
There are services, such as RPX/Janrain that purport to take care of all of these messy details for you, but I have heard that even this has its headaches (e.g. it is mentioned in the article you quoted).
At the end of the day it probably comes down to the type of website you run. Ask yourself this (rather cynical) question - How much do I care if an individual user can't log in? If the answer is 'a lot' (because each issue will cost you money or cause other grief) then maybe forget openId for now. If it's a mass/free website like stackoverflow then it might be the way to go.
Update
There's a comparison of some provider implementations here: http://spreadopenid.org/provider-comparison/. It's no longer updated though so it might be out of date. [Down at the moment, possibly permanently, but see google's cache]
You might be able to find more info via Wikipedia's list of providers
There's also a pretty comprehensive comparison of providers here.