Turns out that 37 Signals’ implementation of OpenID could use some… getting real.
Let me go over these issues and provide either resources or remedies.
Normalization of OpenIDs URLs
Look at these three URLs and make a note to yourself about any differences you see:
To a lay person (or even your average geek), these URLs all represent the same thing — especially if you type any of them into the address bar, they’ll land you on my out-of-date homepage.
But, in the land of OpenID and URI evaluation, these differences can be very significant, especially when you get into the differences between OpenID v1.1 and the forthcoming v2.0 (which adds support for inames).
To the contrary of some discussion on the OpenID list, the way in which you normalize an identity URL very quickly becomes a usability issue if the cause of OpenID login failures are not immediately obvious.
Remedy: Given some of the issues folks have had with OpenID at Highrise, DHH decided to make usability the priority:
I’m going to fix the trailing slash issue on URL-based OpenIDs. We’ll be more liberal in what we take.
This should mean that folks logging in with OpenID shouldn’t have to guess at what their appropriate identity URL looks like, instead only substantively know what the important parts are (i.e. the domain and any sub-domain or path(s)).
Outstanding issues: Of course, 37 Signals can do this, but what happens when the identity URL that someone uses on Highrise doesn’t work elsewhere because other consumers aren’t as liberal with what they accept?
Lack of support for i-names
One of the issues (features?) that OpenID v2.0 brings is the support for i-names, a controversial schema for representing people, businesses and groups using non-familiar formatting codes.
I’ve heard that there’s somewhere in the ballpark of 20,000 i-names users in the wild (I happen to have =chris.messina but never use it), but compared with the over 70 million (and growing) URL-based OpenID users, this is an incredibly small minority of the overall OpenID landscape.
Nevertheless, one potential point of frustration for these users is in the lack of standardization in implementing or indicating support for i-names, as Rod Begbie pointed out in the Highrise forum, to which DHH replied, . We don’t support iname OpenIDs for now, though. We’re just supporting OpenID 1.1.
And this, I imagine, is going to be a common issue, for both OpenID implementors (dealing with support requests for support of i-names) and for i-names users, such that I question, as others have, the wisdom of offering support for i-names identifiers, when issues still clearly remain in the usability of basic URLs.
Remedy: Once the OpenID v2.0 spec has been finalized, there will need to be a new logo to indicate which version of OpenID a consuming site supports; this will hopefully work to set expectations for i-names users.
Outstanding issues: At the same time, the addition of i-names to OpenID v2.0 has caused a lot of concern for folks, many of whom have simply decided to stick with v1.1.
Personally, I don’t see the long term value in fragmenting the OpenID protocol away from more familiar URL-based identifiers. I want something simple, straightforward and obvious. Otherwise, v2.0 is going to be a headache to advocate, to implement and to support that a lot of folks with just stick with v1.1.
Double delegation aka the Sean Coon Problem
My buddy Sean Coon pinged me the other day to see if I could help him debug the problems he was having signing into Highrise with his OpenID account. When he had signed up, he had used seancoon.org as his OpenID URL. He’d started playing with it, but then left it, only to return later, unable to login.
His problem was three-fold, but I’ll first address a basic issue with delegation that some folks might not be familiar with.
As it turned out, Sean had delegated seancoon.org to resolve to ClaimID as his identity provider. The problem was that he used http://claimid.com/spcoon as his identity URL instead of http://openid.claimid.com/spcoon, which is where his OpenID was actually stored.
Typically when people use claimid.com/[username] as their OpenID identity URL to login to sites, this transformation takes place invisibly. This is because ClaimID delegates to themselves.
The problem lies in that Sean delegated seancoon.org to his ClaimID profile, which in turn was delegated to ClaimID’s OpenID server. If this sounds confusing, it is, and that’s why it’s not allowed in OpenID.
As I understand it, delegation can only be done once, or else you might end up in an infinite chain of delegations that may end in some grandious infinite loop. By restricting your delegation hops to one, a lot of problems are avoided.
Remedy: In this case, Sean only needs to re-delegate to openid.claimid.com/spcoon, and fortunately, there’s a handy WordPress plugin that can handle this for him.
Outstanding issues: Delegation is probably one of the coolest aspects of OpenID, since it allows you to use any URL of your choosing as your OpenID and then let someone else deal with the harder part of actually talking to all your services. Furthermore, you can delegate any number of services and set up fallbacks in case your primary identity provider is taking a nap. Communicating how this works and how to resolve and communicate errors when things go wrong is one of the biggest holes in the OpenID offering, and with user experience experts like 37 Signals joining up, I hope that these issues get the amount of due diligence and attention that they deserve.
Untested assumptions
Finally, I discovered a serious mistaken assumption in the Highrise sign-up process. To test out this issue, I created a test account, using http://google.com as my OpenID:
Now, here’s the problem: they didn’t force me to login to that OpenID when I signed up; instead they just assumed that I knew what I was doing and that I was using a valid OpenID.
So here’s the email that I got confirming my account. Note my username:
Of course when I go to login, I can’t, and I’m locked out of my account — since I can’t login and prove that I own google.com — which, notably, is the same result as if I’d mistyped my OpenID. Fortunately, 37 Signals gave me a backdoor, but it kind of defeats the whole purpose of using OpenID and suggests that you shouldn’t let folks arbitrary set their OpenIDs without having them prove that they really have control of their stated identifier.
Remedy: For implementors, you must get proof that someone controls or owns an OpenID if you’re going to rely on it as their primary identifier. You can’t assume that they’ve typed it correctly or even that they’ve even used a proper OpenID. And, most importantly, you’ve got to stress test such a new system to make sure issues like this are avoided.
Oh, and it does appear that MyOpenID.com OpenIDs are totally not working at this time; I’ve put Scott Kveton and Jason Fried in touch, so hopefully they can resolve the matter. Interestingly, if you’ve delegated to more than one identity provider and you’re using your own OpenID URL to login to Highrise, you should be able to get in.
Conclusion
It’s still promising to see folks like 37 Signals get on board with OpenID, but we clearly have a long way to go.
I hope I’ve clarified a few of the current issues that people might be seeing, or that are generally confusing about OpenID, and I admit that while I’m trying to clarify these things, a lot of this will still sound like Greek to most folks.
Given that, if you’re having issues getting OpenID, feel free to drop me a note and I’ll see if I can’t help resolve it.
Factory Joe 