OpenID Delegation Makes Vidoop’s Failure Painless*

I asterisked the word “painless” in the title of this post since Vidoop’s downfall certainly isn’t painless for its employees, many of whom I call friends. But as an OpenID user taking advantage of delegation, the process of switching providers is fairly straightforward.

The quick backstory for those of you wondering What Is OpenID Delegation: Delegation allows one to use a URL that is not an OpenID provider as their claimed OpenID URL. A bit of code that is embedded in the headers of that URL contains redirection code so that OpenID requests are sent to the actual OpenID provider.

In my case, I’d been using Vidoop’s MyVidoop product as my OpenID provider. I added code to the header section of http://www.aaronhockley.com so that I could give that out as my OpenID URL. When I made an OpenID claim using that URL, the code would redirect the request to Vidoop, where I would authenticate, and be redirected back to the relying party. The sites that use OpenID record my aaronhockley.com address, but I authenticated using Vidoop’s secure system.

With Vidoop about to disappear, I needed a new OpenID provider. I chose VeriSign’s PIP system due to their support for two-factor authentication. After signing up for PIP, I updated the code on aaronhockley.com to point to VeriSign’s servers, and that’s the end of the story. I can continue to use aaronhockley.com as my OpenID URL even though my provider has changed, and all of my accounts across the web that are linked to that URL will still work without any disruption in service.

ReadWriteWeb, Movable Type, and Vidoop OpenID: Broken

Warning: user-focused “I just want this damn thing to work” rant ahead.

It’s no secret that I’m a big proponent of OpenID. Last year I took a stand that I would avoid participation on tech-focused blogs that didn’t support OpenID. Shortly thereafter, I discovered that I couldn’t sign into ReadWriteWeb using my Vidoop OpenID.

I contacted Vidoop, and was told:

I’ve done some more troubleshooting with our friends at ReadWriteWeb, the issue is that they aren’t configured to handle “https” (SSL) connections, and we don’t allow OpenID associations with websites who don’t use SSL to verify with us.

This makes sense to me. The main reason I use Vidoop is because of their excellent security and the fact they require a SSL connection is a good thing. I then contacted Richard at ReadWriteWeb; he bounced the issue to his Movable Type consultant, who responded with this:

I have forwarded this on to Byrne at Six Apart. This seems like something that should be supported natively by MT’s OpenID auth module. I will share any feedback that comes back from 6A.

That was in March 2008. It’s now February 2009, and I’m still receiving “An error occurred: The sign-in attempt was not successful; please try again.” when attempting to log in to what should be an easy authentication system for end users.

Why is this so hard? What’s going on?