WordPress OpenID v3.3

I’ve finally gone ahead and released version 3.3 of the WordPress OpenID plugin. This release includes three major sets of changes. First, it drops support for older versions of WordPress… the minimum required version is now 2.8. Trying to maintain backwards compatibility requires a non-trivial amount of effort, and I’d rather spend that time working on new features. It also cleans up the code a fair bit, which I always like. It also drops support for two experimental OpenID extensions known as EAUT and IDIB. EAUT is effectively being replaced by WebFinger, and IDIB never got too much traction. Either could still be added pretty simply by another plugin if people still want them.

Second, this release features a new user interface for the integrating OpenID into the WordPress comment form. Instead of simply advertising OpenID support on the “Website” field, and always attempting OpenID authentication, the plugin now detects OpenID support for a URL, and gives the user the option to authenticate the comment. This provides a cleaner, less obtrusive interface that should work on most all themes. It also gives the user the option to not authentication that particular comment if they don’t want (particularly useful if you’re on a mobile device or in a hurry and don’t want to mess with OpenID). Feel free to try it out on this post if want. You really don’t even have to submit the comment to see it in action… just enter a valid OpenID URL for the website field, and move focus somewhere else (ie, click in the comment box like you’re going to type a comment). There is currently no option to revert to the old style of comment form integration, so hopefully folks will like this new UI. If you really don’t like it, you always have the option of turning off comment form integration and modifying your theme to your heart’s content.

Finally, this release includes a lot of minor bug fixes that people have been complaining about (sorry it took so long). I’m sure I didn’t get to all of them, so please let me know what I missed, and I’ll try to do more regular minor releases with these smaller fixes.

I’ll additionally note that working on WordPress plugins is no longer part of my day job, so I currently work on them rather sporadically as I have time. The changes in this release have been developed a few hours at a time over the last couple of months. I’ve been running trunk here on my site for quite some time and haven’t had problems, but you never know. Please use the DiSo issue tracker to report any new bugs, or to remind me of existing tickets that are still not fixed in this release.

iTunes 9, now with more WebKit

As John Gruber predicted yesterday, iTunes 9 certainly uses WebKit much more than the last version. I used wireshark to do a packet trace when I clicked on the Rock Music section. Sure enough, if you gunzip the response, it is effectively standard HTML (though they do declare a custom XML namespace for everything). It looks like this new HTML based format is triggered by the request header:

X-Apple-Store-Front: 143441-1,5

For example, the following simple curl command will retrieve this Rock page:

curl -H "X-Apple-Store-Front: 143441-1,5" \

http://ax.itunes.apple.com/WebObjects/MZStore.woa/wa/viewGrouping?id=24

To further verify that iTunes was doing little more than rendering the result with WebKit, I went through the response HTML, fixed a couple of URLs, and got this result — exactly what you see in iTunes 9. Of course, the “Quick View” for each album doesn’t work, but you can see how it is all pieced together.

A New Kind of OpenID Proxy

After writing last weeks post on directed identity, I really got to thinking on the topic a little more. One of the things that has always bothered me about the prospect of sites requiring the use of directed identity, is that it means I can no longer use my self-hosted OpenID to login. Currently, I have the WordPress OpenID plugin installed, and I use it as my sole OpenID provider. While the plugin does support identifier select (mainly for blogs which have multiple authors), it does not support directed identity. But even if it did, it wouldn’t make much sense… an OpenID URL of the form “http://willnorris.com/openid/9eb4d59c1d488a4” doesn’t do a very good job of masking who it belongs to. No matter how opaque the path, the URL is still rooted at the authority “willnorris.com” which means it can belong to only one person — me.

So what am I to do? The most obvious answer is to simply use one of the larger hosted OpenID providers that support such a feature, like Google. But I have some real problems with that, both philosophically and practically. Fortunately, I think I may also have a better solution.

Continue reading →

Directed Identity vs Identifier Select

I initially started writing this post a couple months ago in response to the common misuse of the term “directed identity” I was seeing in the OpenID community. After reading Dirk Balfanz’s guest post “Users vs. Identity Providers in OpenID” on Eran Hammer-Lahav’s blog, I decided it was important to get this posted. I think some people who are relatively new to certain identity concepts genuinely misunderstand what is meant by “directed identity”, while others know the difference but are simply loose with the term. In how it is most often used in the OpenID community, the exact distinction between “directed identity” and other related concepts is not terribly important for now. But as we start seeing OpenID used in higher value transactions, and where higher degrees of privacy are required, not understanding the difference can lead to great confusion.

Continue reading →