I’ve talked with core team about this numerous times… in fact, I spoke at WordCamp Portland and Seattle these last two weeks and talked with Matt about it. For the most part, I actually agree with him that OpenID doesn’t necessarily belong in core, at least not yet.

There’s a lot of thought being given to how WordPress can serve as your “digital hub” on the web. Right now, Automattic is playing in that space in the form of BuddyPress. Now right now, BP allows you to create another social network silo. BP installations don’t talk to each other, and there’s no way to use your account on one BP network to login to a different BP network. I talked with Mark Jaquith this weekend about my desire to see this outward facing functionality. For that, I think OpenID becomes painfully obvious.

I would also like to see this OpenID plugin deployed on WordPress.com to replace the existing plugin. Currently, all WP.com blogs are OpenIDs, but you can’t login or leave comments using an external OpenID. And currently, almost no one uses the existing OpenID provider. Of course, I would argue that this is because they haven’t done a good job of promoting it or adding any new features like SReg or AX. Using my OpenID plugin would greatly enhance the OpenID provider functionality on WP.com, and it would allow people to use OpenID when leaving comments. Some of the changes that are included in 3.3 are actually steps toward cleaning up the plugin so that it is more suitable for deploying on WordPress.com. There’s still more work to be done on this front, but it’s something I intend to continue pursuing.

As for inclusion in WordPress core, I just don’t think we’re there yet. The OpenID plugin is pretty popular, but it is far from having the critical mass that would justify inclusion in core. I am a firm believer that WordPress should by no means try and include every cool feature under the sun in core. It would quickly grow out of control. I do believe, however, that the appropriate hooks should be provided in core to allow any cool feature under the sun to be added as a plugin. The core dev team agrees with me on this, and they’ve been very good about making whatever changes were necessary to allow plugins to provide that functionality. In fact, I overhauled how the authentication system is extended in WordPress 2.8 simply to make things like OpenID and OAuth much easier to implement.

A few other things I’d want to see fixed before considering inclusion in core… the OpenID plugin weighs in at what? almost 900K? Remove the screenshots and readme.txt and you’ve got 700K left. Over 500K of that is the JanRain OpenID library. So size is an issue. Also, the biggest problem that people have with getting the plugin to work is related to their environment. WordPress is known for having a very minimal set of requirements to get it running. I’d really want to track down and fix a lot of these weird environment issues that continue to plague the plugin. Finally, we need a really solid UI, both comment form integration and the admin side. I’m pretty happy with the new comment form integration, but the current admin screens need work. More than anything, there is just a lot of functionality in the plugin and it’s hard to boil it down. Especially when you consider both the OpenID consumer and provider options, both site-wide and per-user.

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.

• OpenID Provider - Specific user roles can be given the capability of using the built-in OpenID provider, turning their author posts URL into a valid OpenID which can be used to login to other sites. This includes support for OpenID 1.0 and 2.0 as well as Simple Registration 1.0, with hooks to add other OpenID extensions.
• OpenID Delegation - Users authorized to use the built-in provider can optionally choose to delegate their OpenID to another provider instead.
• EAUT Mapper - Support for the draft Email Address to URL Transformation protocol. If you use an email address at the domain of your WordPress blog, you can now use use that email address to login wherever EAUT is supported.
• Extensibility - the plugin now has a number of public functions and hooks that other plugins can use to integrate with or extend the OpenID plugin. These are all documented here.

It’s worth mentioning that pretty much all of the new features require that you also have the XRDS-Simple plugin installed. There are also a number of other changes in regards to simplifying and stabilizing the plugin, than can be read about here.

• Don’t use OpenID at all
• Use the local OpenID provider built in to the plugin
• Delegate to another OpenID

If a the local OpenID provider is used, it also supports transmitting sreg attributes pulled from the user’s WordPress profile and the DiSo Profiles plugin, if it’s installed. The user can update this data before releasing it to the relying party, but those changes aren’t currently stored. In addition, trust decisions are recorded and stored for the user, and can be modified from their config page at any time.

