[lukev]

Other than the benefit of using strong crypto under the hood, I'm not sure what benefits this has over a system like openid. It has about the same level of interactional complexity, and at the additional cost of requiring browser support.

If we're going to have browser support anyway, I'd rather just use standard two-way SSL and put the work into developing better UI and private key distribution systems for it. It's even more secure and has a great user experience once you've set up the key in the browser and authorized it to the site.

[shantanubala]

Usability involves more than one target audience: it also has to be easy for developers to integrate.

BrowserID (Persona) took me minutes to implement. On a non-trivial project, it may take a couple hours. The beauty of this is the fact that it still works without built-in browser support. It's designed to be a forwards-compatible API that only becomes more usable with time.

Additionally, email is an excellent way to establish a user's identity, and the fact that it's designed around email makes it easy for a regular person to understand its authentication flow.

The problem with SSL is that it is an all-or-nothing technology. There's a chicken and egg problem: people won't make good UI for it until it's widely used, but people won't use it until it has a good UI. Persona provides an implementation of BrowserID that has a decent UI, and the user experience will only get better with time as more people use it. The chicken/egg problem is solved there, but two-way SSL right now is practically unusable for anyone who isn't very familiar with it (most people). Using an email address is very familiar, though.

[StavrosK]

I've forgone traditional auth in favor of Persona because there are just too many advantages. The user might already have an account, the flow is very good if they don't, it takes literally three minutes to integrate django-browserid (or whatever it's called now) versus skinning quite a few templates for all the login and reset forms, it saves the user from having to remember yet another password, etc etc.

I couldn't be happier with a signin solution. It even complements my legacy solution very well, you can see a demo at http://www.yourpane.com (click "Persona", never mind the email field.)

[StavrosK]

The benefit is orders of magnitude better usability. I couldn't get users to grok OpenID, this just needs an email and password.

How will my mom log in to an SSL-certificate-requesting site from another computer?

[lukev]

This has pretty much the same end-user experience as OpenID, unless I'm misunderstanding something. The user still has to sign in to the IdP.

[StavrosK]

You're underestimating how familiar someone's email address is versus an OpenID URL whose significance the user doesn't know and whose use she can't grasp.

[ams6110]

Agreed. URLs as an identifier are completely alien to non-technical folks. Even I think the notion is odd. They just don't make any sense. Plus they are hard to type correctly. Email addresses don't have these problems.

[reidrac]

Although I think you're right, I can't understand why they didn't try to "fix" OpenID and started a new thing instead.

http://xkcd.com/927/

That said, I'd love they succeed and we have finally something that works well and it's not under company-X's control.

[fmarier]

One of the reasons why we couldn't just "fix" OpenID is that we wanted a scheme that would be privacy-sensitive.

With OpenID, the result of the site redirecting you to the IdP (and then the IdP redirecting you back to the site) is that the IdP can get a trail of every website you're trying to log into. That's pretty fundamental to the way OpenID is designed.

[wmf]

In OpenID you have to enter your IDP URL and then optionally sign in to the IDP.

In Persona you will just click a button (because your browser knows your IDP) and then optionally sign in to your IDP. A huge difference.