
Persona is distributed. Today. - charlieok
http://identity.mozilla.com/post/46374271364/persona-is-distributed-today
======
inopinatus
I've just read through the Persona protocol specification document at
[https://github.com/mozilla/id-
specs/blob/prod/browserid/inde...](https://github.com/mozilla/id-
specs/blob/prod/browserid/index.md) 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.

~~~
wmf
Can JavaScript look up a SRV record?

~~~
inopinatus
Javascript can (ISTR there is a pure JS DNS library for node) but perhaps not
in the browser without specific browser support. You can say the same about
trustworthy crypto, incidentally.

SRV is definitely the ideal record. In this case I can see why a pure HTTP
approach was chosen (it avoids browser dependancies) and it irks me that
developers of web-based tools tend to develop inside the HTTP bubble rather
than using the broad and highly capable infrastructure of the Internet,
because this kind of constraining outcome is the result.

SRV would be an excellent choice for HTTP/2.0 as well, rescuing us all from
apex quasi-CNAME hacks and the like.

However in my initial remark you can substitute in the use of "a well-known
subdomain"[1] for "SRV record" and still achieve a better separation of
concerns than simply using the RHS of the identity string.

[1] c.f. DKIM's slightly hackish but effective use of an intermediate
underscore to denote infrastructure DNS entries. Won't work for A records
though IIRC.

------
csense
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.

~~~
martinced
I didn't downvote it but I think I know why: there's a huge wave of negativity
on HN and your question sounds like criticism.

There are ways to formulate the same question which would be much nicer and
less negative, for example:

"It's great to see other solutions providing things similar to OpenID. Can
anyone explain what are the differences with OpenID?"

Simply writing: "How is this different from XXX?" just sounds rude and
negative.

~~~
freshhawk
Understand where you are coming from but this is an overreaction. An HN where
you have to wrap a plain, absolutely neutral question like this in a bunch of
false praise or meaningless filler words is a much much worse place than the
HN that might be overly critical/negative by default (and this perception is
partly false, reinforced by the cultural belief that questions are attacks).

~~~
yellowseed
On the other hand, paraphrasing what you've said to make a counter-argument:
an HN where a peaceful, respectful atmosphere is sustained by thoughtfully
worded comments is a much much worse place than an HN where dry, hastily
worded comments take some heat.

~~~
Helianthus
Honestly, I'm not sure if your counter argument is intended to be ironic.

I'm used to an Internet where you're not required to be so goddamned polite.
Seems to me it becomes the spidery veneer of Silicon Valley networking;
insincere, self-interested, and a corruption of what it means to be 'nice.'

~~~
mindcrime
What's wrong with being polite? It doesn't cost any extra and there are a lot
of people who appreciate it.

~~~
Helianthus
Not anything wrong with being polite. Plenty wrong with requiring people to be
polite.

~~~
cpeterso
You're not required to be polite, but you may be downvoted.

~~~
Helianthus
_shrug_ yep. I'm saying more that there can be an atmosphere of required
politeness.

I mean, look; the OP asked a really good, terse question and got downvoted
presumably because it was 'rude.' That's just silly.

~~~
18pfsmt
I'm curious how the GP's question can be construed as "good" when there exists
a blog post that explicitly addresses it. This indicates the GP didn't do even
cursory research to determine the answer for themselves. In other words, the
GP was lazy, expecting to be hand-fed, and was down-voted as a result.

~~~
freshhawk
Ah! If he was downvoted for asking an easily google-able question then that's
reasonable and end of discussion.

The discussion here started because of the statement that he was probably
downvoted because "how is this different from X?" is interpreted as "This is
stupid, we already have X."

