A lot of questions here revolve around how this is different from OpenID and single sign-on solutions like Google Accounts or Facebook Connect. Here's a rough list (may be incomplete or inaccurate by now; while I work for Mozilla, I'm not involved in this project):

* federated (like OpenID)

* open standard (like OpenID)

* no passwords / no typing / no memorizing (e.g. like FB Connect)

* possibility of browsers providing an integrated experience (technically possible with previous solutions, but no browser has done this so far -- in the case of OpenID for a very good reason IMHO)

* anonymity/choice of identities (like OpenID, definitely unlike e.g. FB Connect)

* no exposure to identity provider (this is unlike any existing solutions; if you log into a site, your OpenID provide, Facebook, Google, etc. will know which site it was; not with BrowserID!)

Check out Dan and Ben giving a nice demo of the BrowserID user experience: http://www.youtube.com/watch?v=6x45Nt1fOMM. No passwords, no typing, and anonymity where desired.

If you're interested in the nitty gritty details, Lloyd explains the cryptographic assertions that actually let sites verify your identity: http://lloyd.io/how-browserid-works

(EDIT: format bullet points)

I'm pretty sure I understand how this works, but please correct me if I'm wrong.

As currently implemented, it appears that if the Primary Identity Authority or Secondary Identity Authority keys are compromised, then all accounts for which that authority is trusted are also compromised. This enables accounts to be compromised en masse, rather than individually. It would seem that by de-centralizing authentication, browserid centralizes security.

Ok, so revoke the compromised certificate. If you "trust" browserid.org and do assertion verification on your own servers, how are you notified of the compromise and key change? Conversely, if you offload assertion checking to browserid.org and they go down, will users really understand why they can't log in and your site is "broken"? You could use CRLs and OSCP, but now you have another thing to get wrong in individual sites' assertion verification implementations.

Another interesting side effect of PIA or SIA key compromise is that an attacker could now create accounts and impersonate users, not just access existing ones.

It would also appear that due to the omission of a nonce, assertions are vulnerable to replay within the validity window.

I think that authentication is broken, and commend attempts to fix it. I'm just not sure that all the added complexity of browserid really buys us anything, and instead enables new attacks that previously weren't feasible.

I like the idea of this, seems like a much better solution than Open ID, and I've never been a fan of sign in with Facebook/Twitter/Google/etc.

However I'm a little disappointed that they tell you to add it as a blocking (synchronous) JavaScript include in the head of your document.

I'm not seeing how BrowserID differs from the standard email verification sign up. I went through the sign up process (enter email, click link in verification email, enter password, sign in with password). I also read Mozilla's 'really short version' explaining browserid (https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol) and will give the longer version a shot.

Maybe I'm stupid, but the linked article gives me the idea that JavaScript is requirement to be enabled to allow log-in. Is this true?

I know, I know, it's 2011, but still I feel it's unnecessarily limiting.

This looks interesting, simple UX for user and simple to implement for developers. I'll give it a try in my next project.

For anyone interested in using BrowserID authentication from a Node.js app, Passport (which I developed) has a BrowserID module: https://github.com/jaredhanson/passport-browserid

Just drop in a few lines of code and you have single sign-on.

Why?

Firefox already stores passwords in a local database and it wouldn't be that hard to automatically log users into sites.

The method they describe here requires every web site be changed and requires cross-domain JavaScript to be enabled such that browserid.org will know which websites you visit. You _could_ place include.js on your local domain to avoid this issue. However history has shown that sites will tend to just cross-domain link to googleapis or yahooapis.

Additionally, this is yet another web authentication method that should probably be handled at a lower level in the stack -- either the HTTP protocol, transport layer (TLS) or perhaps in the future, by using IPSec.

Anything that means I won't have to use yet another password is a good thing.

However I fail to see how this is useful: no sites use it, because no users use it.

Let's not muddy the waters. Use openid. No excuses.

What does BrowserID do that every existing OpenID provider cannot? The BrowserID FAQ says the architecture is "decentralized", but login relies on Mozilla's browserid.org server.

I'm working on a webapp that will be used by not-so-tech-savvy working people and this could be an interesting way to subscribe to the service without implementing generic openid (i think most of them wont understand it) or facebook/twitter etc.. login (it's a service for businessman). I must check if it's more difficult to implement than an all-internal email subscription and verification process.

Maybe I do not understand the system well enough, but isn't there too much room for fake accounts? The web site implementing BrowserID must trust the browser or the 3rd party validation service that the user really owns the specified email, right? Wouldn't it be super-easy for a hacker to simply return bogus values from navigator.id.getVerifiedEmail() when that gets implemented in browsers? (more specifically, what is the verification procedure of the "Primary Identity Authorities" and what stops a hacker to create a fake one?)

I am all for simple log-in procedures, but as a web site owner, I want to be really sure, the email at least exists to prevent a bit of spam or low-quality content.

It would be interesting for this to get some exposure from a large web-service. Being realistic, Facebook nor Google would be interested in replacing their own system. But I think it is an interesting idea which now is no longer just theory.

>Include the BrowserID include.js library in your site by adding the following script tag to your pages <head> tag <script src="https://browserid.org/include.js type="text/javascript"></script>

Not minified. Come on Mozilla, you did the same thing with the (rather large) Open Web Apps library. Minification is required. You are Mozilla, you should know this. YUI Compressor takes a few seconds at most.

>>> Error encountered trying to complete registration. >>> Thank you for signing up with BrowserID.

Quite a bit too experimental for me to register I'm afraid

Why has this been developed? I would have like to have seen a way for clients to generated client-based SSL certificates and submitting them to a server for signing automatically. This would be little new technology and proven cryptographically.

Does BrowserID addresses in any way authorization? Is it compatible with OAuth2?

Hmm.. so if my browser has integrated support, then any site I visit can add itself to my list of primarity authorities as evil-username@evil-domain. And I will be asked to choose one of these authorities to log in to other sites. And a rogue authority can impersonate me on the sites where I use it. Is this correct?

I can see a slight potential to trick the user into using a rogue authority. Imagine the evil email address is somehow tailored to a site the user is expected to log in to, in a way that makes it look like the "right" selection for that site, in the BrowserID dialog. I can't think of an explicit example right now, but when you allow untrusted parties to inject text into trusted dialogs, there are often many possibilities for trickery.

For an even simpler alternative to BrowserID see: http://dswi.net/

Another third party validation service? Thank you, no.

I was hopeful about this protocol, but now I'm kind of disappointed. It uses email and is built into the browser, so why does it require JavaScript on the user side and a complicated verification server on the server side? I was a hoping for something simpler.