Persona makes signing in easy for Gmail users
identity.mozilla.com
identity.mozilla.com
Persona would be a lot more privacy-preserving if it generated a unique identifier for each website. A "persona" for each website instead of one persona for the entire interwebz. Since the system is mostly automated it shouldn't be that hard to add one extra layer of indirection.
It might even be possible to shoe-horn it in to the current protocol with just a little bit extra on the browser and identity provider sides, but no change on the website code.
If anyone has actually done that, please post, I'd like to hear about it. Availability of that functionality would sway me to start using Persona and probably anyone else who is worried about spreading their email adddress far and wide across the internet.
That's identical to the status quo, and fixing it is not one of Persona's explicit goals.
We're very consciously trying to hit a pragmatic middle ground that moves the web closer to user empowerment, without being so different as to hinder adoption. Consider: if you're already collecting email addresses for your users, you can immediately start using Persona without changing any of your assumptions about your data model. It's portable and it dovetails into current practices.
However, it is technically possible to do what you want right now, so long as you have your own domain and write a small browser extension. Longer term, we're currently working with a partner on a possible extension to the provider protocol which would make it easier to implement that sort of "directed identity."
Also some people do want a single identity for the entire Internet, or at least a lot of it. Many people use the same real-name identifiers on HN, Github, LinkedIn, etc. professionally.
Easy to integrate, no need to worry about screwing up storing passwords and you are not abdicating authentication to some evil or possibly evil in the future, company.
1) login.persona.org that takes care of authentication
2) a JavaScript shim that developers add to their sites to get the login button to work.
Persona is designed in such a way that reliance on Mozilla will be phased out as email providers take care of #1 and as browsers start to implement #2. As of now I think FireFox is the only browser that has #2 baked in.
I'm pushing us to get our data formats stabilized in the next few months so that we can start building native extensions for browsers and get ourselves completely out of that loop.
It's worth thinking of Persona as the reference implementation of the BrowserID protocol. If we're successful, Persona as you know it automatically disappears as more and more domains and browsers add native support for the protocol. :)
Google is a giant multi-national corporations that measures revenue in the tens of billions of dollars per quarter.
That means that Mozilla's responsibility is to the people of the world and Google's responsibility is to maximize financial returns for the the already well-off financial class that invested in Google stock.
Does that help you see the difference?
Do you want Persona authentication on your website or do you want a deamon that is an identity provider for your personal domain?
What language or platform would be ideal?
Shane Tomlinson and I gave a talk about turning your own domain into a Identity Provider at FOSDEM this year, which might be helpful: https://www.youtube.com/watch?v=0YRq9LWnlBw
Also, if you'd like to source dive:
- Minimal, static, Mailinator-style IdP: https://github.com/callahad/mockmyid/
- Minimal standalone IdP: https://github.com/mozilla/eyedee.me/
- Mozilla Employee (LDAP) IdP: https://github.com/mozilla/vinz-clortho
- GMail Bridge: https://github.com/mozilla/browserid-sideshow
And there's a Drupal module: https://drupal.org/project/browserid_idp
It's free for now, and will probably always be free for individual usage.
https://ozten.com/.well-known/browserid (a static website) delegates to https://hostedpersona.me/.well-known/browserid which I run on an ec2 instance.
This clearly isn't as polished as aptitude install, but feel free to fork and play.
Just add the .well-known file to your site, and that's it.
EDIT: Actually, I might just open-source this and keep the hosted version for people who want convenience.
It's still early-stage, but it works very well for plain authentication. Next step is two-factor auth.
Awesome job on the site!
EDIT: This is really odd, it's the exact same HTML/CSS, yet a different typeface. Weird.
EDIT 2: It would help if I had actually included the font in the header. Thanks again :)
The auth and provision routes need to be HTML pages that authenticate you however you want, and then sign a certificate with your key that you publish the .well-known file.
Here's how we did it for Gmail: https://github.com/mozilla/browserid-sideshow/blob/master/bi...
UPDATE:- There is a plugin like that http://wordpress.org/plugins/browserid/ . Too bad it doesn't work with Google Apps.
There's a couple of posts on meta.discourse.org asking how to integrate Discourse with an existing Single Sign On (assume all users have email addresses)
With Persona on a LAN-side server, you could even have emails like janesmith@intranet.local and it'd still be seamless.
(Persona works on all major browsers, save MobileIE and Chrome for iOS. Fixes are in the works for those two.)
Then you're never sending anything sensitive to the server.
Sure, it still has the issue of the user choosing a good password, but persona doesn't really get around this, just makes the mail server deal with it.
If I recall correctly, Clickpass was a centralized OpenID proxy, whereas Persona is trying to bootstrap a fully decentralized protocol. We don't want to even be able to track you. :)
[Edit: Corrected YC cohort. Thanks wamatt!]
Then a few years later (2012), Yola sold the IP and users to Janrain [2]
[1] https://news.ycombinator.com/item?id=402973
[2] http://janrain.com/clickpass-acquired-by-janrain/
EDIT: my pleasure callahad :)
Where? I can't see it.
There are many ways they could have notified OpenID users that would have worked -- this wasn't really one of them!
And some things, like using myname+website@gmail.com doesn't work at all.
EDIT: Now I remember my use case.
My email is actually myname+randomstring+website@otherdomain.com, and so I want to sign in with the same randomstring every time. Previously when signing in to Persona with my Gmail email address it would suggest all alternatives, and I'd choose the appropriate one. Now it logs in with Gmail directly instead.
Of course, this is such an edge case that it's probably not worth doing anything about. And I can simply sign into Persona with myname@otherdomain.com for the previous functionality.
Run it with the following command-line arguments: -ProfileManager -new-instance
That brings up a profile picker/creater. Each profile is isolated, different plugins, different cookies, etc. The only information leakage is when a plugin keeps its own data outside of the profile directory, like Adobe Flash keeps its version of cookies in a per-user directory rather than a per-profile directory.
It's not super generalizable, but if you're interested in rolling it out on your end, ping our mailing list (https://lists.mozilla.org/listinfo/dev-identity) and we're happy to support you while you get that going.
A generic Google Apps bridge is somewhat tricky, but we're really interested in prototyping it over the next few months.
and put your gmail in the box :)
Which is completely logical when I think about it since persona would not use the mx record to find the identity provider.
Looking for that "aspmx.l.google.com" entry in the MX record would let them know, with a high degree of certainty, that Google is the login authority for that particular email address.
Is there something I'm missing?
The main thing is that while Persona talks about email verification, the protocol doesn't require that email handling exists. Just that a server vouches for the existence of a user@host, so using MX records wouldn't be 'correct' even if it would be a useful heuristic for google apps domains.
There has been talk of using SRV records, but it looks like the .well-known/browserid file will be the recommended way to do things.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Persona/.we...
Using the mx record would be bad, because, if you are doing it yourself, then your email server would have to also have a persona authenticating server, it would be hard to use your own persona authenticating server and have a third party take care of email, etc.
That said... here is one of the building blocks https://github.com/mozilla/browserid/issues/2932
Get involved and implement this as a NodeJS module.
https://github.com/workhere-io/personaexamples
There's also a demo that shows how Persona works (doesn't save any of your info):
Weird. Oh well. Can't bitch much with a free service can I?
(And not even once per website, just once in a lifetime.)
- Persona works with any email address. This means you can reach anyone that hits your site, without forcing them to sign up with a third party provider.
- I can answer the question "what email address do you want to log in with?" I can't answer the question "what is your OpenID?" nor can I remember which of the 13 buttons on Stack Overflow I used last.
- OpenID requires phoning home with every login transaction. Persona explicitly does not. Your provider doesn't get to learn where you are logging in.
Edit: Put another way, can you tell me what your Google OpenID URL is without cheating? Can most people? If not, then you're only able to select a provider from a predetermined whitelist on each website. That undermines your ability to self-identify, self-assert, and choose who you trust. The open web deserves better.
Or that was my Google OpenID at one point, not sure if it still acts like one or not.
Email addresses have been used as login credentials for a while, so people are used to that. The explanation of Persona might be a little weird, but it's not as totally disabling to a nontechnical user as being asked to sign in with OpenID.
https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Why...
2. Are developers permitted to strip the Persona branding - to make the login process seem to flow with the current website - not a bolt on?
3. Would you consider including tiny profile icon links next to the button itself, to facilitate single-click profile sign-on/switch?
Persona follows the LIFD architecture: http://www.open-mike.org/entry/lifding-the-web
Popups allow us to create a nice messaging channel between the shim / localstorage at persona.org and the website the user is trying to log into, without losing their state on that website.
> 2. Are developers permitted to strip the Persona branding - to make the login process seem to flow with the current website - not a bolt on?
Sure. Brand it however you want. "Sign in with your email" converts best. The popup will always follow the same basic form, but you are able to add your logo, a human readable name, and a background color to influence its design: http://identity.mozilla.com/post/55796551587/persona-a-login...
Check out the login on https://see.drupalpersona.me https://webmaker.org and https://ting.com for examples.
> 3. Would you consider including tiny profile icon links next to the button itself, to facilitate single-click profile sign-on/switch?
Our UX folks are actively experimenting with this. Look for Ryan Feeley's posts on the dev-identity mailing list for some explorations.
1: http://identity.mozilla.com/post/56526022621/what-is-an-iden...
Which means that 99% of sites don't need to worry about security for passwords, and you don't need to worry that your password has been stolen by hackers and now they're trying that same password on every site you might have ever used.
It's also decentralised, so there's no tracking of what sites you've logged in to. (Or, at least, it will be, once email providers implement IDPs themselves rather than using the Mozilla fallback). And the way the certification works, the IDP has no idea what sites you're signing into, so you're safe from that too.
What you're really doing when you sign in to your identity provider is getting a certificate, signed by them, and containing a serialized public key (from a keypair generated and stored in your browser).
What you're really doing when "signing in" to a Persona-enabled site is sending them the certificate and a signed assertion, and letting them check all the signatures (public key in the certificate verifies the signature on the assertion, and the provider's public key is obtained to verify the signature on the certificate).
The only entity involved in this who needs to get a password from you is the identity provider, and password auth isn't required for that; it's just an easy and common way to do it. Sites you log into using Persona never ask for, see, or store a password for you.
The certificates are transient (they expire within 24 hours). The assertions generated by your browser are transient (they expire within 5 minutes). The keypairs generated and stored by your browser can be transient (you don't need to use the same keypair each time you sign in to your identity provider), and are tied to a specific email address and browser instance.
The whole thing is also designed to be decentralized. For most people, for now, Mozilla is the identity provider, but you can run your own (relatively easy) or use a trusted third-party provider. All that matters in a provider is that it speaks the protocol.
This means that comparing Persona to "password authentication" or "two-factor auth" is not really a useful question; your provider can use any mechanism you both agree on to verify you and give you a certificate. Though the immediate big win is, of course, that if there's a password involved, only the provider ever handles it, so you don't have to worry about a bunch of sites' password-storage practices, and you may not even have to worry about your provider's (if your provider doesn't use passwords to verify you).
The provider also doesn't know what sites you're signing in to with Persona; they don't receive the assertion from the site you sign into, they just provide a copy of their public key so the site can complete verification.
Must add that to velruse.
If that's not the case, then what, exactly, information does website X have about me now that I have 'logged in using persona'?
Basically a site using Persona tries to send you to your email provider to authenticate. If your email provider is running Persona, you'll authenticate through them, and the email provider sends a token back confirming your identity.
Mozilla is the default identity provider for people whose email providers don't run Persona (yet). Once the project gains widespread adoption, Mozilla won't be processing much if any authentications because they'll be distributed to email providers.
Also it will in theory work as a browser extension, so your email provider sends your browser the token, and your browser sends the token to the websites you log in to. So your email provider doesn't know where you're logging in.
I don't understand this. Presumably there's nothing stopping Website X sending both: a) my email address; and b) Website X's URL.
Scenario: Joe Bloggs tries to log in to www.SiteThatSellsCars.com using Persona. Joe enters his email address. SiteThatSellsCars sends Joe's email address and "www.SiteThatSellsCars.com" to Joe's ISP. This translates to SiteThatSellsCars saying, "Hey, Joe's ISP, Joe is looking to buy a car, you should send him a metric shit-load of car adverts. He might not like it, but whatever. Thanks for the $20!". Then Joe's ISP replies with, "I sent Joe a token to his browser so he thinks he still has his privacy, but fuck him. Every customer you tell us about, we'll give you $20."
Perhaps I am being cynical.
The site then checks the request is really signed by the identity provider and lets the user in.
The identity provider knows two things:
- You asked to log in somewhere - At least one person logged to site X because site X asked for its public key
It's more like a client certificate issued by your email provider and installed ad-hoc on demand, rather than a typical Central Authentication System.
Yes, but there's nothing stopping them from doing that today. Persona doesn't help you if the site you sign into can't be trusted with the identity you give them. But nothing requires you to give them your normal e-mail address - you could just use throwaway if you find that a concern.
This is not what Persona tries to fix.
Persona is single sign-on where the identity provider does not know which site you sign in to, unlike current solutions where e.g. Google, Twitter or Facebook knows where you sign in whether or not the site you sign into is trustworthy or not.
This is already the case. For browsers that use the shim, the certificate is stored in localStorage on the login.persona.org domain, and then given to the website you're trying to login to.
The protocol still requires an identity provider to attest to your identity, but the actual identitifier doesn't appear to have to be a real email address. It seems like you could use anything in email address format.
(Persona always prompts you with a completely free-form email input field and routes you to the appropriate provider based on that.)
In particular, we're watching the IETF's JOSE family of standards pretty closely.