------
cromwellian
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...](http://timepedia.blogspot.com/2008/05/decentralizing-web.html))
based on the sad state of affairs these days where everything is non-
federated.

~~~
mook
That would end up requiring your identity to be a key of some sort, though,
since ultimately the thing you're logging into needs to check _something_.
Email-like things are useful because somebody has to control the domain; if
you don't have that, it's harder to establish something. Of course, you can
say things like "Hi, I'm random prime number 534473", but that's much less
memorable...

~~~
drdaeman
The displayed name is a bit different concept from identity. It's like a
server and it's DNS name.

The point is, nothing prevents the site from knowing me as
70BD6432E50DFB65FF679B32364C3C7840DE4453, but displaying me everywhere as
"Aleksey".

------
JoshTriplett
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?

~~~
rfk
I recently set up my personal domain as an identity provider, using static
HTML/javascript files and a bit of crypto:

    
    
      https://www.rfk.id.au/blog/entry/persona-identity-provider/
    

There are some things to be mindful of w.r.t. security in this approach, but
it seems to work very nicely for me.

~~~
vdm
Clickable: <https://www.rfk.id.au/blog/entry/persona-identity-provider/>

------
teawithcarl
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.

~~~
badida
Thanks!

Another good way to help Mozilla make the Web better for all is to implement
Persona on web sites you build. It's easy and respects your users. Here's how
you can do it in an hour or less:

<https://developer.mozilla.org/en-US/docs/persona>

~~~
coldpie
Studying, understanding, and maybe implementing this looks like a fun weekend
project. Thanks!

------
namespace
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.

------
jjcm
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.

------
lubujackson
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?

~~~
StavrosK
> Does that give them access to my other Persona accounts?

No, it gives them access to whatever site you registered with your Yahoo!
account. (EDIT: If you use the temporary bridge they implement, they could get
access to your other accounts if they got access to the bridge. This won't
happen if your email provider supports Persona natively).

> Would I (or anyone else) be able to know if the account is compromised?

Yahoo! probably would, and could tell you.

> Normally you change your password and that's the end of it, but I'm not sure
> what happens with Persona.

You change your password and that's the end of it.

> 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?

Just log out of your email provider.

Really, Persona is just a way to make your email provider your authenticator.
It's "Facebook Connect" for your email provider.

Security-wise, if your email gets hacked, what happens is what would happen
anyway, since almost every site can request a password reset by emailing you.
The attacker has access to that anyway. Persona removes the hassle of
remembering one password per account by letting the site ask your email
provider if they know you.

~~~
jessaustin
_Just log out of your email provider._

Really? Is this enough? Elsewhere in this discussion, mention is made of
_delegating_ to a different Persona provider. How will your browser (which,
near as I can tell, is directing traffic for this protocol, either natively or
through an extension) know that clicking "log out" on an email app should make
it stop using certs associated with a different Persona app? Even if it were
the same provider, perhaps under a different subdomain, this link between
email app and everything else seems pretty tenuous. I think there should be an
obvious switch to throw in the browser.

Perhaps I'm really misunderstanding things; please advise.

~~~
StavrosK
It's the same as Facebook Connect. Logging out of Facebook doesn't log you out
of all the connected sites, but it does prevent you from logging in to others,
which is what the GP was asking.

~~~
jessaustin
That is not my interpretation of the original question, but thanks for
clarifying.

This discussion points to a potential for a sort of confusion we've seen
before. It used to be a big user education problem to get all users to press
the "log out" button when they were done using a site, especially on "public"
computers. To some people maybe this is still a problem? (Actually, before
that it was a bit of a struggle getting sites to implement "log out"
functionality, and we just had session cookies multiplying everywhere.)

If my browser has stored Persona certs associated with various sites but gives
me no visual indication of that, it's very possible that I might become
confused about where and whether I'm logged in. The various sites to which I'm
logged in might have different requirements for auto-logout, etc. It seems
that Persona is trying to ignore these issues a bit by saying "this is just
for low-value authentication", but fixing the problem seems possible.
Incorporating Persona functionality into the browser should allow better
security notifications than are possible just through HTML/JS/CSS from
individual sites. The user should have the option to easily throw away certs
(i.e. without clicking through a bunch of "Settings" dialogs), and should have
the information she needs to know when to do that.

~~~
StavrosK
Oh, yes. Persona now integrates with logouts as well, so they know when you
click "log out" from a site and the user agent can prompt the user to log out
of Persona completely or just that site. I don't think they can tell _every_
site you're logged into to log you out by logging out from one site, though.

~~~
jessaustin
That's really interesting. I had previously assumed that the stored cert was
per-user and available for many sites, with each site using its stored cert
from the Persona provider to validate the user cert from the client. (I'm not
sure _why_ I assumed that.) Now I see that it's per-user _and_ per-site. The
more I learn the more I like Persona.

------
epa
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.

~~~
MatthewPhillips
Same here, switched to Aurora permanently and haven't had any issues. Like
that it looks native to the OS you are using. And had forgotten how much
better the awesomebar is.

~~~
epa
Thanks for sharing, did not realize ver20 was in testing.

------
eliasmacpherson
<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?

~~~
mcpherrinm
The plan was to deprecate personas as a name for background themes.

<https://addons.mozilla.org/en-US/firefox/themes/> doesn't use the word
"persona" anywhere I can see any more.

I don't know why getpersonas.com hasn't been axe-murdered yet. (Edit: info on
migration is here, [https://blog.mozilla.org/addons/2013/02/28/getpersonas-
com-m...](https://blog.mozilla.org/addons/2013/02/28/getpersonas-com-
migration-update/) and is ongoing)

------
stcredzero
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.

------
Ixiaus
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.

------
e12e
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/>

~~~
daemon13
FYI, latest stable Firefox says this:

You have asked Firefox to connect securely to cacert.org, but we can't confirm
that your connection is secure. Normally, when you try to connect securely,
sites will present trusted identification to prove that you are going to the
right place. However, this site's identity can't be verified.

~~~
jessaustin
_FYI, latest stable Firefox says..._

I'm sure e12e knows this. If you don't want to see that message, you need to
install the CAcert root certificate in your browser or OS. While you're doing
that, take a look at all the root certificates that are already in there: you
might decide CAcert is more trustworthy than most of those organizations!

~~~
e12e
Indeed. For some painful background, see eg:

    
    
      https://bugzilla.mozilla.org/show_bug.cgi?id=215243
    

A fundamental problem with x509 and Certificate Authorities as it currently
stands wrt https and browsers, is that all users almost randomly trust a few
organizations to issue certificates -- and get warned of any other
certificates -- but there is no decision on part of the user who they trust --
just some vague delegation to browser vendors on vetting CAs.

For some more background, I suggest reading:

    
    
      http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
    

edit: Also, I tend to forget that cacert isn't included, as Debian are among
the distributions that include them as a CA:

    
    
      http://wiki.cacert.org/InclusionStatus

------
yjyft846jh
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.]

