This lets users sign in with an existing email address, so they don't need any new sevice or identifier to remember. It's decentralized; Mozilla has a service for web developers for convenience, but any site can implement the protocol itself instead (or use another provider). And it's designed to let browsers handle the login flow in the future, simplifying login and account creation for end-users.

Most of the oauth services I used allowed me to create an account with ... an e-mail and a password.

Literally the same thing, here.

Isn't one of the advantages of this system is that your password doesn't get stored by the website? Just some type of token? If their database gets stolen or leaked, they shouldn't be able to hash attack your password and gain access to it since it's not there.

I'm just assuming it works this way, as passing the password along would defeat the security of the system and make you more vulnerable.

You still have to enter your e-mail and a password into the BrowserID popup; and with OAuth, the sites using it didn't store your password either.

I literally don't see a major difference here, except that now we're using email instead of whatever bullshit identifier you could have used with other OAuth providers (e.g., your Livejournal username, your Facebook account, etc., etc.)

If I'm wrong, I would love to be enlightened.

browserid.org ("the BrowserID popup") is just a way to bootstrap the system. The idea is that browsers and email providers will support this protocol and browserid.org will be totally unneccessary.

The major difference is it's totally irrelevant to the site (relying party) what provider you're using. The site doesn't need a login page with a facebook button, a twitter button, a livejournal button, etc., it just needs a "sign in" button.

It's a step forward. There were security issues. Some sites used "name" as the user identifier, because obviously nobody on Facebook shares the same name (sarcasm).

Even email isn't safe, unless all the OAuth providers validate the email. Does Twitter allow me to change my email address to "president@whitehouse.com", and then return that to OAuth consumers as my email? I don't know.

There's too many things ways to shoot yourself (or someone else) in the foot.

It actually is decentralized, in the sense that anyone can implement a BrowserID provider.

Anyone can, but from the looks of it, a site chooses to trust one at a time.

There are two separate things here. Using the terminology from http://lloyd.io/how-browserid-works , you have:

1. Primary Identity Authority. This is a host (i.e. the one in your email address) that supports BrowserId. This is fully decentralized.

2. Implementation Provider/Secondary Identity Authority. For now the site has to choose one to trust, but once your browser has support it becomes the IP, and when your host becames a PIA there's no need for an SIA.

I'm wondering if it's at all possible to integrate this with OpenID, and how this interacts with previous Mozilla Identity projects to make your identity a part of the browser chrome. It all seems rather tangential to their other efforts, rather than coherent with.

I certainly hope it isn't possible to integrate this with OpenID. If it is, sites will just continue relying on OpenID, and treat this as a weird special case, rather than a superseding technology that gives the user control without requiring a third-party provider.