If a user chooses to delegate to another OpenID, they need only provide the delegate OpenID itself. All server configuration and supported extensions from that provider are discovered and published in the local XRDS document. Of course this data will have to be cached and probably updated on some interval, but it makes setting up delegation a breeze.

Server Modes

Remember that every user’s OpenID is their author posts URL. So what about the home URL for the blog itself? Well, the OpenID server can operate in two basic modes: multi-user and blog-owner… perhaps not the best names, but they’ll work for now.

In multi-user, the default configuration, the server supports a feature in OpenID 2.0 called OpenID Provider driven identifier selection. What this means is that ANY user on that blog can enter the home URL as their OpenID, and the OpenID provider itself will make sure that the correct identifier is returned to the relying party. The final identifier will still be something like http://example.com/author/admin/, but the user only needs to enter example.com at a relying party. If you’ve used ever used Yahoo’s OpenID provider, then you’ve probably seen how this works.

I suspect the more common mode will be blog-owner, which is appropriate for personal blogs. Even if there are multiple users in the system, the blog is basically owned by one individual and it makes sense for that individual to use the blog home URL as their OpenID. This mode is activated by selecting a “Blog Owner” on the main plugin configuration page. Once set, this user’s personal OpenID configuration (whether turned off, using the local provider, or delegated to another OpenID) will be used at the blog home URL. Other user’s on the blog could still use their OpenIDs, but they would need to type in the full URL each time… they just lose the convenience of being able to use the blog home URL.

For security, once a blog owner is set, no other user can update the setting. The blog owner can set someone else as the new blog owner (a push mechanism), but no-one can take ownership away (a pull mechanism). Additionally, if a multi-user blog wants to ensure no-one is ever set as the blog owner, they can add the following to their wp-config.php file:

define("OPENID_DISALLOW_OWNER", 1);

What’s left to do

The main outstanding work to be done before release is the user interface. You’ll notice that the user’s configuration screen (where they manage their external OpenIDs, OpenID Provider preference, and Trusted Sites) is a bit confusing if you’re not to familiar with OpenID. The current layout was done simply for convenience while developing the OpenID Provider, and will be overhauled to some degree before the release.

I’m also not too sure about compatibility with older versions of PHP and WordPress. I’ve been developing using PHP 5.2.6, MySQL 5.0.51, and WordPress 2.6.1. I do intend to remain as backwards compatible on these as possible (within reason), but make no guarantees for the current development code. I’ll also be working to make everything compatible with WordPressMU and BuddyPress. For now, I just wanted to get the code out there, and get people playing with it a little bit.

Simplified Database Structure

Version 1.0 of wp-openid added four new database tables and overloaded one of the comment table fields in a weird way. Version 2.0 required only three of those four tables and added one column to the comment table to eliminate the overloaded field. The current development version doesn’t add any columns or overload fields of existing tables, and adds only one new table of its own, which I’m still hoping to eliminate.

The two removed tables were used to store OpenID associations and nonces, both of which are temporary data necessary to make OpenID security actually work. Instead of using these tables, I’ve opted to use an updated version of the OpenID store used in Simon Willison’s mu-open-id plugin which uses the WordPress options table to store this data. I’ve updated his store to use the latest php-openid APIs as well as to reduce the potential for race conditions.

I’ve removed the column from the comments table that was tracking which comments were left using OpenIDs, and am instead storing this in the postmeta table for the post the comment is associated with. It would certainly be preferable to have a commentmeta table, but I like this better than the previous solution.

The one remaining table is the identity table which tracks the identity URLs of each user. I would like to store this in the usermeta table, but because it requires unique keys there’s just not a real clean way to do this and keep the plugin scalable to support large deployments. If this is fixed in 2.7, we could theoretically eliminate any custom database stuff in the plugin, which I’d absolutely love.

Removed PEAR_LOG

For the time being I’ve removed PEAR_LOG and am simply using error_log() for what logging still remains. The problem is that most people weren’t taking advantage of the logs anyway, so they were just taking up space. I’ll likely look at making use of the WP_DEBUG constant to allow more verbose logging when it’s desired. For now this just simplifies things a bit, and eliminates at least one case of library conflict that was reported.

