I implemented persona for ASP.Net MVC3 and it was hands down the easiest login system I've ever built in my career. From a developer standpoint it's very intuitive, the documentation is great, and I loved it so much I open sourced my implementation.
Please give this a shot! I would only like them to keep more information on hand, like a first name, or an avatar so I don't pester my user with such requests.
I don't think you've actually implemented the protocol. Like most of the other examples I've looked at, you explicitly check every login attempt with the hard-coded mozilla verifier. This breaks two of the selling features of browserid:
1) Your identity provider doesn't know where/when you login because the relying party (the website) is supposed to cache the identity providers public key.
2) When identity providers start implementing browserid, it's not going to make any difference because you're not checking back with the identity providers website, as encoded in the assertion.
What you've implemented here is more like Microsoft Passport - a single point of failure through which all logins flow.
So, as a bootstrap mechanism the Persona service fails, because assuming people jump on the browserid bandwagon, we'll still be stuck using Persona because all the websites have implemented the protocol wrong (as in this case).
You're correct. This is _not_ a persona provider. It would be more correct to call it "Here's how you can use Persona in an MVC3 application."
---
>So, as a bootstrap mechanism the Persona service fails, because assuming people jump on the browserid bandwagon, we'll still be stuck using Persona because all the websites have implemented the protocol wrong (as in this case).
Please elaborate here. You can just switch out the provider (in my case Mozilla) for another one easy enough. You're not tied down to a particular implementation.
That's right, you're not a 'provider', you're a 'relying party' - but you are unconditionally relying on the bootstrap mozilla service. You're not supposed to swap that out and rely on some other service, you're supposed to look at the assertion provided by the browser (or the javascript shim right now, while we bootstrap). Who you verify the assertion with depends on the user's email address.
So, if tomorrow Google added support for browserid to Gmail, and jo@gmail.com tries to log in to your website, he would claim to be jo@gmail.com and pass you an assertion to that effect. You need to check that with Gmail. Of course, Gmail being popular you've probably already checked the assertion of many people claiming to have Gmail logins, so you already have the Gmail key cached, and can verify the assertion without any http requests to anywhere.
Right now, Gmail does NOT implement browserid, so the assertion which you receive will be that jo@gmail.com is vouched for by the mozilla browserid service, so you will end up checking the URL you've hard coded.
But if it's hard coded we can't proceed to the next stage, which is the distributed promise of browserid. AND, it puts lets less pressure on the likes of Gmail to implement browserid because no one will be checking gmail.com/.well-known/browserid.
Actually, the the verifier (verifier.login.persona.org) runs code that could be run on any server. It _does_ check Gmail for the well-known file first, and then, since not found, uses the fallback of login.persona.org.
As soon as Gmail (or any id provider) implements a well-known file, the verifier will immediately use that instead.
And the script that does all this _could_ be run on your own server. The only reason we don't quite yet tell people to do that is to be absolutely sure the verifier is correct in every step. It's harder to get everyone to upgrade their own server, so while in beta, we offer the verifier.
You are using marketing terms like "Persona is distributed. Today" (last weeks blog title) but it isn't, because every auth request flows through mozilla servers. You are also advertising that it is so simple, the entire website example is 70 lines of python (recent talk), but it isn't, because you aren't implementing browserid, you're delegating to the centralised mozilla server.
Advertising that it is distributed and simple does not accurately communicate the current state of the implementation. Look at the spec:
> This assertion is a Backed Identity Assertion, as defined above. We call it assertion here for simplicity, since the Relying Party typically need only pass this assertion to a verifier service without worrying about the specific semantics of the assertion string.
It does not say that the centralised mozilla verifier is temporary, but expected.
This all leads to people getting the wrong impression. As you say, it is hard to get people to update software on their servers, but they don't even know that they have to - because it's distributed, today, and simple - so they aren't going to be looking. Another group of people are going to look at the spec and implementations and think: what is the point of yet another login scheme which just pipes everything through mozilla?
This is not going to help the adoption of browserid.
Perhaps the marketing of "persona" to consumers should take a backseat. When I signed in to http://123done.org/ the pop up* showing "sign in with persona" confused me for a moment. For a moment, I thought.. "but I do not have a persona account"
If there is a way for users to just sign in with their email without telling them how it is done, I am sure there will be even less friction.
Of course, the persona architecture could still be marketed to developers for integration purposes. But for users, let it just be like magic.
PS: I did not see the Firebase implementation they spoke of. I am still told to make sure my password has 8 characters. https://www.firebase.com/signup/
The Persona branding is necessary because you aren't creating an account with the underlying website--you're creating an account with the persona.org fallback identity provider (that is, unless you're using a yahoo.com email or another Persona identity provider).
Think about it this way: suppose you create a persona.org account at site X, then visit site Y which also uses Persona for login. It would look like site Y recognized you, but how? Seems like an incoherent user experience.
You're losing 95% of users right there, including many techies. What's "Persona" vs "persona.org" vs "Persona identity provider" vs "persona.org fallback identity provider"
I don't think any site using OpenID has a 95% bounce rate because of it. Persona is the name of the magic, you need a way to tell it from OAuth and other sign-in mechanisms.
I get where you are coming from but I strongly thing you should test it.
So if for instance, the user enters his email and is using a persona identity provider, e.g Yahoo It could just give a message 'Sweet, why don't you login with Yahoo " or create an account.
If the user has a Persona account already, once the email is put, it could say "Perfect! You are logged in"
If the user is using persona for the first time and does not user an identity provider, it could just bring a persona form.
Of course, for each instance, you could have a tiny "powered by persona" somewhere. With a bit of thinking it can be refined.
I do not see any reason why a user will want to start thinking about what persona is. They will just use an alternative (Facebook). What persona should be aiming for should be to become "login with email" and not another 3-in-one brand called persona.
Well, I personally don't think they do imply the same thing from a user's perspective.
* Google, Facebook, Twitter, ... have become so well-known brands comparing to the new Persona. Normal users could quickly get a sense of what "Sign in with Google/Facebook/Twitter/..." means, but not "Sign in with Persona" means.
* Persona is not a social network while other mentioned brands are or provide a sense of social network. A user might perceive "signing in with <your-favourite-social-network-provider>" as an act of making the site a part of the network; while with Persona it's totally different.
It's not clear at all. It's not clear to me and I've been a web developer for 15 years!
- I go to this site that I've never been to before
- It asks me to sign in with my email address, but I've never been to the site before so assume it doesn't "know" my email address
- I think look for a "Create Account" button to set up my account
- Now I'm confused as there is not a button anywhere
- I think "Well, I can't just type my email address in because that has never, ever worked on the web"
And so confusion reigns. Without some sort of iconography explaining what email addresses are accepted a la OAuth most users are going to be completely stumped.
Hey, so any email address will work. If it's not a Persona identity provider, then you'll just get prompted to create an account with the persona.org fallback IdP. You can see this right now by trying to login using a gmail account vs a yahoo mail account.
I understand the premise now, but it took me a while to figure out how it worked. The problem is, what they really need to say is something like:
"You can put any email address in here. If Persona has seen you before you can just put in your password and you're set. If you put in an email address that we have an integration with (like Yahoo) then you're all set. If you put in an address that we dont know, we'll ask you to create an account and then you'll be signed in. We might well have seen you before, so maybe try your 'normal' email address but the chances are you won't know whether we know about you as this is all too new."
Because THAT is basically how it works (AFAICT) but obviously that's a lot of text and no one actually reads text on websites.
The problem is that no one knows WTF persona is. Like my Dad and my wife have no idea what it is. They are also REALLY nervous about just putting their email address and password for a separate account into a website they have never seen before, AND FOR GOOD REASON!
This is a total usability clusterfuck. You expect my Dad (who calls the entire internet "Google") to accept this and not get worried about it?
They need to put MASSIVE INTERNET BRAND LOGOS in that box. Like Facebook, Google, Yahoo, Apple. Brands like that. Brands that, you know, my Dad has actually heard of and might actually have an account with.
I can see they are going in that direction with the Yahoo announcement, and MASSIVE KUDOS to them for that, that's a big step. Bit right now the usability is fucked and will stay fucked until the Persona brand as as big as Apple's or Google's. So never.
There's a sleight-of-hand Amazon plays with their own sign-in box: they give you a single "email" box, and then two radio buttons -- "I'm new" and "I already have an account and here is my password" [with a password input below that option].
The clever thing is, the radio buttons are completely ignored -- if you have an account and the password matches, you get logged in; if you didn't put in a password, and the email isn't in their records, they bring you to the account creation flow. The radio buttons are just there to let users express a choice they expected to be able to make, and thereby keep them in flow.
A better Persona login box could just do the same thing, but without the password input box under the "I already have an account" option. In fact, since selecting an option is the last step of the flow, just have an email field with two buttons, "Sign Up" and "Log In". Both buttons do the same thing :)
A reasonable guess for "Sign in with your email" prompt is that you'd need to go through a typical account creation process using your email as a primary ID. In other words, the message looks like a synonym of "Create an account".
There gotta be more thought put into how to make people aware of Persona mechanism, because it is quite different from all existing sign-in options and it needs to be learned of explicitly.
After you click a button labeled sign in, the popup reads "[Your site] uses Persona instead of usernames to sign you in. To sign in with Persona, please enter your email address."
I'm not sure I can do better than that text -- do you have any suggestions?
Sure. How about adding "This does not require registration in advance." (Or "previous registration" or "a previous account" or whatever is clearest). The problem is users searching for "Create Account" instead of "Sign In" when there is no "Create Account".
Edit: Sorry, on review this post was tangential to the point to which you were responding (about why the email is needed). It was targeted more at the point about user confusion by the login process.
Regarding Firebase, they said that they "added support for Persona as one of the authentication mechanisms for their Simple Login service". Their main website must not be using this service or not enabled the particular authentication component?
This means the data you store in Firebase can be associated with a Persona user, and you can structure your security rules to enforce whatever read/write behavior makes sense for your app.
I have to say that I'm really loving Mozilla/Mozilla Research these days. Their heart is in the right place, and their research projects like Asm.js, Persona, Rust, and Firefox OS are very cool. They are what Google was in 2005.
Unlike Google in 2005, Mozilla is a non-profit actively working to protect user privacy & build a better web. Also, everything we build is open source :-)
Rust is perhaps the only thing that you listed with any real promise. It is bringing in some good ideas from other programming languages, and it does appear to be a language that may eventually offer some practical value.
Asm.js is, at best, a very ugly hack. Instead of going in the right direction and eliminating JavaScript in favor of a proper embedded runtime or virtual machine, it's just promoting further use of bad (even if widespread) technologies.
Firefox OS doesn't appear to be anything but a me-too catch-up effort. Nothing suggests it can truly compete with iOS or Android, never mind the numerous other mobile OSes out there that are available on far more devices and actually have at least some users.
Persona is perhaps a good-hearted effort, but it's pretty clear that it isn't catching on. There are already too many other authentication systems out there, and many of them have far more traction.
The community as a whole would likely get much better value if Mozilla focused on the software that many people actually use on a daily basis, like Firefox and Thunderbird, rather than these side projects that don't really offer much at all.
That's unfortunate to hear. I would have hoped that you'd be more aware of its actual level of adoption.
Taking an objective look at the situation, as somebody who isn't tied to the project, I just don't see it being used. While so many web sites and applications allow authentication using Google, Facebook, Twitter and even some other more obscure providers, I never see Persona listed as an option.
The adopters listed in the article are minor, at best. Given that the BrowserID initiative has been public for almost two years now, it's not a very impressive list.
It's easy to write blog articles claiming that "hundreds of millions of Web users are now ready to log in with just a few clicks", but we just don't seem to be seeing that actually happening in practice.
I contest that GNU Mailman, the Eclipse Foundation, Firebase, the Born This Way Foundation, and Discourse are hardly "minor, at best." Not to mention extensive dogfooding within Mozilla itself.
Less flippantly, these things take time. While the initiative has been public for some time, it's only been in beta for roughly 6 months. It would be irresponsible for many organizations to jump on board this early, and taking that as a sign of failure is disingenuous.
Before they push Persona more, can someone walk over to the team that's running http://www.getpersonas.com/en-US/ and either disconnect their servers or lock them to their chairs until they finish the migration?
I understand the pain of rebranding assets, I do. But if you're going to rebrand to a product your company is already using, it has to be fast. And Mozilla, the 2 year anniversary is in July...
getpersonas.com is currently read-only [0], "Personas" have been renamed to "Themes" on addons.mozilla.org [1], and the getpersonas.com domain should go away within two weeks [2].
Persona seems terribly important. And well designed, particularly compared to the ad hoc social login systems. I don't understand why it doesn't have more mindshare. Is it not yet ready for use by consumer sites?
It's still pretty new (as the link states, it's still in beta). I'd say that is probably a big part of it.
That, and the whole federated/shared/social login space is confusing! First there was OpenID, but then everyone jumped to OAuth. But wait, OAuth isn't really about authentication?! Throw in xAuth and all of Eran Hammer's rants, and you quickly realize that anything resembling consensus is pretty tenuous, at best.
Persona looks solid, though -- here's hoping browser developers jump on board quickly. I'm concerned that OAuth's delegated authentication mechanism might remain king for a lot of free web apps, though. The ability to require permissions to post (spam) to your users timeline/wall (even if it's not actually needed by your application) is probably pretty tempting for someone trying to work every angle possible to make money from their application. Every angle other than actually charging for their service, that is.
OAuth is still very useful if you need more data from a user than just that he's who he says he is. If your app processes user data from another source, OAuth is still the best choice.
Also, people recognize Facebook and Google as brands they already have accounts with. When a user sees a big blue/red Sign In With Facebook/Google button, that's an easier decision than hand-keying your credentials (especially on a tiny and slow mobile keyboard). Moreover, users trust Facebook and Google to know how to secure their passwords better than randomsiteijustfound.com, so they may believe OAuth is safer than trusting that randomsiteijustfound.com's developer knows how to properly hash a password.
I don't disagree that OAuth is very useful when an application needs access to resources on another site.
That said, many of the applications that feature "sign in with Facebook", don't actually need access to my Facebook account. They may just be trying to make it easier for the user to sign in, but they also sometimes abuse that trust, and start posting things on your behalf.
Frankly, I'd much rather generate a random password for randomsiteijustfound.com and not worry too much about their password-hashing policy than trust them to do the right thing with access to my Facebook account.
This is why I like Persona -- if a site really just wants to make it easy for me to sign in, they'll use Persona, and I won't have to worry about them abusing my trust, because I'm not granting them access to anything else. Once I feel like they're trustworthy or useful enough, I can consider granting them OAuth authorizations to my Facebook account.
> I don't understand why it doesn't have more mindshare.
Because all they've published so far is API specs and fluffy PR sites that try to portray it as "oh so much better" without offering any insight about why it is better. They can claim "more privacy" all day long, but without any details about what gets stored where and why it is supposed to be safer, they don't make a compelling case.
Look at this page for example: https://login.persona.org/about (the "how it works" page) - it has 0 details about these claims and unfortunately, we're already tired of reading how Google and FB respect our privacy. From "outside", it looks like we need to give Mozilla our (existing) credentials and trust them to handle them with care. Why should we? I feel safer making pwgen passwords for every new site I need to register at.
And if you read those, it should become pretty clear _why_ this is better for privacy than the FB or Google login systems. For one thing, the identity provider is never told that you're logging in.
Not even the links you posted tell me a) where certificates are stored and how they are protected, b) what measures are taken to prevent unauthorized use of those certificates by the ID provider, the browser (plugins?), other entities, c) how the act of entering an e-mail address is secure (other people may have access to my computer and know my e-mail address). Admittedly, I didn't watch the 1 hour presentation video, but I've come across HN-linked presentation web pages several times and tried to understand these issues every time, the result was always the same: Mozilla assures me it's all done properly, but does not provide the relevant details to back up these claims.
Mozilla needs to make a very compelling case to web site owners for adoption, because FB and even Google has more users and oauth is at least roughly understood.
Let's see if I can help provide some answers here:
a) certificates are stored in localStorage for https://login.persona.org. They are very short-lived (hours), so that we don't have to deal with revocation, since that would likely be impossible on a per-user scale.
b) there's no way you can prevent an identity provider from misusing your identity. They're your identity provider. You chose them because you trust them to credential you and not let other folks impersonate you.
b') browser extensions already have full control over your life. That's something that should be addressed longer term, but Persona is not making this any worse.
b'') other entities cannot access the localStorage for login.persona.org, so that should be okay.
c) you're not just entering an email address. You're also proving you own it, for example by being logged into your Yahoo.com account, or by clicking the confirmation link we send you. What we're doing is minimizing the number of steps you have to take to prove you own an email address. But you still have to own it.
You should check out our documentation, which is quite thorough:
https://developer.mozilla.org/en-US/docs/persona
I think we've provided a lot of hard data and docs to back our claims, but we're happy to provide more, of course.
> how the act of entering an e-mail address is secure (other people may have access to my computer and know my e-mail address)
Assuming you're saying other people have access to your email account already, it's game over: practically every site will send password reset procedures on demand to the email you used to create your account.
Alternatively, if you're saying other people know your email address, that's not really relevant. They need to either be able to read email on your account (see above), or be able to implement an Identity Provider on your email domain.
If an unauthorized party is able to implement an IdP on your email domain you have an even worse problem: your email provider apparently is unable to control basic aspects of their own domain.
to actually implement an IdP, your email provider must publish a https://domain.com/.well-known/browserid file. If a rogue third party can do this at will, I'd say your email provider has horrible security and your security assumptions are probably broken anyway.
Since programmers and other tech workers still have difficulty understanding the details of Persona, this seems to be a clear PR issue. It's a lot like trying to convert normal people to Linux by telling them it's great and if they don't believe you they can read the source of the kernel. Not a very compelling defense.
From there, you can dig as deep as you'd like--we have docs to help with building an identity provider, integrating Persona into an existing site, even a list of pre-written open source plugins in a ton of languages/frameworks.
If none of that works, drop by #identity on mozilla IRC and tell us our docs suck, so we can prioritize making them better.
Yow, that's rough. We try really hard to publish docs that will help non-technical users, sites considering using Persona, and potential identity providers. The best starting point is probably the top-level MDN page:
I am a technical user. I just don't want to wade through source code or watch 1 hour long videos to understand why this is supposedly secure. I can accept that not telling ID providers where users are logging in enhances their privacy (whether they care or not is debatable). However, I do not see why accounts are protected better, especially compared to different passwords for every site.
What is my identity tied to? The browser and the given e-mail address? Can anyone who has access to these fake my identity? What countermeasures can I take if that happens? A simple password change is probably out of the question. Such are the questions I'd like to be able to answer, but with the provided, easily accessible information, I cannot.
To be fair, if you want to understand why something is supposedly secure, you will have to spend some time :)
Let's see if I can help.
Your identity is tied to your ability to prove that you own an email address. You can do that by clicking a confirmation link we send you. Or, as of Beta2 (today!), you can do that by having your domain implement the Persona Identity Provider API, where your domain publishes a public-key and issues certificates to you based on that public key, which you can then use to sign into web sites. Also as of today, we do that for Yahoo users by bridging to Yahoo OpenID, so basically Persona is an OpenID client to Yahoo, gets Yahoo to vouch for your email, and based on that issues you a Persona certificate (backed by our public key) for your email address.
But whatever way you go, it's about proving you own an email address and obtaining a certificate for it.
Yes, someone who has access to your browser can fake your identity if you don't lock your browser/OS, but that's nothing new. In fact, the simple password change is how we mitigate that. As soon as you change your password, we invalidate all sessions on all devices. Certificates last only a few hours, so they'll be disabled quickly too.
For this to be adopted, you need to have at least one major email provider implementing it, at least one major browser, and at least one major website. If you don't have the three corners of the triangle, people will inevitably judge Persona by its fallback implementation and will fail to understand the advantages Persona offers.
The good news is Mozilla have managed to implement a bridge that makes it look like one major email provider, Yahoo!, implements it.
Now you need the other two corners. Firefox OS is not mainstream enough, why doesn't Firefox for the desktop implement this natively yet? Isn't the whole of Mozilla behind this initiative? (Also, why haven't they fully retired the old usage of the brand Mozilla Persona yet?)
Very good points, and we agree. We're going to bridge more Identity Providers. We're working on native implementations (though I suspect that those are less pressing than the other two angles.)
As for big web sites... we've got some things in the works. But that's where you and others on HN can help. If you like Persona, if you like the vision we have, then help us. Pick one site where you can implement it. Ditch social login, which users hate, and pick Persona instead.
As cliche as it might sound, I think I have to say this: Be the change you want to see in the Web. Help us make Persona, the one login system that respects users, truly successful.
Browser integration is actually supposed to be one of the core pieces of Persona. The idea is that by building the Persona login process directly into the browser (as opposed to it requiring a popup/webpage) then phishing attacks may be somewhat mitigated.
Also, it's more private. With a native browser implementation, you don't communicate with persona.org every time you log in to a website, you only have to trust your browser to store your cached authentication credential.
Can I associate additional data to my profile? A lot of websites I use want to know my name, nickname, age, avatar-pic, timezone, etc. It would be nice if I could store it all with my Persona account and selectively allow access to sites that request it. I could even store my credit card info, and when the site wants me to fill in my address and such, I just click to allow access to that data, which can then autofill the forms.
I could even add things like have browsing preference data like "prefers-dark-on-light-theme", "no-video-or-audio-autoplay", or "no-nsfw-content". The site can add functionality for these preferences if it chooses to. Does Persona already have this?
This is fantastic! I'm really excited to see Mozilla improving the login experience for users across the web. It is a problem that is sorely in need of better solutions.
For the Node.js developers in the crowd, I'm happy to see Mozilla is using Passport.js (http://passportjs.org/) (which I'm the developer of) to power the OpenID/OAuth dances when doing identity bridging. You can see it in action at the BigTent repo: https://github.com/mozilla/browserid-bigtent
Passport.js can be used in your own applications to easily perform the server-side part of Persona/BrowserID as well as integrate with or transition from an existing login system.
Can someone recommend a good article about how Persona exactly works under the hood? I've seen zillions of news about Persona but haven't grasped the main concept. Comparison with OpenID will be appreciated also.
Many of articles say that Persona is great and awesome etc. but do not explain what are the advantages and security implications.
This is off the top of my head so maybe somebody will correct me, but:
Persona is a login system that cares about your privacy. With social login systems, the website you are logging into contacts the social login provider (Facebook/Google+/Twitter/what-have-you) when you attempt to log in. So you end up leaving a trail of breadcrumbs behind you of every site you visited (and used a social login on). Further, many people are not comfortable giving sites access to their social accounts because of privacy concerns.
With Persona, the idea is that your identity provider (can be your email provider, persona.org , or someone else) will have a key publicly available on their site. Your browser would generate a certificate that can be verified against that key. However, since the same key from the provider is used to authenticate all accounts on that provider, all the provider finds out when a website contacts it for the key is that someone is trying to log into said website. Plus, the website could cache the certificate and now the provider does not know this either.
There is more to this so you're probably better off reading one of the other links.
If Persona would care about anyone's privacy, they won't use emails.
Logging in with, say, Twitter account is less secure in aspect Twitter knows what sites you log in, but more secure in aspect the sites can't spam you unless you allow them to do so.
I've been thinking about this, and I have come to the conclusion that it's less of an issue than I thought it was. For a simple reason: the "email address" you provide is just an identifier. A string formatted as "user@domain", nothing more.
By convention it's a usable email address, but there is literally nothing preventing someone from starting up an email-less Persona identity provider. You'd still log in with your_username@noemailpersona.com, but that's just a formality that doesn't need to be hooked up to an actual mail server at any point.
Never using that account to actually communicate would put it on par with any other auth system you can come up with. Disposable when you want to dispose of it, and no need to ever dispose of it unless you want to. The whole issue with some people changing their email addresses for spam-fighting / inbox-cleaning purposes is a non-issue with this kind of an account.
This is correct, but the whole thing is marketed as email address, so it will be used as an email address, i.e. means of contacting me.
Now, consider I want to try some service I don't trust. I sign in with a email-looking identifier (which doesn't work as email address) and use the site for some time. Eventually, I become fond of this service and want it to start contacting me. With 123done.org I can't do this, nor at the mineshafter.info, nor at crossword.thetimes.co.uk. Trovebox looks broken to me, so can't tell it works, and I was lucky with voo.st, as it allowed me to add more accounts. Don't know more sites using Persona. Considering, today when you register with only Facebook or Google account relatively many sites don't let you change that binding in the future, it's very likely the situation with Persona will be the same.
Hopefully, the existence / use of non-emailable browserid providers would encourage sites to accept alternate / custom 'primary' email addresses. It's definitely a chicken-and-egg problem though, and far from guaranteed that it would be resolved happily. And I'm in complete agreement on the marketing, and it's a problem for this setup - the system is young though, maybe this can be changed.
Though honestly I suspect browserid would encourage this anyway, since people are likely to use their primary email address, and they are likely to change to a different address in the future. If sites want to keep people through such a change, they'll want to allow changing it (since I doubt I'm alone in resenting sites that require me to maintain an address I don't use. resentment isn't good for retention).
Personally, I wouldn't call email addresses identities, and just say they're credentials. But Mozilla clearly has another idea on what the identity is.
Choose your identity providers (and thus email addresses) wisely. They should be filtering spam for you / letting you control things. And they shouldn't be doing it by forcing you into their silo, the way "login with Twitter" buttons work.
Actually, it's my biggest problem with Persona is that the source of my identity is not me, but some third party I have to trust.
I run my email addresses on my own (physically-owned) servers. I know various approaches to filtering spam, and the best one in my experience is to not have a littered inbox is to have a private non-dictionary per-service email address and not expose it anywhere else.
The only mandatory third party between me and the Internet is domain registrar, I lease my domain name from. Not trustworthy, but this is the best one could have while all authentication systems are tightly coupled with DNS.
I know that. It's just depending on domain name "ownership" (and even though it's called so, it's temporary lease, not purchase of property), in exactly the same way general audience depends on email account "ownership".
Except for the fact, if one's email account or the whole provider goes down, they should still be able to login with old-fashioned password credentials. With Persona, unless the site has a backup authentication method, they're out of luck.
This effectively means I've to stick with my domain name forever.
The login string looks like an email, but it is only for convenience. Any thing that looks like an email address, and for which the domain will authenticate it using the persona protocol, can be used. Or even an address at mockmyid.com
Not an issue, as far as I can tell. Sign in as "OnlyMyPersonaIdentity@example.com" (or whatever) and then never check the mail: you get an easy, consistent identity, and all the sites get is an email-shaped label.
I do see the huge potential benefits of the system but have a couple of concerns.
I'm concerned that a 'one password' for everything can be more of a liability if your password is stolen/lost and make phishing potentially more lucrative.
Also concerned about a centralised password store - people make mistakes and if there was some DB leak/hack it could be damaging as it would not be contained within one system (if I've understood how it all works correctly).
For most people, their email password already is 'one password' for everything. If someone compromises their email account then they can use the account recovery features of these other websites to reset their password through email.
That's just the fallback identity provider Mozilla runs. The idea is that your GMail address will authenticate you using whatever GMail uses, so you can use 2-factor authentication.
If you have your own domain/server, you can easily switch out password authentication for something else today if you run your own Identity Provider. Here's my minimal Python IdP implementing TOTP (Google authenticator) authentication:
There has to be at least one password. If you use password managers like Lastpass or Keepass, you're essentially putting all your eggs in one basket, but that is generally safer than what the typical internet user does which is use the same password for everything.
Persona is decentralised by design (with a centralised stop-gap to get things going). Once other companies implement their own Identity Provider it's all entirely decentralised.
Doesn't that lead to the problem of having to have multiple identities again?
ATM, I have a FB account that I can use to log in to some sites, a Twitter account, a Google account, a Yahoo account, etc.
With potentially everyone being able to be an Identity Provider, what happens if a site recognizes some providers, but not others? Does Persona ensure that, regardless of Provider, I can use one login on all sites?
Furthermore, how does it protect me from the site gathering and aggregating all kinds of information about me (which, admittedly, they probably already have)? There's usually one overarching, way-behind-the-scenes entity handling the data aggregation for many sites (ie., Facebook) which leads us right back to where we are now.
Persona is the protocol that the sites use to communicate with the identity provider. If they support Persona they will support Persona authentication from any email provider that chooses to support Persona and from the fallback provider that Mozilla provides.
Well, since they get the email address, they can easily check that it ends in @gmail and stop everyone else. Of course, only supporting gmail means they have to write _more code_ than supporting every provider, so lets hope lazyness wins.
Identity Bridging will eventually get 60-80% of users functionally off of our fallback and onto their provider's native authentication paths, but I do wonder if the Persona fallback support two-factor auth natively for the remaining 20-40% of users.
Persona leaves authentication entirely up to the identity provider. In the case of the fallback identify provider that you're probably seeing, they choose passwords. Other identify providers can choose any method of authentication that they want to use.
I haven't been keeping up to date with Persona, but doesn't this open a window for email account breaching? I can picture some malicious websites mocking the "Sign in with persona" process and gaining the email AND associated password for that account without much trouble. Unless I've misunderstood Persona's point and the password is different from the user's email password.
Short answer (assuming native browser, native webmail provider): The malicious website would have to fake browser chrome and fake the user's webmail login flow.
What if I just want to collect emails and passwords, and with a free cert and a funky domain harvest (email, password)'s? I thought the whole point was to be password less?
Second, I wanted to play a crossword puzzle. I click login and am greeted with a popup window, I put in my email, then it asks for a password (ok whatever). So now I have to go to my email, and it says that I click the link and can go play the puzzle, but then it takes me to some persona account manager thing. I go back to my email, click the link again, this time with an error an no puzzle :(
Whats new here? That you guys plan is to just store logins for people? Do you share my email with the webapp I wanted to use? Seriously, whats new here?
The password stuff was because your email provider doesn't support Persona's protocol, so it fell back to asking Mozilla to validate your identity with a challenge email (and a password, so you don't have to use a challenge email when you come back next time).
Just one privacy question:
Imagine If I log in using the same email to Service1 and post some comment. And later, using the same identity I log in to Service2 to post some pictures. Does Service1 and Service2 (imagine the share some data) know that it was the same person?
I like Persona a lot and I would love to implement it on some of my sites, but I wonder how to best describe what it does to the average user. "Sign in with Persona" will probably look just as bad as "Sign in with Facebook"...
I tried to use my gmail address and it gave me this: http://dl.dropbox.com/u/13941904/persona.png
Am I just making up a password for a Persona account and it's using my email address as the user id? I can see how some people would type in their gmail password in by mistake.
I found this bit confusing too, but in a different way.
The first time around, I knew I was making up a new password, just not where it would be stored.
Then much later I used a different computer (but firefox sync'ed) and tried logging in to Persona, got asked for a password, and thought "oh, so now I make up a new one because it's a new browser and this is BrowserID? Where is this password stored anyway?"
I'm guessing that password is stored on persona.org, not in my sync profile, but even after reading http://lloyd.io/how-browserid-works I still find this one point confusing.
EDIT: I now see that the creation bit has a "verify" field whereas the sign-in bit has only one field, I guess that should have been my hint to use the same password as before. I'm still wondering though how it works when you have several email accounts on one browser, do they all share the same password? Does persona.org know that I have all those email addresses?
> I can see how some people would type in their gmail password in by mistake.
I can see how this could be a big problem once one ID provider decides he'd be interested in grabbing and abusing such credentials. The natural password related to the e-mail address for most people is that of the e-mail provieder.
Would Google ever allow this work with Gmail? Since they are trying to get sites to adopt the "sign in with google" option I'm curious if they would get behind this initiative.
I clicked on the first link, in the announcement of one of their adopters "The Eclipse Foundation" (actually their Orion project: https://orionhub.org/), to see what the sign in flow was like. I already had a Persona account from the early announcements but wanted to see it on a real site.
The experience was bad. I signed in with Persona on Orion to be greeted with "There is no Orion account associated with your Persona email. Please register or contact your system administrator for assistance." Isn't the whole point that I don't need to register?
I clicked the register button to see what more it would require and they wanted a user name, password, and email. With such a poor integration the whole idea of not having to remember another, username and password is lost isn't it?
Obviously this particular failure is the fault of the integrating site and not Persona which seems really cool.
Screen shot after logging in with Persona; then after clicking register:
http://imgur.com/a/WCKnh
Thanks for beinging that up. The specific implementation at OrionHub is Not Ideal -- they should kickstart account creation when you sign in with Persona, like at https://voo.st or http://sloblog.io
I'll reach out to the folks over there and see if that can get that fixed in their next release.
I don't like Persona, personally. Email is not an identity. When we connect with email and passwords, both fields are keys (in the open-the-door metaphor). To make the password a secret key, we can't check it for uniqueness so we need a less secret key that will be checked for uniqueness. I think it's important that users can easily modify both keys without loosing their identity.
> Wait. So, my email provider (Yahoo) can now keep track of every website I login to, if he wants? How can I stop Yahoo being the middleman?
Nope.
Architectures like OpenID "phone home" and report your movement across the web.
Persona was explicitly designed to be privacy preserving.
> Second question, if an attacker knows my Yahoo password, can he potentially login to _all_ Persona-powered websites with my email then?
Yes, if an attacker has your yahoo email address and password, they can log in as you. BUT, you can take advantage of two factor auth from Yahoo as well as other security features they provide, to keep yourself safe.
No, because Persona mediates, and Yahoo only knows that you're using your Yahoo identity with Persona, nothing more. That's a key privacy property of Persona.
However, if you use the "login with Yahoo" button (or Google or Facebook), then yes, they can track all of your activity.
To your second point: great question! No, the attacker cannot. We still protect your other email addresses with a Persona password.
Oh wait, I misread your point. Yes, the attacker can log into all Persona web sites if they know your Yahoo password. But that's the way the cookie crumbles with federated identity. It's the same thing if you pick a Yahoo email address as your recovery email. Pick your identity providers wisely!
Isn't the second question equivalent to what we have now? If an attacker knows my Yahoo password, can he potentially reset all the passwords of sites I registered with using my Yahoo email address and login to them.
Email accounts are almost everyone's achilles. Even without Persona, the attacker could still go around to websites and request password resets if they have access to your email.
So I can log in everywhere using the exact same username? This will make it SO much easier for the user data trackers to capture and aggregate all of the information they can about me. I think I'll take a pass.
It's also one that isn't very easy to solve, regardless of how you slice it. Most sites that let you create your own username still require an email address. If you're using the same email address, we're back to square one here. Persona absolutely does not increase your trackability, and by giving users at least the option to use multiple, different email addresses, it's better for privacy than, say, Facebook Connect. That's a win in my book.
It's got curl and streams examples so it should cover 95% of the PHP installs out there. Its crazy how easy it is to drop in and implement...Mozilla's done a great job with it so far. I look forward to more integration of it in the future.
The login on the Persona site (https://login.persona.org/signin) doesn't seem to work for me, using my Yahoo account. It pops up the Window, I login to Yahoo, that little window goes away, then ... nothing else happens. If I click "verify" again, the little window pops up momentarily and then just goes away. Is it supposed to actually do something, or was that the whole demonstration?
Though we might need a month or two to get a few last details ironed out, an identity bridge for Gmail is absolutely coming soon. Until then, we wanted to soft launch with a single bridge (Yahoo) before throwing the switch for everyone.
It already works with any email address, including Gmail. But the Persona team works on a dedicated support for Gmail, that will allow Gmail users to use Persona without a need of an additional password.
One major difference is that if you log in to a site with Facebook then Facebook knows you logged in to the site.
Whereas if you log in to a site with Persona, that's between you, your browser, and the site. Mozilla is not pinged with any details about you in the process.
Furthermore, Persona is decentralized. Anyone can run an identity server (though sites don't have to trust all servers, obviously). So you do not in fact have to build an account with anyone new if your mail server deploys Persona and sites trust it to identify people. The article points out the Yahoo has rolled this out already, so anyone with an @yahoo.com mail doesn't have to do any new account-building.
Oh neat, it seems my current Firefox (20) works with Persona now when third party cookies are disabled. This was a huge problem before when I was playing around with it a few months ago (it would flat-out never properly authenticate when I was testing it before). Didn't think the new cookie policy would roll out of testing so quickly.
So, openid by firefox is called persona? I would like to use google, twitter.
What are the special features of this? I don't think anybody would like to use firefox OS. But it's good, but it has a heavy competition in the future.
1. Privacy: the identity provider can't tell what site you are logging in to.
2. It's decentralized: any email provider can provide Persona authentication for the email addresses that it handles. You don't have to rely on Mozilla to do this except as a fallback for email providers who don't support Persona.
I already have three such aliases in my Persona account. I'd say Persona makes it easier to use the me+thissite@fastmail.com method. Of course, if you add a hundred such, you'll get a very long list to click through when you log in …
The concept of putting <script src=> on my login page skeevs me out more than a little bit. This is a major security hole that won't be patched until there is native support in the browser.
Off-topic, but wow. Blast from the past. Tucows is still around, and now has a mobile phone service! That was my go-to place for shareware games when I was a youngin'.
Persona works with any email address, so the major difference is that you can get the "Sign in with Google" experience, with just one button, but without being forced to choose (and phone home to) Google.
Another big thing is privacy. Signing in with google, or facebook pretty much enables them to stalk you. This can't happen with person due to its architecture =)
Why promote Yahoo!'s email service? They still don't use SSL after you are logged in right? Sending your plaintext session cookie over the net, allowing people in your coffee shop to hijack your email. Nobody should be encouraging people to keep or get Yahoo email accounts.
Just checked, you can now enable SSL, but by default it is not enabled. No doubt most people don't have it on. Therefore, Yahoo is still an insecure email service.
There are a plethora of links elsewhere in this thread answering that exact question, but in brief, the developer experience, user experience, and privacy model are all dramatically better.
Please, guys, change the pastel orange background of the blog to something a bit more serious. It gives wrong first impression and starts things off the wrong foot.
Why are they shitting on social sign-in when this works the exact same way, but with email providers? You still need a pop-up that takes you to several domains and makes you click Yahoo's "Accept" button.
I can see the confidence people might get from the added layer of Persona talking to the external service as opposed to the website that you've never been to before (given the Persona brand builds lots of trust), but the UX is still just as clunky and awkward.
The UX isn't perfect, but Persona does have a few advantages that ultimately make it better for the end user:
1) Doesn't require a popup. The idea with Persona is that browser developers would build a Persona/BrowserID-type dialog directly into the browser, as opposed to requiring a popup/webpage. This may help mitigate phishing.
2) Better privacy for the end user. With other, uri callback-based systems, your IdP's know what sites/services you're accessing. With Persona, this becomes a bit more difficult, as there is no callback mechanism.
Julius Schorzman of DailyCred, the instant CRM package for any web site, implemented Persona and remarked “We’ve seen from our internal metrics that more than 70% of users still prefer email and password authentication over social log-in like Facebook. Implementing Persona is actually easier than Facebook Connect, or any OAuth implementation we’ve seen.”
People want control over their identity on the web. Social sign-in doesn't meet this need.
I'm personally not a big fan of social sign in, and i doubt i'm going to use persona (at this time).
Persona seems like to me kinda like what the chinese are doing with requiring people to use .gov ids on the web. Sure in china it will be by force and here it will be opt in, but in my eyes the result will be the same: making it easier to track people across the web.
I don't feel like persona solves the ability for a person to have control over their identity on the web any more than people do now, maybe just offer the same utility of social logins without trusting 3rd party(?).
Are all persona users data stored in a central location (besides websites that have multiple users sign up through persona?)
As I understand it, there's nothing to stop you using a separate Persona ID for each site you visit, and none of your IDs has to be tied to your real life identity. But most people already give the same username and same e-mail on loads of different websites, so we're happy to carry on doing that.
For now, most Persona users are stored in a central location by Mozilla. The idea is that e-mail providers take over authenticating users, so eventually there should only be a few users that Mozilla stores credentials for. I'm hoping that GMail will add support soon.
Hmm, I can see how this would be better than using facebook connect for the risk adverse (though I must question that if one is using something like facebook connect or google whatever in the first place).
But most web users aren't risk adverse, and I question the utility this will have over facebook connect when using it in some kind of application that the user wants to use that requires some kind of social data in order to get the most out of the app.
You can run your own persona identity provider on your own domain, then use an email address at that domain to log in. You get to control the authentication, the password policy, decide on multi-factor, etc.
This actually very much can solve the inability people have to control their identity on the web.
It appears to me that in order to run your own Persona Identity Provider you must setup and maintain an SSL capable webserver for your email domain, equipped with a certificate that chains up to one in Mozilla's bundle (no self-signed cert), configured to handle the Persona protocol and authenticate you. FWIW, some (including myself) run email-only domains/servers with unnecessary services (httpd!) purposely disabled in order to reduce attack surface and administration chores.
AFAICT, even if you do setup your own Persona Identity Provider you would not have control over Relying Parties (websites you login to) and how they verify identity assertions. IOW, you couldn't prevent Relying Parties from taking the easy way out and issuing backend calls to Mozilla's verification service. Which would leak Email Address, Login Site, and time information to Mozilla. Nothing against Mozilla BTW, it's just a third party in such contexts and thus should not be privy to any information about account creations and/or logins.
I think those who run a strong browser config (limiting third party scripts, third party cookies, and/or cross site requests) would have to weaken their setup to even allow the Persona mechanisms to work correctly.
When i think of people controlling their identity, i dont think of just an email address. I think of their name, their gender, what they look like and the context their data is put in on the web.
Persona seems like it has everything to do with the signup/login process, and not the actual identity of the person who already has some kind of data of that kind floating around the internet (the kind people want to sell to others).
There's no way that this gives someone the ability to go back and erase whats already out there now and somehow give them control over where their information resides and how it's used more than it is now.
Maybe i'm missing something, but this doesn't seem to provide any more utility that i need now since i haven't even incorporated any social login to my site anyways (and don't plan on it either).
https://github.com/sergiotapia/ASP.Net-MVC3-Persona-Demo
Please give this a shot! I would only like them to keep more information on hand, like a first name, or an avatar so I don't pester my user with such requests.