TallyHoh OpenID

I was going through my feeds this morning on Tallyhoh and I came across Adam Fortuna’s post on Problems with OpenID?. He was discussing a post done over at Factory City a site I hadn’t seen before. His article, Problems with OpenID on Highrise by Chris Messina, immediately made me switch into DHH mode. This article discusses issues he takes with how the open_id_authentication plugin works.

Normalization of Open ID

Chris talks about the decision made by DHH on how to normalize the identity. He claims:

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?

I would agree with him, if not for a simple Google search to see the draft 2.0 specification for open id, where they discuss proper normalization of a identity url. The other problem I have with this section of his article, is his claim that these 4 urls should be the same:

  • factoryjoe.com
  • http://www.factoryjoe.com
  • http://factoryjoe.com
  • http://factoryjoe.com/

I agree with one exception. The absence of a sub-domain is a domain in itself. Even though usually in the world wide web, people make this the same, I don’t think it should propagate over to open id.

My understand of the open_id_authentication plugin, is that it is suppose to handle the three cases with no sub-domain. However so far in my experience it is not adding the trailing space, if it is not there, which is no fun. Hopefully this will be fixed soon.

Lack of i-names

This article was the first I have heard of i-names, and I am sure they are extremly cool, and helpful. My issue with his complaint is that i-names were not added to the open id 2.0 specification, and it is still a draft. So I don’t believe it is worth spending time implementing something that might not end up in the final version. Especially a topic that has so much debate around it as i-names.

Double Delegation

Open Id allows for a wonderful process of delegation. This allows sites like Claim ID and MyOpenId to provide an open id service. Then you can append two meta tags on your own website to delegate the authentication to one of these service providers, but you can use your own domain, for instance.. http://danielroop.com as your open id.

This article brings up a problem that I was not aware of, that you could not delegate multiple times. According to his article ( I did no research of my own) the open id specification, does not allow for multiple delegations. They did this to not prevent an endless loop of calls. In this specific instance, his friend was using Claim ID as his service provider. Claim id, is kind enough to give a shorten versioned of their normal identity url. The problem lies in the implementaiton, and in this case, open id, did not do any magic on their side, they just did a delegation to the normal url. His friend apparently did not read the documentation on how to setup your own domain to use the claim id service. Because it states very clearly, to use the full http://openid.claimid.com/[username], it even goes as far to give you copy and paste code if you are logged in to the site.

I agree

I will wrap this article up by commenting on what I do appreciate about his article. First, I am happy to see people talking about Open ID. I am new to the game, but I think it is very promising . Second, I am glad someone is talking about 37 signals, in the negative. What they see as wrong. The rails community often takes a stance that 37 signals does no wrong, which this article did not. I also agree with his commentary on the sign-up process. I am very suprised that Highrise does not make you verify your openid before you use it. Tallyhoh addresses this issue, by not having a signup section for open id. You simply log in, if you have not logged in before, we request certain information be filled out, and then you continue as before. With this model, if they enter an inaccurate open id, the login will never be created.

In Conclusion

Even though I may come across like I don’t like this guy, it is quite the contrary. I do appreciate the questions and concerns he raised. And after reading over the article a couple times writing this post, I realized, that in the context of Highrise, he is right. I believe the way 37 signals chose to implement their openid lends to numerous problems, that could be fixed. That being said, GO OPENID!

This entry was posted in programming and tagged , . Bookmark the permalink.

3 Responses to TallyHoh OpenID

  1. Thanks for adding your comments, Daniel. I’m typically a fan of 37 Signals work, but in this case, I think they needed some additional guidance. I also consider the 37 Signals crew friends, so I wasn’t trying to sling mud, but simply offer feedback on my experience in the hopes that they improve their implementation, since many people look to them for inspiration.

    As well, I would encourage you to support OpenID on this blog with the wpopenid+ plugin. We have a long way to go, but every little bit counts!

  2. Adam Fortuna says:

    I’d have to agree about the normalization. I wouldn’t mind a standard for test.com, http://test.com and http://test.com/; but the subdomain is another story. The www subdomain is just a waste in most cases anyway.

  3. danielroop says:

    Chris, I completely agree with you. I think the 37 signals guys have some rough edges to work out with highrise openid support, but atleast they are trying.

    Also I kept forgetting to install the OpenID plugin, so thanks for the kick in the butt. I just finished setting it up, I believe it is working.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>