• version 2.0 will require WordPress 2.2 or greater. This is not likely to change, as the previous version continues to work in earlier versions of WordPress.
• version 2.0 currently requires PHP5. This will change before the final release, with the minimum PHP version moving to either 4.3 or 4.4.
• jQuery is used for all comment form manipulation… this means that this particular feature requires javascript, but should work out of the box on tons more themes.
• the latest version is available in the subversion repository ‘trunk’. I’d love to get some feedback (keeping the above limitations in mind), but please to proceed with caution. Detailed feedback is needed and actual patches are certainly appreciated (though not required). My project page for the plugin had fallen horribly out of date, but I’ve updated the URLs to point to the current subversion repository and such.
• I’d like to have the plugin released around the same time as OpenID 2.0 being finalized (supposedly the first of October). Given how long it’s taken me to get back at it thus far, this seems realistic.

I’ll also note that I’ve made a project page for my MicroID plugin. The plugin has actually been around for quite some time, but somehow I missed making a page for it. This plugin builds on some ideas in existing MicroID plugins, but goes a bit further to support a number of additional features.

I’m a little confused by his use of microID in the comments. In addition to adding microIDs to the blog HEAD and posts, Richard’s plugin (which I have installed here) adds a microID to blog comments that is computed using the commenter’s email and webpage. I see two different use cases when it comes to microIDs and blog comments…

Verifying email/URL couplet

Richard quotes something Jeremie says on the microID homepage —

Blog comment systems can check the given email address against a MicroID from the entered home page link to help reduce link spamming and blatant spoofing.

So this means a blog could potentially use a microID to verify the authenticity of an email/url claimed by a commenter. That is, when I make a comment on someone’s blog, their comment filtering system would compute a microID using the email and URL I claimed, and would make an out-of-band call back to my blog and compare the microID that I have on my site there. If it matches, then the email and URL are “valid” so to speak, and we’re done. If it doesn’t match, then the email addresses used to compute each ID are obviously different.

However, I do disagree with Jeremie’s claim that this could help reduce blatant spoofing (Jeremie even mentions this himself in an FAQ). Nothing prevents me from entering someone else’s email address and URL into a comment box. When they compare microIDs, of course they will match. This simply verifies a valid email/url couplet, but does not verify that the person making the comment actually owns either of those items. Put simply, microID does not do authentication (which the webpage mentions). Use openID for that!

Attributing ownership

The second use case is that of attributing ownership of a given comment to the author of that comment (which I think is what Richard was going after with his plugin). A microID is basically an assertion of ownership with three distinct parts.

• The authority making the assertion — this is the actual webpage that the content is hosted on. If you have the ability to manipulate the content of a given website, then it is assumed that you have some kind of authority over that security domain (or at least a small portion of it). This authority is the URL used to compute the microID.
• The person who owns the content — in the microID world, people are identified by email address, and this email address is used to compute the microID.
• The content for which ownership is being asserted — this is not part of the microID itself, but rather is implied based on the placement of the ID. If I am asserting ownership of an entire website, then the microID should appear within the HEAD tag. If ownership is being asserted for a small portion of content (such as a specific blog comment), then class values are used.

Back to Richard’s plugin, the content is obviously the actual comment itself and the person is the commenter, but where I think his plugin goes astray is the authority. In this case, the authority is not the commenter’s URL, but rather the URL of where this comment is hosted (most likely the URL of the original blog post the comment was made on). This would allow the commenter to make a claim of ownership of that comment on a system such as claimID (although I believe claimID only supports page level claims right now… not sections of content like this. Speaking of which, how would you specify which portion of a webpage you were claiming ownership of? Maybe use an #anchor in the URL? The microID verifier would certainly have to know how to deal with that).

So all that to say, I think the following function:

function add_microid_on_comment($comment = '')
{
    $microid = microid_hash(get_comment_author_email(), get_comment_author_url());
    return "<div class='microid-$microid'>$comment</div>";
}

should instead be changed to

function add_microid_on_comment($comment = '')
{
    $microid = microid_hash(get_comment_author_email(), get_permalink());
    return "<div class='microid-$microid'>$comment</div>";
}

(Wasn’t trying to pick on Richard in this post… actually I really like his plugin and find it very useful. Explaining all this in this fashion actually helped clear it up in my head as well).