I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol.

This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overloaded website with some problematic assumptions ladled in.

This creates a significant barrier to adoption. Many entities just won't bother: not only does it ask an apex A record to serve actual content (usually a mistake) but it requires the primary web host of a registerable domain, usually a trademark or brand identity, to carry technical material, definitely a clash of concerns.

(Why? In many companies of reasonable size, the website is managed by a completely different group of people - often a marketing team - to the internal identity service. Then, even if one team convinces to the other to install the browserid file, there is a possibility of it being deleted it by mistake during the next site refresh.)

I had hoped to find an intermediate step where a DNS SRV lookup was used to first locate the host delivering the browserid file. This follows the federated structure of email rather more closely and allows the identity service to be independent of the corporate brochureware. Even better - if the SRV lookup could be signed with DNSSEC, the transfer itself can be protected with DANE. The whole thing becomes manageable as a simple, separate unit of technology. It is thus rather more likely to gain the support of system administrators.

How is this different from OpenID?

EDIT: Seriously, this question was downvoted within two minutes? Why?

EDIT again: The best I've been able to come up with by reading the comments and docs is that they attempt to solve the same problem, but OpenID is based on the backend of the website you're logging into issuing a request to the auth server over HTTP, while Persona has the auth server issue a very-short-duration cert for a public key generated by the client.

I haven't look at the specs deeply, but it would be nice to have a system that did not need any kind of server at all, but the browser itself could be the Persona identity provider. The actual local data needed to pull it off could be replicated (encrypted) to cloud storage so it would work across all your devices and browsers, but the actual profile data itself would never be readable by the servers.

