Comments with OpenID

Readers who look at our blog itself (rather than one of the lovely sites that reprint our articles) may have noticed that you can now comment in either the usual WordPress way (Name/Email/Link) or by logging in with a social media profile from one of a large range of providers, including WordPress, Livejournal, Yahoo, Google and many more.

This uses the broadly-cooperative openID system. If you run a website that accepts reader contributions, you should allow comments with openid because it helps people to use their existing social media membership without you having to surrender any control to facebook, twitter, or anyone else (unless you choose to). You also don’t have to ask your readers to weaken their security settings like with disqus (which requires javascript and third-party cookies).

The comment form on our site is powered by the openid plugin, together with our co-op’s version of the comments-with-openid plugin which can be downloaded from our site. Please download them if you’d find them useful for your WordPress site. (I’d love to adopt the official comments-with-openid at because the previous maintainer doesn’t answer – anyone know how to do that? I’m surprised it’s not in the FAQ.)

Do you use some other platform? What tools have let you add openid logins to it? For example, Drupal has some openID support in its core distribution: what else is out there?

This entry was posted in Wordpress and Blogs. Bookmark the permalink.

16 Responses to Comments with OpenID

  1. It’d be great if everyone supported OpenID. And if everyone’s OpenID implementations actually worked: as a WordPress user I’ve recently been unable to use it to comment on Blogger blogs, for reasons I haven’t attempted to diagnose.

    Since you ask about implementations, there are OpenID modules for Apache, FWIW. OpenID authentication has been around for some time; making Apache an OpenID provider is more recent and I haven’t tried the latter myself.

  2. Hmmm, from the last comment it looks as if your implementation is sadly failing to pick up my name from my URL.

  3. mjr says:

    Sorry it’s not picking up your name. I think it has for some people on this site, so are you sure your wordpress knows your name and shares it with other sites?

  4. Anon says:

    Would you consider supporting BrowserID? Seems like a better standard going forward, which ties identity to the user’s browser and email rather than to their account with a third party.

  5. Anon says:

    (Also, could you please stop automatically treating the email “” as an indication of spam? Hence the sillier email address used for these comments.)

  6. Anon says:

    For MyOpenID, please default to https, not http.

  7. mjr says:

    @Anon – I’m not yet sure about BrowserID. It looks like it requires javascript and is tied to a single Mozilla website ( which both seem wrong and worse than OpenID to me. OpenID is not tied to a third party – you can change your OpenID delegation at any time. I feel that identity on the web is better tied to someone’s homepage than to their email address and browser: I have several emails and use at least three different browsers daily, but I’ve one homepage. Why do you think BrowserID is a better standard?

    I’m not sure yet why is being treated as spam – it’s not in any site-specific blocklists, but it might be flagged by the blogspam co-operative moderation network. I’ve switched on extra logging and I’ll test it in a minute. Also, I don’t usually publish anonymous comments here (see the comments policy link in the header), but I’ve made an exception in this case.

    I’ll change the myopenid default Real Soon Now. Thanks for the tip.

  8. Anon says:

    The end goal for BrowserID involves native browser support for authentication, using public-key crypto with the keys generated and stored by the browser. exists as a compatibility shim to make BrowserID universally available *before* browsers have native support for it; they really need to document that plan better on the site.

    (Also, you could implement BrowserID server-side without JavaScript; implements it client-side using JavaScript to avoid the need for specialized server-side code on each site adopting it, which greatly simplifies adoption.)

    OpenID requires a webpage supporting a specialized authentication protocol which websites don’t normally implement. You can’t use OpenID with an arbitrary homepage URL without either hosting an OpenID implementation yourself or delegating to a third-party authentication provider. More importantly, having a personal OpenID that doesn’t depend on a third-party account requires hosting a personal homepage, which not every Internet user has or needs. As a result, in practice, the vast majority of OpenID users rely on a third-party identity provider such as the dozen whose icons you show at the top of this form, and that seems unlikely to ever change.

    BrowserID specifically ties identity to an email address, which everyone with Internet access already has. People can easily obtain an email address in their own name and at their own domain, and use that as their BrowserID, *without* having to seek out additional support for a specialized protocol as in OpenID. Also, almost all sites already want an email address when signing up, so using BrowserID avoids the need to deal with other pieces of information. BrowserID supports changing that email address, so that you don’t get stuck with a pile of accounts using when you’ve migrated to BrowserID also pre-validates the email address, which means you don’t have to redo the usual email-a-link verification with every single site.

    You mentioned that you have three email addresses and only one homepage. That case actually works *better* with BrowserID, which offers you the choice of which email address you want to use to authenticate to any given site. So, you can easily maintain accounts for,, or, without needing to host three homepages or rely on third-party authentication providers.

    As for using multiple browsers, BrowserID supports migrating from to in-browser authentication without changing anything visible to sites, and browsers which support in-browser authentication will almost certainly support migrating or sharing identities between themselves.

    So, I personally prefer BrowserID because it gives me more control over my own identity, lets me maintain multiple identities as easily as having multiple email addresses, avoids tying my account with a site to an account I currently have with a third party (and may want to drop in the future), reduces the number of pieces of information I need to provide to sites to one, eliminates the per-site email verification, and provides a path leading to in-browser crypto-based authentication.

    Does that help answer your question?

  9. Anon says:

    Thanks for pointing at your comment policy. You might consider making it more visible by linking to it near the comment form. :)

    I do recognize that many anonymous comments represent drive-bys which may feel futile to respond to when you don’t know if someone will check back. In my case I always check back with the site for any possible responses, but I can understand that most people may not do that. Your site, your rules; I appreciate you allowing me to comment, though.

    Also, I wonder: if you don’t normally want to allow anonymous comments because you might want to follow up with people, why do you allow OpenID, which allows people to comment without providing any information you can easily use to track them down? Most OpenID providers won’t share contact information with your site unless the user wants them to, and an OpenID URL alone doesn’t provide enough information to contact someone or otherwise track them down. Consider providers like , which provides anonymous disposable OpenIDs. (By contrast, if someone logs in with BrowserID you know you have a working email address for them. :) )

  10. Daniel says:

    Ikiwiki gives OpenID support in the default configuration:

  11. mjr says:

    @Daniel – Thanks.

    @Anon – Sorry, I’m still not seeing any advantage and using email address instead of web page still seems like a step backwards. Firstly, a web page is something you can get whatever information its owner leaves there on-demand, whereas email autoreplies suck. Secondly, not everyone who uses the internet has email any more. That may seem strange to old fogies like us, but that’s the way it is. Finally, people can easily obtain a personal home page and delegate that identity to whoever works for them for now, changing it later.

    It’s interesting that you say you could implement BrowserID server-side without JavaScript. Maybe if I saw that code in something like python, perl or php, I’d have a better idea of how it works, but I only found javascript on and I don’t want to waste our JS guru’s time on something that looks like pain for no gain. If there’s native browser support, how can you trust that BrowserID means a valid email address?

    Anonymous disposable OpenIDs still work for what I need them for. I don’t think BrowserID is any better for it, nor why you’d “know you have a working email address for them”: what stops someone deleting their email address after commenting?

    These seem like fairly forseeable FAQs to me, but doesn’t answer them and there’s only “Is this article helpful? Yes / No” rather than any way to ask there. “Ask the community Support Forum” doesn’t let you ask about BrowserID. Sites like make me feel like I must be really stupid!

  12. Anon says:

    (Note: my original version of this post contained a variety of useful links to sites with more information on BrowserID, but I’ve had to turn those links into descriptions of how to find the content, to attempt to avoid triggering a false positive from the rather aggressive comment filtering.)

    As far as I can tell, Mozilla’s support site exists primarily for users, not for developers or anyone else who cares about implementation details. However, that entry does link to a blog post which provides more details.

    Also, the blog at posts quite a bit of useful information about BrowserID, including more of the long-term strategy I mentioned. In particular, they have a post “How BrowserID differs from OpenID”, dated July 16, 2011.

    Regarding the use of email addresses rather than URLs, take a look at the post “Privacy and BrowserID” (July 21, 2011) under the heading “A Model Users Already Understand”: “Most users already associate e-mail addresses with personas and understand, for example, the difference between their personal and professional e-mails. [...] Logging into an online project management website? Use your work e-mail. Logging into your spouse’s photo album? Use your personal e-mail. We don’t need to reinvent a mental model for users.”

    Regarding email verification, either your server or browserid-dot-org’s verifier takes care of verifying the cryptographic “assertion” that the user has a valid working email address. That applies even in the case of a native browser implementation. The assertion chains back to a key that the site can (and must) verify. The user can either have their email domain act as a primary Identity Provider (“IdP”), or rely on browserid-dot-org’s assertions on arbitrary email addresses which does the usual email-a-verification-link dance (but only once, not once per site).

    Regarding native implementation, the guide at mentions that you can either use the verifier at, or “You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others.”. That page links to the specification for validating assertions, and a reference server-side validator. (Still written in JavaScript using node.js, though; Mozilla rather likes JavaScript. :) )

  13. mjr says: lays out three key beliefs: 1. an email address is the right identifier; 2. identity providers should not be involved in the login transaction; 3. the login system should be integrated in the browser.

    I believe that two of those are wrong (a web page is the right identifier so that you can see something on-demand and identity providers should be involved in order to check things are current) and the third is reinventing a wheel (most browsers support HTTP authentication and some support certificate-based authentication – isn’t a third login method in one piece of software a bit confusing?). So I’m not sure that we’re going to agree on browserid being a good idea, even without the current implementation problems.

    Also a bit disappointing that doesn’t allow discussion.

  14. Anon says:

    What do you mean by “identity providers should be involved in order to check things are current”?

    I do understand that if you fundamentally disagree with using an email as an identifier, you probably won’t care much for BrowserID. It might help to note that BrowserID plans to offer the same kind of “optional additional information” that OpenID does, including a homepage URL; however, I think it makes more sense to make an email mandatory and a homepage optional, rather than the other way around, simply because far more people have emails than homepages, and because most sites using authentication want to know an email address but don’t care about a homepage. (Leaving aside the issue that most people using OpenID don’t provide a useful homepage in the process, just a random useless identity-provider URL.)

    Regarding reinventing the wheel, browsers have supported both HTTP authentication and certificate authentication for years, and almost no sites have adopted either one due to usability issues. Meanwhile, almost every site uses forms and cookies. Clearly browsers need to try a new approach. It’s OK to reinvent the wheel when attempting to actually make it round this time. :)

    Note that Mozilla plans to integrate all forms of authentication into the browser: BrowserID, OpenID, and standard usernames and passwords. Take a look at for a prototype extension that allows sites to integrate their authentication with the browser, to make it easier to log in, log out, and see what identity you currently use.

    I appreciate you taking the time to consider BrowserID. I personally hope to see it succeed and become universally available, but it sounds like you don’t plan to be one of the early adopters. :)

  15. mjr says:

    @Anon – I mean that it looks like BrowserID does the email verification shuffle once and then you can close the mailbox but keep on using BrowserID with no assurance that the email address still works. Maybe I’ve misread something.

    So far, it’s mainly Google and Yahoo that don’t give any sort of a homepage address for their users in the openID login process – although they often actually have pages for many of their users, including on Yahoo’s Flickr and Google’s Blogspot. Even the specific ID services like claimID and MyOpenID seem to provide useful homepages.

    There are usability issues with HTTP and certificate authentication so far, but they are completely fixable by Mozilla for their browsers. Thank you for sharing the link to the toolbar login control: I’d not seen that before and it seems OK but it doesn’t seem to integrate HTTP or cert auth. It’s still rather frustrating to see them promoting another half-arsed login method before making what they already have usable first, then seeing if BrowserID is still needed.

    No, I don’t plan to be one of the early adopters.

  16. Gouri says:

    Had it not been for Facebook, open ID would have been more popular by now.

Leave a Reply

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

* Copy this password:

* Type or paste password here:

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>