On being an Open ID(iot)

As I know so many people whom I both like and respect but who are also very keen on Open ID, I've been reluctant to carp (and it could just have been me who found it hard going), so I'm glad someone else has come out the closet on this.. Jan Miksovsky logs most of the issues I came across and many more, and his conclusion roughly matched mine:

For the time being, I can’t imagine a sane business operator forcing their precious visitors through this gauntlet of user experience issues just for the marginal benefits that accrue to a shared form of ID. I've read numerous claims that all it will take is for someone big like Google to support OpenID to crack this problem open. Unfortunately, there's no business of any size that can afford to direct their traffic down a dead end.

In short, if it's fiddly for a tech tart like me, its not going to fly with the mass market. Jan offers a good list of proposed solutions. I'd like to second them otherwise this idea of an Open ID, which I support, will wither away.

1. Redesign the OpenID home page for consumers. The page's main content should contain a brief explanation of OpenID in consumer-friendly terms, along with a giant Get an Open ID button. Move all the developer material behind a Developers button.
2. Design an end-to-end process for getting an OpenID from a service operator's site. Since most services won't care which provider the user uses, let these services send the user into a real flow for picking a provider, getting an ID, and most importantly coming back to the original service to use the new ID. When they get back to the service, the new OpenID should be prefilled.
3. Give the above flow a sidebar titled "Do you have a blog?" that explains that, if they have a blog on LiveJournal, TypePad, etc., they can use that for their OpenID. A link in the sidebar should shunt the user into a page that has them pick their blog provider, then tells them what the (blog service dependent) form of their OpenID is. The flow should then return the user to the service they started on (again, with their OpenID prefilled).
4. Organize the list of providers around factors that can actually influence a user's decision. Consider offering provider ratings based on ease of use, uptime, etc.
5. Refine reference designs for the complex range of cases that come up in using OpenID with a service. E.g., define the expected behavior and terminology that should be used when a user tries to log in with an OpenID but does not already have an account with that ID.
6. Define guarantees that services should offer to users in the event their OpenID provider goes out of business.
7. Build an organization that can do real usability testing on this service with real consumers.