Code Refactoring

Really? More refactoring? Didn’t I just do a lot of this in the last point release? Well yes, but more was needed… MUCH more. Previously, code was roughly divided based on the MVC (model, view, controller) model into store.php, interface.php, and logic.php, respectively. That worked for a while, but got to be pretty confusing as those individual files became a bit unmanageable. Instead, things are now broken into more logical segments… comments, admin panel, logging in through wp-login.php, etc. This seems to be a lot easier to manage and more importantly, easier to extend.

More Hooks

I haven’t sat down to document them all yet, but I’m adding in more hooks for other plugins to add functionality. Want to pull profile data from FOAF instead of sreg? No problem, now you have a hook you can implement. This makes everything in the plugin much more lightweight and “loosely joined” which is always good. All of the existing non-core OpenID functionality (like SREG) is currently using these hooks.

Bug Fixes

Though I’m not always good about replying, I generally do monitor the conversations on the WordPress support forums. I will try and put together a more exhaustive list of what bugs have been addressed, but I will simply say for now that most of the major bugs people have reported there should be absent from the current development branch.

Here Be Dragons!

Let me say first and foremost, don’t use this on a production blog. I always say that when I blog about unreleased code, but this time it’s much more important. There are major database changes in this version… changes which are non-trivial to reverse. There is a very good chance there will be more database changes before the final release, and there will not be an upgrade path from this development version (there will however be an upgrade path from the last stable version… 2.2.x).

What’s New

For now, I’m just going to have two follow-up posts talking about changes in the coming release. I’m sure I’ll overlook something and may have to add a third post, but for now we’re looking at:

• Making the plugin more stable, extensible, and overall simpler
• OpenID Providing and Delegation

Test it Out

The current plugin can be checked out from the DiSo subversion repository; grab the 3.0 branch . In addition, it requires a special branch of the XRDS-Simple plugin to provide all the XRDS publishing stuff. If you have a previous version of wp-openid installed, you must deactivate and reactivate the plugin for the database changes to be applied. Again, keep in mind that these will be somewhat substantial changes to the OpenID portions of the database, so don’t do this on your production blog just yet. Please direct any support questions to the DiSo Mailing List.

• POST replay for comments - this should fix all the compatibility issues with other comment related plugins like reCaptcha.
• MUCH better memory usage - like no longer needlessly building a 2MB object on every page load!
• support for Email Address to URL Transformation - now you can use an email address anywhere you normally use an OpenID
• fixed OpenID Spoofing vulnerability - users’ profile URLs must match one of their OpenIDs
• using hooks for gathering user data - other plugins can now hook in and gather user info from FOAF, hCard, whatever
• If OpenID authentication fails for whatever reason, the user is given the opportunity to submit their comment without OpenID
• lots of little fixes, code refactoring and cleanup, and a lot of UI tweaks

Download at http://wordpress.org/extend/plugins/openid/.

I tested pretty thoroughly on WordPress 2.2 through 2.6 using PHP5. I’m fairly certain I didn’t break PHP4, but let me know if you find any problems.

With this out the door, I’ll be jumping right into my feature list for the next major release — adding a native OpenID Server and delegation capabilities. At that point, it should be able to handle all of your OpenID related needs.

Posting comments

OpenID is integrated into comment posting by intercepting a comment submission to see if it includes a valid OpenID. If it does, the user is sent to their OpenID provider to authenticate, and upon their return the comment is submitted. Previously, the wp-openid plugin itself performed the comment submission, basically by copying the logic found in wp-comments-post.php. This introduced a number of problems, especially when using any other plugins that modify the comment submission process such as reCaptcha. Violating DRY is bad, but necessary at times. Breaking other plugins is really bad and had to be fixed.

