Introducing Mozilla Persona, An Identity System for the Web

Nor did I, but as you acknowledged, that sort of control has entered the status quo. Anyone who can break into your email account can trivially reset your password on many sites, at which point, per-site passwords just become another liability. We get rid of those, and empower you to independently decide who to trust with your identity.

> Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly?

The idea of a secondary (or fallback) isn't central to the BrowserID protocol; it's just a convenience so that we can actually bootstrap a fully decentralized system. In practice, all libraries trust Mozilla's fallback Identity Provider by default. As email providers add native support for the BrowserID protocol less and less traffic passes through our fallback until it simply and automatically drops out of existence.

> If the browser can decrypt the keyring, so can malware.

Yep, that's true. Same with your password manager, though we are trying to mitigate this by making the certificate itself relatively short-lived. To wit, each client has its own ephemeral keypair with certificates that expire regularly, requiring a silent renewal with the Identity Provider. This creates an opportunity for the Identity Provider to refuse to renew a certificate, should one of your machines become compromised.

> Is there a password prompt when you first sit down at the native BrowserID implementation? Or does it just assume that your browser means its you sitting there?!

If you have a valid, unexpired certificate available, you'll be able to log in to things straight away. If not, you'll need to authenticate with your identity provider to get a fresh cert. Native clients are, of course, free to implement additional security measures before allowing access to the keystore.

That's mostly right. The BrowserID protocol gives you a way to say to a site "Hi, I'm someone@mockmyid.com, and here's the proof." That proof is, in part, a certificate that has been cryptographically signed by the user's email provider.

Now, to verify that, instead of asking the user for a password, or emailing them a confirmation link, you just have to check the cryptographic signature on the certificate. So in this case, you'd go request mockmyid.com's public key at https://mockmyid.com/.well-known/browserid, verify the signature, and if it all checks out, you can let the user into your site!

As for being a "single-step subscribe/account creation", you're spot on. Since there aren't any per-site passwords anymore, there's no difference in the flow for a returning user and a brand new user, since they both say "Hi, I'm name@example.com, and here's the proof." If that user exists in your database, great! log em' in. If not? Yay! You have a new user. Ask them for any additional information you might need.

Most sites nowadays log you in right after account creation and just wait for email-verification later. Is that even possible with Persona?

At least in the case of password resets, it's the site deciding they want "email" to be the weakest link, and many sites will require at least a little bit more (like secret questions) after a reset. In this scheme, email is by definition the weakest link.

The secondaries can never go away, unless sites are willing to straight up refuse customers based on their email address. There is an extremely long tail of corporate email servers out there, and those corporate employees are our users. I guess we just gracefully degrade back to standard usernames and passwords?

So the certa expire AND the key-pair is ephemeral, so if the user doesn't stay logged into their email account, they are going to get login prompts every 6 hours. If you use multiple emails, that means constantly cycling through your various gmail accounts every time the certs expire.

I think you need to allow flushing the key pair manually or else you're saying there really is no way to "Log out" with this. Worse, a user will click 'Log out' on their site, but the cert is still active so anyone can walk up / pick up the device and log right back in. So what we've been taught "make sure you log out and then quit the browser" wouldn't actually apply anymore.

Last thing for the night... If a site falls victim to a XSS vulnerability, does this mean an attacker can call id.get() and steal a users assertion, send it to themselves, and login as a user of my site by replaying the assertion? This is like stepping back to IE5 where cookies couldn't be HttpOnly!

Is there at least a way to change the email addredd associated with an account? I can't see anything about that.