* Logo is ambiguous and looks like a generic button
* "Mozilla" in the name instantly steers away other browsers
We've implemented it on LinkUp (https://www.linkup.com/account/), love the technology, and REALLY hope the adoption of it takes off - but until I can explain it to a user in 2 sentences, it won't claim the throne.
I would urge mozilla to remove all branding from the popup. It's gonna get really confusing when 3rd party popups get into the game (would they call it Google browserID or "google's version of persona"?). Second, since websites are not getting any private information from mozilla, mozilla is barely relevant. Third, while mozilla's work is commendable, users don't need a link to learn about the protocol and that it's benevolently "built by a nonprofit", instead they trust that the target website knows what it's doing by showing that popup.
I think the "built by a nonprofit" is a fantastic point that they should keep pushing, though.
"Sign in with your email address"
At Voost (https://www.voo.st/) we have been using BrowserID since launch earlier this year. We just use this simple phrase and users "get it" right away. There's no need for complicated branding.
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.
#2 has not been a problem, as far as we can tell. If users forget their passwords, the reset-password process on the Persona login dialog works great - better than almost every other password-based website I've used. In the long run, passwords are only maintained by primary IdPs like Gmail, so this is even less of an issue.
#3 is totally dependent upon your audience. We definitely get pushback on Facebook auth - you can't run a FB-only login system without alienating a significant chunk of most audiences. Initially we tried to encourage FB auth by making BrowserID less obvious, but that just produced a lot of angry emails from people who didn't realize they had an alternative. Now that Persona and FB auth are on equal footings, we have yet to have anyone complain about the signup process. YMMV.
Facebook blew it. They could have been identity for the internet, but with all the privacy and spam problems users HATE logging in with Facebook connect. We tried it for a website and it just failed. There's huge resistance.
What's your experience with that? Implementing OpenID tends to not be very fun (whether as a consumer or as a provider), is Persona better?
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.
I'm curious how you deal with someone logging in with one system and then coming back and logging in with another. Do you have a way to merge accounts somehow?
Also, I clicked on yahoo and got this: http://www.evernote.com/shard/s178/sh/faba70e1-03e6-4448-81f...
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...
Persona doesn't sound that different from solutions that came before it. It sounds really similar to CardSpace, especially with how easily you can integrate it into a site. So why would Persona have a chance at succeeding where so many others have failed? Is it just a matter of timing, coming after some major password leaks, or are they hoping the Mozilla name will buy them support from the developer community?
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.
Also, are you sure it's not from gravatar? In my case, it's the same image as the google profile photo.
So I think it's very likely that it's just Gravatar, and all you need is an email address to pull that.
But i have to say unless Google/Yahoo/Facebook/Twitter support this it will whitehr and die. I suppose it depends if they are really watching what we login to with openid.
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.
no, I like this design, and I am guessing the reason only time crossword signed up is that google and yahoo like knowing which sites I have visited. Making me even more happy to move away
Technically, I think this is vastly superior to the currently available login solutions. But one of the things I never liked about centralised or even federated auth was all the links between accounts.
One thing I don't like: ideally, all a site should need to know is that I'm the same entity I claimed to be last time. I only want to be locally unique on the site, not a globally unique value which can be correlated between sites. Also, it should be my choice as to whether I disclose my email address to sites.
In practice, email addresses are usually required for signups, and it's easy enough to create throwaways. I can absolutely see why it was designed this way, but it would still be nicer if the protocol did not disclose more than it needed to.
In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites.
I thought a bit about making a mailinator-like IDP (i.e. a convenient way to hack around this). Unfortunately, I can't see a good way right now to get both these properties at the same time:
a) The IDP doesn't know what site (RP) the user is logging in to
b) The IDP can auto-generate a persistent unique id for each site (RP) (e.g: <type-4-uuid>@idp...)
I guess the degenerate case would be an IDP which signs <anything@idp...>. Not super useful, but OK for sites where you didn't really want to have a login anyway, I guess... true mailinator style, but for logins.
A few other points:
* Would also be good to have a privacy option to force the browser to generate a fresh keypair every time a new user certificate is requested; at least then we can only be tracked by identity and not so much by device over time as well.
* There is the obvious timing attack, where if the RP doesn't cache the IDP's public key, it may disclose what site the user is logging in to, to the IDP.
* Also, verifier.persona.org will know who is logging in where, if you use their JS (since you pass the assertion and the audience via REST).
* I am not 100% sure at this stage what stops a malicious user from simply asking the browser to perform an identity assertion and grabbing email (or clickjacking the user into doing it) when they already have a user cert; haven't looked at it in depth though.
It's still possible within the framework of Persona to fix this -- the browser / identity provider needs to support freshly-generated opaque "email addresses" for each new site that needs a login. This prevents tracking and spam problems, but will also require both providers and relying parties to downplay the 'email address' token in the UI, which I fear is far too much to ask.
It doesn't even ask for a password. I don't think it would be too much work to create a Persona service like 33mail.com, which provides your own domain for email and authentication. That way, you would enter "firstname.lastname@example.org", the site would send you there for auth, 33mail would reply that you are logged in to your account (if you were, obviously), and that'd be all.
Personas - Skins for the Firefox Web Browser
This is an issue that needs to be resolved.
"To sum it up:
* BrowserID renamed to Mozilla Persona
* Personas renamed to Background Themes
* Themes are now Complete Themes"
I think most people understand Wallpapers (Backgrounds) / Themes.
I fully support this idea from Mozilla and I hope it kills OpenID, as even that's a pain in the ass sometimes.
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.
> Why involve the email operator?
We involved CAs.
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.
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.
Making the email address part of the protocol lowers the bar for sites to join the ecosystem.
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.
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.
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.
That's how inflexible this protocol is, compared with a simple keypair.
True, the fact that URLs identify them confuses some people. However, http:// being usually superfluous, I don't see why roger.example.com is more confusing than email@example.com.
> Most sites would like at least an email address to be able to contact you, so will almost always require an additional step after logging in for the first time.
And openId provides an email if the site asks for it.
> OpenID is a jarring login process.
The difference is that the provider page is a full page rather than a popup?
> Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to.
So does mozilla persona as your identity provider is your browser ! I remember an opera unite app that acted as an openId provider. How is Persona different/better than that?
> oAuth is complicated for developers to implement [...] several versions of the protocol, [...]
That is true. And it will also be true of persona in two years when you will have to support firefox15 to 20, chrome 33 to 35, ie11, opera14, opera15, webkit-beta-nameless-browser, webkit-alpha-nameless-browser and others' own versions of persona
Because roger.example.com is not what most people's OpenID is. Google uses the same OpenID url for all accounts. If you have a Gmail account, your OpenID URL is: https://www.google.com/accounts/o8/id
How the hell can you not find that confusing?
I knew I liked BrowserID and you've pointed out around reason why.
>> Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to.
> So does mozilla persona as your identity provider is your browser !
Also, developers only have an assertion to send; that's really really simple and less likely to break in future releases. Easier signups are important especially for small web utilities that just need a unique identifier and not much private information to work.
Because "roger.example.com" is a webpage, whereas "firstname.lastname@example.org" is an addressbook entry. Very occasionally, "roger.example.com" is a blog or personal webpage and thus probably refers to a single person. Maybe.
Browser only auth doesn't get me all the way there. I can look at wrapping UIWebKit, or whatever, in my apps, but I bet I am just asking for some hurt. :-)
I think they may be a bit evil.
Will Mozilla provide native support or an extension? Or they feel like it would hurt if someone could implement a bad login page that still works if the browser has native support?
I think most people overemphasize the importance of the particular authentication scheme used and overlook the problems created by extreme centralization of stuff.
They have a working native support - http://www.soeren-hentzschel.at/mozilla/persona/2011/07/15/m... - and expect it to see it natively in probably ~17. Their biggest push is for WebKit to adopt a similar solution based off the same tech.
In BrowserID they do generate keypair, but then tie identity not to it, but to an email address, something user lends, but never actually possesses. Completely the same as with OpenID, where identity is tied to URI. Actually, the only change is URI scheme part: http/https to mailto — which is nice UX-wise, but that's about all the advantages.
OpenID was heavily criticized for that (remember all those "did I sign up with Google or Facebook?", URI changes/account rename issues, identity providers being temporarily down, and so on?), and now those who criticized OpenID are praising system that have most of the same problems.
I can only hope Persona would silently fail and never gain any significant popularity, so users won't have to struggle with another hype wave, to only lose their trust (if there's any left) in non-centralized identity systems.
Please, put your egos away and get this done for the sake of everyone who uses the web.
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 ...
- I don't want to give my email address to every site I use. It should be available to the site only if I approve their request.
- I use a unique email address for every site that needs one.
- What if I want to start using a new email address?
However, having said that, I do otherwise agree with you, I also don't want to give my email out to all of them, and when I do, it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard.
You are given the choice of which email address you want to use to log in. Isn't that exactly what you want?
- An independent Identity Provider (IdP) uses some means of identification for the user (two-factor, iris scan, whatever)
- The IdP provides an anonymized email address to each site that the user logs into.
I'll have to read the spec a bit more to see if that's possible...
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.
Isn't the whole point of Persona that... it's not? Or it doesn't have to at least? In fact, two of the main motivations of Persona are 1. decentralized identity provider (so you don't have to rely on Mozilla) and 2. that the identity provider should not know which websites you're using (so whoever you're relying on doesn't have to know you're looking at cat pictures)
Unfortunately, most people fuck up PKI and now we're relying on a third party (Mozilla) to authenticate all our logins.
You could also just implement client certificates without a third party. Issue your users a cert when they register or log in. This would be similarly "automatic" authentication without relying on Persona to be stable and secure 24/7. I wonder why they didn't just make a browser plug-in that simplifies using client certificates (without the expense of supporting a highly reliable 3rd-party site and extra code to make it work)
So the goal is basically: I have a computer at work, a computer at home, a computer in my pocket, and a computer I just borrowed to check something at a friend's house. I want to be able to go to the same random site on all four devices and have it recognize that I am the same person, without (1) remembering a special password for that site, or (2) trusting that site in any way.
So there are two ways to do that. One involves generating a certificate on one of my devices and somehow communicating it to the others without a central authority. The other involves a central authority that each device can communicate with.
The first way will be, let's say, extremely challenging to get working reliably across all devices and platforms in a way that average users can handle. So Mozilla went with an extremely flexible version of the second way. It goes like this: users remember a Username and URL, in the form Username@URL. They also remember a Password which is only shared with URL. When I want to identify myself to that random website on any of my four devices, Mozilla helps me get a verifiable statement from URL to send to the random website that I am Username@URL.
There are two things mixed in to make it more likely this will take off. First, users are already used to remembering Username@Url / Password credentials, so they don't have to learn anything new to identify this way. And second, because existing Username@Url identities are email addresses, Mozilla can offer an intermediate identification service based on the ability to receive email, until other identity servers come online.
TL;DR: By using an intermediate ID server and credentials that look like email addresses, Mozilla has created a path to cross-device, cross-platform user ID that solves the problems of user adoption, technical adoption, and independence -- it can be implemented in existing browsers, understood by existing users, and offers a clean transition to completely decentralized identification. Very cool.
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.
If you don't want to trust Mozilla, you don't have to.
No, wait, that was terrible!
One thing that I don't see is what happens if I sign up as a user now (with my GMail address) and then GMail later starts providing their own service, instead of the fallback. Do I lose my account on all the services I signed into?
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.
I trust Mozilla to have done a good job of this. If there's a weakness, it's not going to be anything so obvious that you can see it from my stumbling attempts to describe the protocol. If it sounds like there is, I'm probably describing it wrong. Have a look at the details here: http://lloyd.io/how-browserid-works
If Gmail suddenly started verifying instead of Persona for @gmail.com addresses, the web site would see the email address as exactly the same so should give access to the same account.
They would then start verifying that "assertion" using Gmail and not Persona. It would be verified and hence secure.
I just don't like the idea of all the passwords being centralized in one place and being so very easy to obtain by the US Government.
Stripe is doing this right, when you make a payment on a website you have no idea that you're using Stripe.
In any case, the brand is for marketing to developers right now -- once "Persona" becomes a thing in and of itself, this will be a nonissue.