FC4: Persona Questions

A couple of episodes back, commenter “tom jones” wrote, urging me to study Mozilla Persona: “it seems all the questions you are discussing have already been solved by them.” Well, then.

[This is part of the Federation Conversation series.] This piece in particular left a lot of open questions in my mind, which appear at the end of the sections down below. None of them are rhetorical and I’d like to hear what people think.

So I went and looked at the Persona docs, and had some email back and forth with Lloyd Hilaeil, a Mozillian who works on it, and wired it into my testbed at favcolor.net — and it sort of works.

But please don’t go beat on it yet, there are some missing pieces (see below) and the integration is kinda rough.

So I’m not a world-class Persona expert, but my hands are dirty enough to talk about it. I’ll compare it here and there with the OAuth-2-based OpenID Connect protocol, which I’ll call “OIDC” for short.

Moving target · Persona is one. I had two real irritants in integrating it with my testbed. First of all, as it stands now, the sign-in dialogue is popup-only, which means you have to have a human click something to launch it; you can’t start it programmatically, which means even if you know the email they want to log in with, the IDP they want to use, and every other relevant fact, there’s no way to just launch the freaking sign-in process already. Second, when you do launch the sign-in process, there’s no way to tell Persona which email address you’re trying to sign in with, so (unless they’re already signed in) the luckless human is going to have to type it again.

If you think about it, you can combine those two capabilities with something like AccountChooser and get secure one-click sign-in, and after you’ve experienced that even once, it sure smells like the future.

But, Lloyd tells me (with pointers to Github branches), they’re fixing that stuff. So when they do, I’ll smooth out my testbed integration and encourage everyone to try it.

OK, now let’s ask some questions.

The theory · It’s documented in Protocol Overview, and has the following players: The Browser is being operated by a person with an email address. The IDP is a Persona Identity Provider, for example login.persona.org. The RP is a site that wants to log the user in. It goes like this:

1. The Browser generates a keypair.

2. The Browser sends its public key to the IDP.

3. The IDP authenticates the person at the Browser to an email address, with a traditional password or space-age hardware token or whatever.

4. The IDP generates an “IDP assertion” containing the email address, the Browser public key, and the IDP’s domain name, signs it with its private key, and sends it to the Browser.

5. The Browser generates an “RP assertion” containing the RP “origin” (scheme, domain, & port), and signs it with its private key.

6. To sign in, the Browser sends the RP assertion and IDP assertion off to the RP, which fetches the IDP’s public key, and can verify that:

   • The IDP issued the IDP assertion.

   • The IDP authenticated the email in the IDP assertion, and its association with the Browser keypair.

   • The Browser holds the same keypair and wants to log into the RP.

(I’m omitting a bunch of stuff about discovery and expiry times and so on, because I don’t think they’re essential to understanding.)

It’s pretty comprehensible, and has fewer steps than most OAuth 2 flows. Also, notice that the IDP doesn’t need to know who’s logging into the RP, so in theory there’s less tracking.

I now work among security experts but I’m not one, really, so I’m going to be silent on whether this is more or less secure than OAuth. And I’d encourage people joining the conversation to zip their lips unless they really understand these issues; 14 months in Google’s Identity group has taught me deep humility about the way real security people look at things, and how far I’d have to go to get there.

Question: If you’re an expert, do you think it’s secure enough?

Theory and practice · I was wiring in the Persona software, following the instructions in the (really pretty good) Quick Setup doc, and got to Step 6 in the flow above. I assumed my next task would be figuring out how to fetch the Persona.org keys and validate the assertions. But I don’t have to; the doc says, and I quote:

Once your server has an assertion, how do you verify it? The easiest way is to use a helper service provided by Mozilla. Simply POST the assertion to https://verifier.login.persona.org/verify with two parameters:

1. assertion: The identity assertion provided by the user.

2. audience: The hostname and port of your website. You must hardcode this value in your backend; do not derive it from any data supplied by the user.

I did that, and it works just fine. And, well... of course, the IDP (in this case login.persona.org) can now track everywhere I go and every time I sign in. So, just because you’re using a protocol that allows tracking avoidance, that doesn’t mean you’ll get it. Conversely, just because you’re using one like OIDC that tells the IDP where you’re signing in, that doesn’t mean your IDP will actually log it. This is about policy not technology.

Question: How many RPs do you think will bother to fetch the key and check the signatures, and how many will just do the easy thing that works from the Quick Setup?

