Why Mozilla Persona is the right answer to the question of Identity

I love Persona. I want a Persona shirt and tattoo. OpenID was just a bit harder, but had nowhere near the payout that using Persona offers. The only burden of Persona is the auto-login/logout handling, which is a good thing in the long-run but in the short-run involves tracking down all your login/logout methods and making sure they all react properly.

*OAuth integration is a nasty mess of nastiness that I can't bring up w/o derailing this entire conversation. If you want to chat about that train-wreck, email me.

Once a user's source authenticity is verified, we give the option to merge accounts once we detect overlaps. So if you login via Twitter, verify your Yahoo! email address through the profile, and then login through Yahoo!, you'll be in the same account as you were in the 1st login. We have ~20 scenarios that we maintain for logins, and have heard 0 complaints on the assumptions we have in practice.

Thanks for the screenshot - we'll get that fixed today. Would you like an email once it is resolved?

Teaches me to try and get Yahoo! to behave with https. If anyone wants a great example of why to use Persona, try using Yahoo's developer apps interface...

I think the "built by a nonprofit" is a fantastic point that they should keep pushing, though.

1) Forced all users in your system, who already had email/password based accounts, to abandon their existing accounts and adopt Persona

2) Became fluent in quickly explaining to users how to reset their Persona password when they forget it

3) Don't mind losing all the users who say "I trust you, but not this company I haven't heard of before." Some users, especially jobseekers, won't let their circle of trust grow - and forcing adoption of a 3rd party causes abandonment. But so does a complicated sign-in process, so you just need to figure out if group A or group B is larger because you can't make everyone happy.

CardSpace was a Microsoft project led by Kim Cameron, the godfather of digital identity. They originally wanted to make it part of Windows Vista, but it was dropped for lack of interest. It was an open standard, and there were browser plugins to make it work in other browsers and operating systems. Microsoft knew they couldn't make it a Windows-only thing if they wanted people adopting it. They just wanted to be at the forefront of security for once.

A developer would add meta tags to a site's login page with a URL to post identity info to and a list of information it's requesting. That would trigger the browser (or plugin) to open a modal display of identity "cards", which the user could choose from. Then it would show what information the site requested and they could deny individual pieces of info. The data would be posted back to the site, along with a unique signature for that user & site.

Cards could be self-issued or issued by a third party, like your employer or bank. They could have graphical backgrounds applied so they looked more like ID cards or credit cards. It was a great UI for identity, and easy for developers to use. But I think the Microsoft name tarnished it. I know people outside the identity community were making comments about how this was Microsoft's attempt to become Big Brother & so forth, even though Microsoft was completely out of the communication loop between the user and the site.

Why? It might not become ubiquitous if they big players don't support it, but it could become the alternative that all the other sites use and makes their lives easier.

I don't see a network effect here that means only one method will win and all the others lose.

I think most people understand Wallpapers (Backgrounds) / Themes.

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.

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

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.

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

I knew I liked BrowserID and you've pointed out around reason why.

A hope, which has been dashed time and time again by bitter reality. It seems the only people lazier about password security than the actual end users, is the site owners ...

You are given the choice of which email address you want to use to log in. Isn't that exactly what you want?

Providing anonymized addresses is harder, since your IdP wouldn't be contacted until after the user has selected an address. In that case, you'd want a browser extension that generated addresses conforming to some scheme @youridp.com and automatically filled or selected them in the dialog when using Persona. Totally doable, but that part requires getting out in front of the call to navigator.id.request.

Multiple accounts is a good idea because it creates separate security domains which cannot be broken. You crack my Facebook password, there's no way you can get into my completely separate Citibank account. The one-login-for-all model is less secure because it centralizes your accounts into one general security domain: the ID provider.

If you hadn't made it a requirement that you can use the computer at your friend's house, this would be more secure, because you could keep your private keys just on your trusted devices. But now you're on a foreign device and you didn't bring your keys - so you have to either get them from your ID provider, or generate new ones.

Now an attacker can either A. break into the ID provider and steal the keys for all the sites you use, or B. intercept the username/password login to your ID provider.

The risk of A. is of course possible, plausible, and given the track record of companies with the highest security reputations in the land being pwnd by lame phishing expeditions, likely to actually work (eventually).

If you were using your home computer with the keys already stored in the browser, B. would be impossible, but you're at a friend's house with no keys. And my guess is there will be malware developed just to disable browser keys, force a u/p login, collect the creds, and try all online banks using this system to find your account and siphon funds. (This is exactly what malware does today, only they usually use direct injection of your normal banking browser sessions or steal saved logins)

Of course you can use separate accounts with Persona. They advertise you using a work e-mail and personal e-mail to make separate accounts. But let's be realistic: who the hell wants to complicate their logins further? People will probably use one e-mail for all their accounts - because it's easy.

I have a solution for these security concerns. It's to stop trying to making security easy. If you forced people instead to jump through hoops for the one or two accounts which really need to be extra secure, they'll deal with it (once) and get on with their lives.

Banking is one example. You can step a user through generating and storing a client certificate, and then they never have to do it again until they use a new computer. If they need access from outside their home (WHICH IS A BAD IDEA, BUT ANYWAY,) they can use a temporary e-mailed login token which is only good for one session and requires things like login rate limits, additional identity verification, etc. We can do this today without any new technology.

Facebook, Twitter, etc aren't sensitive accounts and thus don't need ridiculous security - Persona would be fine for these. Crack my social media accounts, fine, but don't allow things like banks and e-mail accounts to be linked as well. It's like clipping blank checks to your house or office keys.

What would change tho is the login procedure. Where once the user saw a Persona login box, suddenly they will see a Gmail login box. That has the potential to be really confusing unless handled well, no?

I haven't thought it all through, but it feels like there's a weakness there that's just waiting to be exploited.