The current solution I’m using is to capture the comment submission POST, do the OpenID dance, and then replay the POST (modified if necessary). If the OpenID dance results in the commenter being authenticated as a valid WordPress user, then the comment POST is modified to look like they were logged in all along. If the OpenID dance results in user attributes (via attribute exchange, sreg, hcard, foaf, whatever), then those values override what was included in the original comment form. If OpenID authentication fails for whatever reason, the idea is to give the user the option to submit the post without OpenID. This part isn’t finish yet, but will be before the release. Currently, if OpenID authentication fails, then the comment is very likely lost unless you use other means to save the comment. And of course, if any other plugins include additional data in the original comment POST, it will be included in the replayed POST.

Still left to do

Because all of the OpenID responses are being sent to /openid_consumer, it’s not quite as simple to display friendly messages to the end user. I’m may try to find a way to display error messages similar to how they look today (for example, login errors are displayed on the wp-login.php page, etc). Otherwise, I’ll just have a somewhat generic error pages that is specific to OpenID errors, and then include links back to whatever the user was doing.

Need Testers

Right now, I’m in need of people to test this new version of the plugin to find any cases I may have overlooked. Like I said, the message display is in need of work, but everything is at least functional as best as I can tell. If you’re interested in testing, checkout a copy of the latest code from the Diso Repository and give it a shot. If you have an older version installed, you will most certainly need to disable it first, then re-enable after installing the new version. Otherwise, WordPress won’t handle the /openid_consumer endpoint properly. If you have any questions or comments, you can leave a comment here or on the Diso Mailing List. As always, I would strongly discourage you from using this on your production WordPress installation (notice I’m not using it here).

I’ve been working in the Identity Management space for a few years now. I started getting involved with the Shibboleth project while at the University of Memphis. After a year and a half, I moved to California and took a job at USC working in their middleware group. I’ve spent the last two years there helping to develop and manage various parts of the Identity Management cloud including the LDAP directories, meta-directory processes, and their Shibboleth environment. In October 2006 I formally joined the core Shibboleth development team, focusing on the Shibboleth 2.0 Identity Provider.

Meanwhile, I have also been toying with OpenID for a couple of years. In early 2007 or so, I sort of took over development of Alan Castonguay’s OpenID plugin for WordPress. I started with a couple of new features, then worked to add support for the latest OpenID protocol, lots of code refactoring, etc. I got to know characters like Chris Messina, Scott Kveton, and a host of others. I continued making updates to the WordPress plugin as I had time, but it never felt like enough. Don’t get me wrong, I certainly enjoyed the work I was doing at USC and with Shibboleth… I just would have liked to have had more time for everything else as well. Every now and then Chris or Scott would prod me about going to work at Google or somewhere to spend more time on OpenID and related technologies, but I wasn’t ready to leave my work at USC.

Late last year, Chris Messina and Steve Ivy announced the DiSo Project, initially based on my updated wp-openid plugin. Within the first week after it was announced, I sat down with Chris and Steve and we decided it would be best to officially move the wp-openid plugin under the DiSo umbrella to allow for tighter integration with the other planned work. Then a lot happened this last February in the social networking space — Google announced the Social Graph API and SGFoo really got people talking more about enriching the OpenID endpoint (among other things). Things were beginning to move pretty fast, and I felt like if I didn’t jump in now then I’d end up watching all the great new developments from the sidelines. I spent the next few months interviewing with a number of companies active in this space and made a couple of trips to San Francisco to talk with them in person.

In the end, a dinner conversation with Luke Sontag had me sold. I was quite familiar with Vidoop and their OpenID provider, knew they had a great development team, but had always been a little skeptical of the company. After Luke gave me a better picture of their overall vision and where technologies like DiSo fit into that picture, I knew that these guys really “get it”. They understand the importance of what DiSo is trying to do, and more importantly they are willing to do their part in making it a reality. I love Vidoop’s OpenID implementation and have been using it since before I took this job, but that’s not why I did. I took the job because the team at Vidoop know their shit, they know the kinds of problems we’re up against, and they are ready to take a shot at developing some real solutions. Well that and I really can’t wait to get started working with Chris a lot more. :)