Try these links, which go into much more detail, answering the "why bother" questions.
Note that BrowserID was the old working name for the project.
We've been live for several months now in the Real World - our userbase (amateur athletes) is primarily nontechnical. About half of our users choose Persona/BrowserID and half choose Facebook. We were initially concerned about the BID login flow (in particular, the immediate email roundtrip) but it hasn't been a problem and the UX has been refined quite a lot over the last month or two.
For a mass-consumer audience, the combined FB/Persona solution is excellent:
* Facebook unquestionably has the slickest auth experience, even eliminating the followup name/sex/bday questions. However, a significant percentage of the world (possibly > 25%) either Hates Facebook or wants to keep their Facebook account isolated. This is unlikely to change in the near future and could even get worse depending on what sleeping dogs Zuckerberg decides to kick next week. We don't have the option of alienating the FB haters and we wouldn't want to anyways.
* The Persona UX is good and rapidly getting better. BigTent integration with gmail, yahoo, hotmail will bring one-click login to those users. A native experience is being built into browser chrome. All this is coming without me having to write code. It may not be as slick as Facebook, but I like where this train is headed.
* Integration is simple compared to writing a username/password system. The API is incredibly easy to work with. Dual-auth with Facebook is a little more complicated, but a complete Persona-based auth system is a question of hours, not days.
* The fact that identity is just an email address makes it easier to integrate with existing login systems. In our system, you can log into the same account with both Facebook and Persona as long as the emails match. No, email is not a perfect identifier, but even nontechnical users understand it immediately and really - what other option is there? "What email address did I use?" is a lot better than "What weird combination of letters and numbers did I use as a login name?"
* Support on the Mozilla dev-identity list has been fantastic.
We're pretty happy. Honestly, I don't ever see myself writing another username/password login system ever again. Persona is less work for a better UX.
I'm using Chrome. Don't know if that affects things. Anyway.
Hit Browser ID, asks me for my email address. OK fine, add that in. It then says (quickly, and temporarily as it's an AJAX load), that it's looking up my email provider (Google Apps). It then asks me for my password.
So now I'm totally confused. I've not signed up with your site or BID before, so I dont know if it wants my GAPPS password or a new password. I don't feel like I want to put in my GApps password, as there is no Google branding anywhere and the URL is not Google.
So I try putting in my GAPPS password, because I use 2 factor, and it doesn't work. Most likely because I use 2 factor, and I can't authenticate with just my standard GAPPS password.
So it failed. I guess I'm an edge case as most people don't enable 2-factor on their Google account, but I was still really confused when it asked for my email password.
Same thing happened with Firefox version whatever the latest one is.
I'd say it's completely confusing, all in all.
Not sure why you're confused.
"Website operators still get a verified email address for their users, and users only have to remember a single password. BrowserID is also intuitive, since email addresses are commonly understood to be associated with identities."
Mozilla is really stressing the "email address/single password" concept. If they really mean "email address/separate dedicated Persona password" then they should make this clear.
In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider. If your email address isn't supported, Persona asks you to create a single new password at login.persona.org. You can then add many other unsupported addresses, without needing more passwords. So it's an "at most one new password" system.
> In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider.
I don't know what this means. I won't give Persona my gmail/yahoo-mail email password.
You can try out the supported email provider workflow by signing up for a dummy account at eyedee.me, and then using that account to sign in at, say, 123done.org.
"Sign in with your email address" gets the point across. "Sign in with your user identity at a controlling DNS authority" may be more accurate, but will actually confuse everyone.
It asks you to create a password. (admittedly it could be a clearer what you are creating a password for, i.e. persona.org)
If your email address isn't known to Persona it will ask you to create a password, which is cool. Otherwise, it will just bring up a password box with your email address just above it.
I must have used BrowserID once when it was launched, because what the OP got happened to me and I was just as confused. It might not be a problem in the future when it's more well known, but it would be nice for it to have an indication that they want your Persona password, and not your email password.
I'm positively surprised to see that you found a 50-50 balance between BrowserID and Facebook; I expected a lower pickup rate on BrowserID. So, I guess I've decided what login system to use for my project(s).
Thanks for the information.
"a significant percentage of the world (possibly > 25%) either Hates Facebook or wants to keep their Facebook account isolated."
And some people don't even have a Facebook account. Around 6 billion people, last time I heard :)
There's also some work on integrating existing e-mail providers, so you can get instant identities:
This is probably the web-thing I'm most excited about today, even though the development is kinda slow. I really want to implement it as a sole identity provider on my websites some day.
EDIT: I also began writing a Safari extension that would work like the mockup above, but gave up halfway since it was too convoluted and totally insecure... maybe I should try writing a SIMBL plugin or something like that.
But even with the current implementation it is possible to validate the assertion in your server without contacting browserid.org, but AFAIK nobody did it yet.
(I tried to find a reference for that, but they took it down from their Wiki. It used to say "You may choose to validate assertions on your own server": https://github.com/mozilla/browserid/wiki/How-to-Use-Browser... - the verification code is still online, though)
Faaborg's mockups are awesome, but they're well over a year old and not really guiding our current work. Still, definitely take a look at them, if nothing else than for the cool way of doing mockups!
You can definitely do your own verification without having us in the loop, but we'd urge you to hold off until this fall; the IETF is still standardizing some of the data formats we're using, so the exact serialization of keys and assertions might change between now and then. By using our verifier, you're certain to be up to date.
The easiest way to verify-it-yourself is to just run our code locally; it's all open source, after all :) https://github.com/mozilla/browserid
(PS: The docs are now on MDN, instead of the GitHub wiki: https://developer.mozilla.org/en/BrowserID )
Ballmer had both the plans and source code for an identity product that would have been 10x more advanced than Facebook, but they decided to axe the project so they could make the Zune instead.
ANYONE can make an identity product that is 10x more advanced than Facebook.
The problem is making an identity product that is 10x SIMPLER than Facebook, without relying on a single source of identity verification.
Every company and every account I sign up for I give a different email address. I'm not about to use a single one for my ID. Especially when they are easy to spoof (any one can send mail as email@example.com) and they are easy to spam and abuse. I had an email address that got 3000 spams a day. That's why I never give use email as ID because I want to be able to disable any email address that's giving me trouble.
So, not interested in BrowserID I think. Or maybe I didn't grok it.
My understanding of Browser ID is that it's a way to provide an email address to a site operator that doesn't need to be confirmed. It's a single-step subscribe/account creation, rather than an authentication per se.
In the mockmyid case, you are saying "I own the address firstname.lastname@example.org". But the MockMyID server will happily let anyone make such an assertion, so you get a simple kind of mock identity.
Of course, you shouldn't use that as your identity on any sites that you care about. Mail to email@example.com doesn't go anywhere, and there's nothing to prevent other people from using the same @mockmyid.com address. But it's a neat example of the sort of thing that is possible.
That's mostly right. The BrowserID protocol gives you a way to say to a site "Hi, I'm firstname.lastname@example.org, 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 email@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.
This seems much more one sided -- it's good for the user that doesn't use FB or Twitter but 'meh' for the website. I'm not sure we'll see fast adoption like we have for OAuth.
We also let you reach many, many more people, since you're not forcing users into joining an anointed social network. Everyone has an email address, and people understand what it means to reveal it.
Also, there's no lock-in, because we're not giving you an opaque, one-way identifier for your users. Instead, you always get a verified email address. Want to switch away from Persona? Add a 'password' column to your database and send a few emails.
Edit: I should also note that we're really, really easy to implement. Like, roll-your-own-integration in less than 3 hours with zero previous experience easy. I want to see us become the de facto auth solution for weekend projects, but we're also a really nice option to put alongside your social login. If you're already offering Twitter and Facebook, why not provide a vendor-neutral option, too?
Would you tell the user to "just enter all email addresses you ever registered" and then send confirmation emails to all of them? I'd imagine this ending with one or two confirmed email addresses and maybe 3 additional unconfirmed ones.
When the user then tries to use one of the unconfirmed addresses to sign in — what do you do? Refuse log in because the address is not confirmed? Send another confirmation email to that account and ask the user to confirm it? List those confirmed addresses in the account and ask the user if he wants to sign in with one of them?
Is there at least a way to change the email addredd associated with an account? I can't see anything about that.
If you're using an email provider with native support for Persona, the only password you have is with your email provider.
Assuming by "we" and "us" you mean Mozilla? Or do you also mean the other major browsers?
Why did you write it like that? Why not just say "Persona" instead of "we" and "us"? Surely Persona is much bigger than Mozilla or do you not think so?
Firstly, that kind of language does not inspire trust. It sounds very much "us" vs "them", instead of addressing the real problem, which is helping users by creating and managing more secure passwords.
Secondly, your marketing to users includes:
"Many sign-in systems carry your profile data with them; some even share that info with other sites and social networks. We believe you should control how your personal information is shared."
You seem to want to attract publishers and yet you show your distrust of them to users.
Also, from experience in Public Web Apps, and the fact that it's still not possible for a user to give raw and pure TCP, UDP or POSIX power to Web Apps (and WebSockets and IndexedDB are not at all the same), I don't think the issue is so much that the user has power, as it is that the browser should have power. As it is today, the user is given very little power at all by the browser. Very little trust. Most spec discussions seem to constantly worry about users shooting themselves in the foot, and are prepared to stop at that, rather than finding ways to empower users to give power to web apps.
At the moment, however, and Persona is a good example of this, the browser approach to innovation is very much top-down with high-level APIs like UndoManager, WebRTC, IndexedDB rather than bottom-up with low-level APIs like UDP, TCP and POSIX which would trust the developer community to do the rest. Browsers are just not very programmable when compared to platforms like mobile and native.
For example, if the user would be allowed by the browser to empower a web app with raw POSIX, then that would unleash an explosion of databases running in the browser, orders of magnitude better and faster than IndexedDB.
Sadly, this kind of innovation is currently locked up tight inside the various spec committees. For sure, developers can contribute to the mailing lists, but innovation should not be made to go through that kind of process at all in the first place. Innovation on the web needs to be decentralized not centralized. Ideally, Mozilla needs to start making that possible, by providing just the right OS-level APIs and a simple way for users to grant these to Web Apps.
It must be 1984 that one can use a browser, but not be allowed to give raw TCP or UDP or POSIX annointing to web apps that one trusts.
See Tim Berners-Lee on the subject: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
In an ideal situation, both your browser (eg: Firefox) and your email provider (eg: Gmail) would support Persona. In that case, you don't have to click on any links to prove your email address, you don't have to create a new password, you don't have to trust Mozilla's servers to store a hashed version of your password correctly. The log-in dialog itself with be part of the browser chrome, training users to trust the browser and not the website, which is a good thing.
If your browser or your email provider don't support Persona, then Mozilla have provided fallbacks, which require you to click a link in an email and to create a new Persona-specific password.
It always takes me 5 minutes to integrate, doesn't require me to write any sort of "forgot password" functionality, doesn't require me to worry about storing passwords, and it's generally very easy to work with.
One problem is that users don't know if they're supposed to sign up or sign in, and that a Persona works for other sites, but I think this can be ameliorated with good copy.
I think Persona really needs to sort that out, it's completely non obvious.
Plus, twitter and facebook won't be here forever and may be a fad. Imagine if people used their myspace handle to login to their bank account today. And facebook accounts get disabled/hacked much more often than, say, gmail. E-mail is much more signup-and-forget and nobody considers giving their email address a privacy violation.
I see lots of complaints here about the technical aspects of browserid, yet i believe it's the most pragmatic approach one can take to rid the web from the dreaded password plague.
What really sucks about all solutions is that once the data has leaked, you gotta trust the service providers not to sell or give your data away.
Can't do that with all digital data, but you could with e.g. email addresses, cc's, addresses, maybe phone numbers.
Same with credit cards: my bank offers a free service where I can set up as many virtual CCs as I want. Until recently they were single payment only, but now you can choose if it's single or multiple.
Forwarding (physical) address exist too, 'though they seem to be mainly targeted at people outside the US who want a address there, and they cost you an extra shipping fee, of course.
I know a password reset function that uses only email is basically the same level of trust in the email provider, and I'm no fan of email based password reset, but this feels even worse -- literally abdicating your security entirely into your email providers hands? Gmail is great because it's free, but I didn't join gmail with the idea of giving them the keys to my life.
Another thing I don't fully grok yet is the 'issued-by' concept. Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly?
Finally, in a native implementation, how is the keyring persisted on disk kept safe from malware extracting your private keys? If the browser can decrypt the keyring, so can malware.
Ok I lied, one more thing... 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?! Then of course the next question is, how do you tell your browser you are walking away (akin to logout) and is it going to expire all sessions that were tied to your identity when that happens? So much to worry about...
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.
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!
As to XSS, the assertion that's transmitted to a site is scoped to that specific site, and is only valid for, iirc, 2 minutes. So replay attacks are severely constrained. Plus, the only meaningful data they contain is the user's email address, so phishing doesn't get you much of value or put the user at risk.
Saying, 'oh your account can only be logged into by attackers for 2 minutes if they can XSS the RP' is beyond disappointing, it's borderline negligent.
However, I'm not arguing against that a lot of people probably _are_ already logged into Facebook.
There are websites that have chosen Persona as an authentication method. We now need to see the following two pieces implemented:
- It needs to be implemented in the browser's GUI, like in this old screenshot . People will be able to see the usability and security benefits of having a standardised way to log in that's built-in into the browser. Could we at least have a Firefox extension or a nightly build of Firefox that does this?
- At least one email provider needs to be a Persona "ID provider", which would eliminate the need to create a Persona password and to click on a link in an email. My guess is that getting Gmail to support this would be slow work, why not try persuading smaller email providers like Fastmail to be the first to openly support Persona?
Fortunately, Persona does work even without these two pieces, using fall-back servers and a shim. But most of the benefits of Persona are only valid once the browser and the email provider deliberately support it.
 - https://news.ycombinator.com/item?id=2764824
 - http://i50.tinypic.com/2ptyv80.jpg
Native support should be coming in Firefox 17, albeit off-by-default. Native support will be enabled on phones running Boot2Gecko, which ship in Q1 next year.
• The name "Persona" is odd considering something by the same name already exists in Mozilla-land, a fact they seem to be aware of.
• I hope sites use this instead of forcing Facebook login!!
Would Twitter be the same if it was for short text messages? Or are Tweets so different that they deserve their own name?
The term chosen was "background theme", since a background image is essentially all that they are.
"Skin" was also under consideration.
Correct me if I'm wrong, but BrowserID/Persona assumes that for a firstname.lastname@example.org identifier there is a corresponding https://example.org. That's not true for most of the domains I support. In many cases, example.org doesn't even resolve to to an IP address and web servers are only run on subdomains (and not all subdomains have HTTP servers). Does BrowserID/Persona support a DNS mechanism to discover the location of the required HTTPS web server, similar to an MX record?
The opposite problem is where a user has a single email account with multiple valid addresses at multiple domains, such as email@example.com, firstname.lastname@example.org, email@example.com, etc. I work for an organization approaching a million users where this is the case and isn't going to change anytime soon. Once again, you can't assume there is an identity provider running on a web server at all of these domains. Is there a DNS-based method of discovery to solve this problem?
Does BrowserID/Persona allow users to authenticate against the same system they use when accessing email? If so, why does the OpenPhoto example ask for a password? I thought the whole point was that users avoid sharing credentials with sites. That implementation is very confusing and looks like a scary phishing attack.
Finally, it's not very clear what I should expect in the way of connections from other computers, whether I'm running an identity provider or not. This is crucial information to avoid tripping an intrusion detection system (IDS) during unexpected connections, especially from my own users.
Most sites nowadays log you in right after account creation and just wait for email-verification later. Is that even possible with Persona?
OpenPhoto is still using our old API, which can't handle post-verification redirects. Our new API does this automatically. Grab a mailinator account and try signing in to http://123done.org.
As for creating a Persona account, we're trying to fix that, too. Next month we'll be turning on a feature (codenamed "bigtent") that verifies Gmail, Hotmail, and Yahoo users by sending them through their respective provider's OpenID or Oauth endpoints. No more new account creation. No more email verification loop. Just three clicks and you're done.
Many more users are going to have Facebook logins already, and it provides social information that may be useful to your app.
(Hoping to hear answers other than the dev-centric 'I don't like facebook')
You can additionally just ask for the users email address.
Any one building a serious business using facebook auth does one of the above.
us3r-1D@facebook.com - that's helpful :)
I'm simply not trusting facebook under any circumstances. I'm in the minority, I know. But, if you want my money, or my time, on your web app (and maybe you don't; maybe you want people who have low desire for privacy or security, since they're probably more likely to click on ads), you're gonna have to offer something other than facebook for logging in.
Often the comments we want to write on websites have absolutely no business being concurrently posted back to FB. People like contributing without disclosing or offering their FB identities or sharing every micro-activity. And fair enough.
Not everyone is comfortable with fronting up to an unfamiliar website and saying "hi, I'm John Smith. Here's my comment about religious persecution in South Asia. And don't forget to Like me on Facebook. Sign up now to connect and share with the people in you life"...
In other words, the less clunky FB social plugin mess on websites the better. I hope Persona goes well.
You should use both, to maximize the convenience of your users.
Some are always signed into Facebook, and like to just use that, others want other methods that offer different models of security and openness, Persona is the best of those I would argue (OpenID is nice too, but the lack of native browser integration is what makes it less impressive than Persona).
There's more to Persona than liberating you from your password column.
Nevertheless, there are still huge classes of applications that don't benefit from social features, but do want the improved experience that Persona can offer. Think banks, universities, corporations, and governments.
So even in the absolute worst case versus Facebook Connect, we still have enormous potential for alleviating the pain of per-site passwords and containing the damage from security breaches in day to day life.
Now I'm wondering whether to use Persona or build it myself from scratch.
You can contact me through Github or through the project's issue tracker.
Could somebody do a quick summary for me? I would appreciate it very much.
As an analogy, we work really similarlu to showing a bouncer your ID. The ID has identifying information on it, and it has features that allow you to know that it's authentic and hasn't been tampered with. The bouncer can learn how to validate IDs issued by many different authorities, and can remember this when he sees other IDs from that same authority.
Our IDs are personal public/private keypairs, signed by the email provider.
So, quick and dirty, here's how we work:
I want to log in to 123done.org as firstname.lastname@example.org, but to do that, I need an ID with eyedee.me's digital signature on it. So in a popup, my browser sends me over to eyedee.me to ask for that signature.
Before eyedee.me will sign a public key with my name on it, I have to prove that I really am who I say I am. It's just between the two of us, so I can prove my identity however eyedee.me wants. It could be a password, an RSA keyfob, or entering a code from a text message. Whatever it is, eyedee.me is happy that I am who I say I am, and they sign my key and hand it back.
I want to show this to 123done.org, but it's not enough for it to be valid, since we have to prevent malicious websites or phishers from copying it and masquerading as other people. For my ID to be a valid login token, I have to add two more things: what site I'm logging in to, and a timestamp so it expires soon after I hand it over. I then sign that with my private key.
I then take that whole bundle and hand it off to 123done.org.
123done verifies it by asking for eyedee.me's public key (which can be cached), and seeing if that matches the first signature on the ID. If it does, then 123done pulls out the validly signed public key, and checks if it matches the second signature on the ID. If that matches, then the whole package is valid, and 123done knows that I really am email@example.com.
Does that make sense? It really just revolves around a document with two signatures: An email provider's which says "This key is associated with this account," and a user's which says "I am associated with that key."
I made a Persona account just now. All I saw happening was that I clicked on a link in a confirmation email. Was there also communication between mozilla and my email provider? (I am with a small ISP who is serving my emails - I have my own domain, so my email address is sthg like firstname.lastname@example.org). What went on behind the curtains, if anything, and why did it work with my small provider right away?
That's the great thing about Persona: it works even when email providers don't support it. However, it works best when they do.
For me, the big question was about whether email providers supported key signing without having to click on an email. Now I see that both ways work the same.
^ adapted from this?
Want to use SSH keys for auth? Okay. You can do that.
Pull requests and new issues welcome :)
Voo.st, OpenPhoto.me, Crossword.TheTimes.co.uk, 5apps.com, Haskellers.com, etc. We're also working to get Persona working with some larger sites, but most of those are waiting to go live until after we formally announce API stability next month.
This buq with webfonts are reporter year ego and stili NGASF on Windows xp Firefox 13.01 its start on Firefox 4