Site Experience · Persona, by design, only shares its users’ emails with RPs. As far as the RP knows, you’re your email and that’s all you are. OIDC offers (with user consent) a small package of information: Display name, link to a photo, gender, and so on. Nobody’s under any obligation to provide these things, but you almost always get at least a display name, so you can say “Hi Tim Bray!” as opposed to “Hi tbray@textuality.com!”

So I had to do some re-engineering on my demo site to make do with less, and the user experience was a bit impoverished. For a demo that’s OK I guess, but this kind of thing will make a lot of app builders grumpy.

This notion of “social login” is really not a Facebook plot for world domination, it’s something that a whole lot of sites and services find value in. And there are lots of intermediate points between full-on Facebook Connect and nuthin’-but-email Persona.

Question: In terms of telling RPs about the people who sign in, where do you think the sweet spot is?

Human Experience · (Yes, I bend over backward to avoid the word “user”, which I loathe.) In OIDC, an essential step is that the RP registers its app at the IDP, with a human-readable label and optional graphic. And when you try to authenticate, the protocol includes an RP identifier and requires that you get a prompt asking if you’re OK with your identity being sent to that site (identified by text and graphics) before sign-in happens.

On the one hand, this makes sign-in tracking possible in principle. On the other hand, it means you can be really sure you’re never going to be signed in anywhere by surprise. (By the way, the protocol isn’t stupid, you only have to approve sign-in to a site once.)

Question: Which is better?

IDP Experience · In case it’s not obvious, I’m seeing mostly reasonable trade-offs between Persona and OIDC. At the moment, my biggest issue is, do I want to use Mozilla for my IDP? Well, they’re an independent non-profit (even if they are ad-financed), and they produce a totally great browser that I use every day of the year, and the Mozillians I know are by and large cool and smart. I’m a fan! So yeah, maybe.

But maybe not. How many data centers does Mozilla have? How many engineers doing abuse-detection and fraud-prevention and account-recovery? Do they offer two-factor? How good are their lawyers? How well are they defended against attackers who are employees of foreign governments?

I actually think this probably isn’t a problem, because I can’t see why Mozilla would want to build out the horribly-expensive infrastructure and devops you need to be a global-scale IDP. Maybe they’d like to be an (unusual) IDP-with-no-other-service-businesses for people with special privacy requirements? But actually, for the mainstream, I think they’d be perfectly happy if Google and Facebook and Paypal and so on decided to be Persona IDPs.

It wouldn’t be that hard for Google to be a Persona IDP, I think, assuming our security gorgons can get comfy with the protocol.

Question: Should Google be a Persona IDP? Why?

Mobile experience · I’m quite intimate with our work on OAuth-2-enabling Android apps. It was hard because OAuth 2 explicitly calls out to browser redirects, which native mobile apps can’t straightforwardly do.

I note that Persona doesn’t really depend on redirect semantics, and if you could find a way to park a long-lived IDP assertion on a mobile device, that might help things work smoothly in the native-app context.

I haven’t dug into this much, but the idea has promise.

Question: Is there any Persona-on-mobile work going on out there?

That tracking thing · I confess: I. Just. Don’t. Get. It. I am reasonably paranoid; I routinely refuse to share my location, and I am currently refusing to install the mobile app from my bank because it wants permission to read my contacts. Ewwwww... banking isn’t social!

But check out the gory details on who’s watching you. Your phone company knows where you are all the time, and between the spooks, the enemies, and the ad companies, you are being tracked eight ways from center, permanently. The fact that an IDP knows about my (relatively-infrequent) sign-in events seems to me like it’s way off to the right of the privacy decimal point.

Having said that, I acknowledge that there are people who are going to disagree. And yeah, if you’re that kind of person, Persona should (in theory, if not always in practice) allow you to dodge one particular flavor of tracking.

Question: Is there a reason why sign-in tracking is especially pernicious and to be avoided?

The future · I think Persona’s just fine. It didn’t take long to understand and it didn’t take long to integrate with. I don’t know whether or not it’ll become a big mainstream ecosystem or not; wouldn’t be surprised either way.

I’ll tell you one thing I’m pretty sure of, though: The future will have more than one Identity protocol.

My work hooking up Persona to various bits of Identity middleware already has one interesting finding, orthogonal to the goodness-or-not of Persona, and here it is: I’ve had remarkably little pain wiring together real OIDC as practiced by Google, not-quite-real OIDC from Microsoft and Facebook, and Persona, all in one app, with a decent, consistent user experience.

Question: Does anyone not think we’re headed for a multi-protocol future?

---

---

Contributions

---