Normalization of OpenIDs URLs

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).

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

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 Begbiepointed out in the Highrise forum, to which DHHreplied, . 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.

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

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

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.

14 thoughts on “Problems with OpenID on Highrise”

Yes, the entire point of allowing someone to use OpenID is that they prove it’s their own – with math and redirects – with actual authentication at the provider.

And as for the limiting of the delegation to a single lookup – again, you’re correct. It’s because allowing multi-hop lookup would be very very hard to debug – and besides, whatever you can do with two hops, you can do with one (masking the real provider domain, protecting yourself from a private firm going under in the future, etc).

After further debugging, it seems that the MyOpenID problems were related to bad caches that the JanRan library were keeping. Iâ€™ve cleared those out and were able to log in with MyOpenID again. Weâ€™ll be following up with JanRan to find the root of these problems. And to get it working with xrds delegation.

That depends. I personally really like their work and think that they make excellent products. Their products aren’t for everyone, though, and they’re very direct about that. Sometimes this comes off as arrogance, but, at the same time, it’s hard to argue with their level of success.

I guess I worry less about how overrated they are and more about how much competition they have. If someone else wants to compete with them on quality, execution of commitment, I think we’d all be better off, including 37S.

So it’s not so much as they’re overrated, it’s just that they set the bar, just as Apple does, for what is considered “good”. It’s up to someone else to come along and reset those standards.

Another interesting quirk with Highrise and OpenID seems to be that I lose access to my authenticated RSS feed. All my RSS readers expect me to authenticate using a username/password pair, not an openID, effectively blocking me out of the Highrise RSS data.

I guess this is true for any site that has authenticated RSS feeds and OpenID logins.