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.

@Simon – it’s nice to have something to anchor a food co-op to. Do housing co-op members do most of the food co-op work?

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 http://identity.mozilla.com/post/8841090082/sign-into-websites-directly-from-your-browser-toolbar 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.

My concern is that the funding for the Making Local Food Work project is finishing. So, who is going to support food co-ops in their start up stages now?

I was keen to go along to point people in the direction of Co-op Development Bodies in the South West. However, there may actually be plans in place to support start up food co-op groups. Could anyone who was there let me know any plans that were mentioned? Ta.

Brian, Co-operative Assistance Network Limited

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 identity.mozilla.org doesn’t allow discussion.

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 http://identity.mozilla.com/ 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 https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site mentions that you can either use the verifier at browserid.org/verify, 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. )

@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 browserid.org 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 https://support.mozilla.org/en-US/kb/what-browserid-and-how-does-it-work 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 support.mozilla.org make me feel like I must be really stupid!