~~~
whatshisface
If I knew your email, I could make an account on a website in your name
without you knowing.

~~~
yjyft846jh
I don't see how that would cause a problem. If the website ever sent an email
to me, I would know about it and just be able to do password recovery and
delete the account. If the website never sends an email, it's of no
inconvenience to me.

In that case is this not just functionally equivalent to sending a validation
email upon account creation, as many sites do already?

------
snowwrestler
> 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.

~~~
marcioaguiar
He was just making a point that authentication protocol is a domain choice
(from 2-digit passwords to retinal scan).

It's up to the users to trust the domain he is going to use as identity. Just
like many people trust Facebook Connect.

~~~
DannyBee
But facebook at least has standards (or is believed to, i have no knowledge).

Why should, for example, google, ever trust, say, fred's discount web hosting,
enough to let them login to gmail?

Not in the sense of "these guys could compromise gmail" (which is a worry in
certain elevated privileges contexts), but more in the sense that "people are
still going to say 'my gmail got hacked'" if their gmail gets hacked because
they made bad choices. They do now!

Google will still get blamed, and their only real option is to decide not to
accept certain identity providers (IE blacklist or whitelist). Long term, how
are we not going to end up with just a mishmash of who accepts what?

I've read a bunch of docs on persona, and it doesn't seem to address this past
stating how wonderful user choice is, and how making this more distributed
will make the web more secure (which seems, well, wrong)

~~~
shardling
For most people, they _already_ use an email account to authenticate. Pretty
much every single login I have, someone with access to my primary email
account could co-opt with the snap of their fingers.

If your email provider is vulnerable, _you're already fucked_ , except for
those accounts which use two-factor auth. And persona isn't intended for your
bank/etc.

~~~
DannyBee
But your argument is essentially "we're just as fucked as we are now". Okay,
so then, uh, what problem have we solved?

Now we are fucked, after we're just as fucked but not using facebook as the
identity provider?

I guess i don't see this as much of an improvement? Honestly, i'm not trying
to be snarky. I'm just trying to understand why this seems to be presented as
leaps and bounds above what we have now when it seems to be just as bad, just
more distributed :)

~~~
shardling
No, _if_ you choose a shitty email provider you're fucked. But currenty,
you're also fucked on a site by site basis if whoever you have an account
stores your password in plaintext/etc.

It's an improvement on having dozens of accounts on dozens of sites, both from
a security standpoint and a UX one.

------
jchrisa
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.

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

~~~
enaeseth
Online login services are generally many-to-one. For example, _many_ sites
accept Facebook login, but for a user to log in that way, there is only _one_
identity provider they can use: Facebook. If you don't have a Facebook
account, or don't want the site in question to have any access to it, you
can't use Facebook login.

When the article says "distributed", it means Persona is many-to- _many_. Any
domain can implement the protocol, so when a site accepts Persona login, you
can choose from _many_ identity providers – including your own, if you're
industrious and want to set one up for your domain. Most people are using
Mozilla's service today, but the idea is that email providers like gmail will
implement it themselves in the future.

------
supervillain
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>

~~~
AndrewDucker
Except that Passport meant using a single authority (Microsoft), whereas
Persona is entirely federated (once individual domains opt-in).

------
themgt
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...](https://github.com/benadida/node-client-
sessions/tarball/92fff32)

~~~
badida
Sorry, that's my bad. It's fixed now if you pull the latest eyedee.me.

~~~
themgt
Thanks! I ran into one other issue (PR:
<https://github.com/mozilla/eyedee.me/pull/27>) but was otherwise able to get
it booted in our Heroku-esque environment: <http://eyedee-me.a.pogoapp.com/>

------
zobzu
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;-)

------
frabcus
How is this different from WebFinger?

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

I hope they succeed!

------
oscargrouch
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

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

------
tiziano88
very cool, looking forward to a more widespread adoption!

------
martinced
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.

~~~
callahad
> _was this conceived from the start with security in mind_

Absolutely. Point 4 in the Mozilla Manifesto: "Individuals' security on the
Internet is fundamental and cannot be treated as optional."
(<http://www.mozilla.org/about/manifesto.en.html#principles>)

> _is it simple enough as to not be plagued with the countless security issues
> which product that are too complex inevitably run into?_

We hope so. Persona's design and implementation have gone through several
internal and external audits, and thus far it appears sound. Keeping
everything as simple as possible is a core goal.

------
jcroll
__Mozilla __

building stuff you don't need _today_