I started looking at the feasibility of building something like Persona into a 'serverless' social network a while ago using Broadcast Encryption techniques to define social sharing groups with revocation (de-friending) and Identity Based Encryption, but it seems like the state of the art IBE always requires a trusted server somewhere. But someone with more expertise in cryptography than me can maybe make it work. My original essay that prompted it (http://timepedia.blogspot.com/2008/05/decentralizing-web.htm...) based on the sad state of affairs these days where everything is non-federated.

Currently wondering the most sensible approach to make a single-user website support this protocol, so that I can make my email address (the only valid email address at my domain) support Persona natively. I don't really want to have to set up a username/password system with a single user. I'd almost prefer to manually hand my identity's private key to each browser I want to use. I wonder how much work it would take to write a Firefox extension that does this and uses Sync to snychronize the key between browsers?

Outstanding work, Mozilla. Parallel to when they broke the I-E monopoly, Mozilla is truly impressive lately.

Best way to support the new creativity surge by Mozilla - re-adopt Firefox as your MAIN browser.

With each search worth $1 (approximately), every time you search using Firfox, Mozilla receives $1. (payment by Google, for using their search engine)

Mozilla currently receives $300 million/year via search. Increasing search $ income ... rewards Mozilla as the most open platform and amongst the most innovative organizations on Earth.

Email has been the identity backbone for a long time. Persona supports multiple emails. This makes maintaining multiple identities even easier. A great alternative to identity trackers.

Great work Mozilla team, very eager to see this catch on in the coming years. Would be great if startups could get on board with it so the larger giants will be swayed to follow suit.

I still have a funny feeling about the robustness of Persona. For instance - let's say one of my emails gets hacked, my crappy Yahoo email. Does that give them access to my other Persona accounts? Would I (or anyone else) be able to know if the account is compromised? Normally you change your password and that's the end of it, but I'm not sure what happens with Persona.

What if my kid brother uses my computer - wouldn't he have access to any site that allows Persona logins? How do you lock it down?

It's hard not to respect Mozilla in 2013. I know i've personally moved away from Chrome back to FireFox. Mozilla seems like a young Google in a way.

http://www.getpersonas.com/en-US/ I have been confused by the distinction between these two for the longest time, and I'm hardly alone. Any plans to rename one or the other?

One nitpick about the current implementation: It was hard for me to know if I already had a Persona ID. I'm still not sure. I ended up "resetting" my Persona password to log into Trovebox. I have no idea if this actually created my Persona ID by doing so, or if I had one before. A developer like me might realize that this is idempotent and just go ahead, but your ordinary joe user might be put off.

I'm building this into the authentication scheme for my company's new application. It's remarkably easy to get started with. The team did a great job of making it solid and simple.

Persona is nice, because it is simple. It is still important to note that it is an alternative mostly to: "Trust that a user being able to read an email address is proof authenticating said user" -- in other words sites using it have no expectation that the user need any form of authentication before being issued a persona (Similar to eg: shared mail accounts -- where having access to the email does not identify you as a single person/user -- rather as a group of users -- which is subtly different).

Additionally without any form of single sign out/invalidation of private keys/session certificates other than expiration (please correct me if I've missed something wrt sign-out/invalidation) -- persona is in some ways less secure than "trust the mailbox": Even if you change your password/secret key -- any (stolen) signed session certificate (aka token/ticket in most other systems) will remain valid as far as the authorizing site is concerned.

This is similar to a stolen cookie -- except the site cannot decide how long the certificate is valid -- the identity provider does. So if somedomain.net signs certificates valid for a year, the only thing you can do as a site allowing persona logins, is mark said domain as "not trustworthy enough" -- and disallow logins.

This is "fine" as long as Persona isn't used for anything "serious" -- however with social engineering attacks, anything that to the end users appears to be proof of identity can be used to escalate privileges ("He sent me a hipsterchat-message on kewlchat.net -- so I reset the RDP-password like he requested").

I do think moving identity management "closer" to the user is good -- let the ISP, the various organizations the user is identified with vet and administer the user database -- but for the general use case -- we also need some form of trust between the sites, and the iDPs. Shibboleth[1] is one approach to this -- but it is more complicated that Persona, and has more overhead.

Personally I'd like to see a solution based around x509 certs and organizations like https://cacert.org -- but for that to work we need browsers to get better at handling cerificates. That is -- we need a user friendly way to manage identities based around x509 -- and we need browsers and servers to expect to validate both server and client certificates. Unfortunately such validation will entail a lot of problems with expired certs etc... it's not a trivial problem to solve in practice.

[1] http://shibboleth.net/

I don't understand how this is an advantage over just using email address as username with a password, like many sites do already. Can someone please explain the benefit?

[Edit: message to user Anonymous09, who replied to me below - you appear to have been hellbanned since the past three weeks. Thought you ought to know.]

> Of course, in the long term, Persona is meant to be distributed: alice@example.com should be verified and certified by the administrators of example.com. If example.com wants to use 2-digit passwords, they can. If they want to use retinal scans powered by your webcam, they can. It’s up to them. With each domain able to customize its authentication protocol with its users, the Web becomes more secure.

How would a 2-digit password make the web more secure?

Let's say I allow users to authenticate into my website with Persona, and I accept alice@example.com--whose 2 digit password is brute-forced the next day. Now whoever got into Alice's account has elevated permissions in my web app too. Great. If I had just stuck with my own authentication scheme at least I could have enforced some minimum complexity.

I hacked together a PhoneGap plugin so you can easily use Persona to log into your mobile apps https://github.com/couchbaselabs/cordova-browserid

I think this is an easier protocol for devs than OpenId or Facebook Connect.

Can anybody explain exactly what is meant by "distributed" here?

Is Persona reviving the old Microsoft Passport?

Microsoft first implemented this in early 2000s, I remember Microsoft Passport marketing the single sign-on feature, it did not catch up.

http://www.nytimes.com/2001/09/20/technology/20SOFT.html

I tried to boot the example app eyedee.me and it's unable to find this tarball from the package.json: https://github.com/benadida/node-client-sessions/tarball/92f...

Note: both 2 digits passwords and webcam based retina scans are terribly weak. Always upsets me when sarcasm like this is used, and the author is horribly wrong;-)

How is this different from WebFinger?

And a more detailed question - what is Mozilla's political strategy for getting adoption?

I hope they succeed!

Web technology (http and relatives) was not meant to do this. Can do it? of course, but will do it badly..

Its time to wake up, and see that we need new kinds of technology to keep up evolving

Its like glue wings in a old car and say that it is a plain and can fly..

The idea is good, and we need it badly, but the technology infrastructure its based on is weak for this scenario

Am I the only one to read this as 'Persona is disturbed'?

very cool, looking forward to a more widespread adoption!

It sounds great both for users and for devs which, I'm sure, is going to help it take off.

However I've got one question: was this conceived from the start with security in mind and is it simple enough as to not be plagued with the countless security issues which product that are too complex inevitably run into?

I'm thinking, for example, of the various recent OAuth SNAFUs.

undefined

Mozilla

building stuff you don't need today