Because my mother doesn't give two shits about public/private key. She just wants to authenticate and the easiest way both logistically and mentally to do that is to just sign into her email.

I fully support this idea from Mozilla and I hope it kills OpenID, as even that's a pain in the ass sometimes.

Surely the real win here is the massive reduction in password re-use on 'less secure' environments.

Obviously google/microsoft etc are not immune to screwing up and having their database hacked - but I'd rather put all my eggs in that basket than having a single egg in lots of baskets with differing levels of security that subsequently enable access to all of my eggs anyway and...

Yeah. So the eggs metaphor doesn't really work. Sorry.

Your mom can treat keypair as just another password thing. With the nice exception that she would never have to type it, just click on "sign in as (name)" button and browser/GPG agent combo would do the rest.

I'd note there are tons of solutions involving key escrow, so synchronization and recovery are not problems.

My first thought is that completely depends on browser uptake. Persona/BrowserID works whether the browser supports it or not.

Because with browserID your email acts like a public key, and presumably the third party does a better job at securing your private key (with 2 factor auth, biometrics etc) than most people do on their own (the current password theft onslaught proves that). If this gets traction i m sure many hacker groups will come up with independent, noncommercial and nongovernmental authenticators.

We had that, it didn't work.

> Why involve the email operator?

We involved CAs.

CAs would not be required at all for a simple certificate-signing scheme that could be implemented in a similarly user-friendly way.

How would it work on other people's computers?

The same way it works with Mozilla Persona.

If they're not using their normal browser, they don't have any cert data stored, so they have to 'log in' the traditional way to Mozilla Persona, which then gives the browser the cert data. The whole thing hinges on caching login credentials.

The simplest way to support this without depending on a 3rd party (Mozilla) would be to use an e-mail reset to send you a temporary credential to log in from an "unsafe" computer. There would need to be lots of restrictions on its use of course.

Persona doesn't involve any hard dependency on Mozilla. The user can use another ID provider (or even run their own) and the site can verify the credentials without using Mozilla's webservice. Both are currently unlikely, but it's easy to imagine GMail being an ID provider in the future.

can i supply more than one so sites could check if one of the providers has been compromised or something similar? does it make sense to have more than one?

As I understand it, it checks with the domain from the 'email address' to verify you. (air quotes because it needn't be possible to send email to the identifier). So it wouldn't make sense to have more than one way to verify one ID. If the site you're signing into is particularly sensitive, it could require a separate check - perhaps even a second BrowserID login from a different domain.

Okay, replace my usage of 'Mozilla' with 'ID provider'. The point is we can do all of this without an 'ID provider' today.

E-mailing temporary credentials still effectively relies on an ID provider: your mail server, which must ensure that no-one else can read e-mail sent to your address. You can run both that and a BrowserID provider yourself if you don't trust someone else to do it.

BrowserID is much easier for the web developer to set up and for the user to log in with: no switching between tabs to copy and paste passwords from your e-mail.

I think part of it is that sites want email addresses for their users.

Making the email address part of the protocol lowers the bar for sites to join the ecosystem.

Good question. This was actually implemented in Firefox a while ago, I even remember actually finding it in use in the wild once. The key issue there is how do users manage their certificates? Their 'passwords' are now a set of certificates stored somewhere. These certs need to be accessible from their phone, their work computer, their home computer, the cyber cafe, their friend's computer, and so on.

I see two possible solutions to this. One is storing these certs in the cloud, the other is hard token like a flash drive. The problem with the physical token is that it can be lost, so it needs to be backed up somewhere. Where to back it up? The cloud seems the natural answer. How do you reliably authenticate this cloud cert storage system in a way that a person can't just lose or forget? And we're back to email.

Persona reduces all of these things down to the email account. Assuming they did it right (I haven't gone into the details yet) then they're introducing no new attack vectors (someone with your email can own most of your accounts already) and they're eliminating the password from most places. Seems like a win to me.

So, we have two options:

1. Tie identity to email address. No means of backup (you just can't back up your email provider), no sensible migration possibilities, system is as vulnerable as your email account.

2. Tie identity to keypair. Let email provider (or other trusted third party) sign it, validating the email address. Then escrow the pair and allow recovery by passphrase and email validation, and/or put it on hardware token, and/or hide a piece of paper in a safe behind a cupboard. Simple means of migration (just authenticate with old key and new address), huge flexibility of choices between security and usability.

Both options may have the same default UI/UX and they share very similar workflow. Generate keypair, let the provider perform the email validation, get the signature, give it to the consumer. The only difference is what's finally tied to your account — your address or your public key.

Argh. Why am I so late to this thread?

This is possible. Your BrowserID provider can do public/private key auth. You could have an identity that is provided for (you could do this yourself on your own domain) that you authenticate to via a private key.

That's how flexible this protocol is. The provider has a huge range of discretion about how the account is authenticated.

The problem is, one can't own a domain, but only lease it for a time being. And one can't migrate between johnny@example.edu and john@example.org.

That's how inflexible this protocol is, compared with a simple keypair.