
Why Mozilla Persona is the right answer to the question of Identity - jalada
http://labs.newsint.co.uk/blog/2012/10/why-mozilla-persona-is-the-right-answer-to-the-question-of-identity/
======
ecaron
The biggest problem with Mozilla's Persona is the branding of it. Until they
are able to get a handle on the branding-related issues, it can't get off the
ground:

* Logo is ambiguous and looks like a generic button

* "Mozilla" in the name instantly steers away other browsers

We've implemented it on LinkUp (<https://www.linkup.com/account/>), love the
technology, and REALLY hope the adoption of it takes off - but until I can
explain it to a user in 2 sentences, it won't claim the throne.

~~~
masklinn
> We've implemented it on LinkUp (<https://www.linkup.com/account/>)

What's your experience with that? Implementing OpenID tends to not be very fun
(whether as a consumer or as a provider), is Persona better?

~~~
ecaron
I did OpenID early on in the site (nobody understood it), RPXNow/JanRain (more
than we could afford for fewer features than we needed), and finally our own
solution that does OAuth* for the various providers and Persona.

I love Persona. I want a Persona shirt and tattoo. OpenID was just a bit
harder, but had nowhere near the payout that using Persona offers. The only
burden of Persona is the auto-login/logout handling, which is a good thing in
the long-run but in the short-run involves tracking down all your login/logout
methods and making sure they all react properly.

*OAuth integration is a nasty mess of nastiness that I can't bring up w/o derailing this entire conversation. If you want to chat about that train-wreck, email me.

------
po
Have any of the other major browsers made any public statements about
BrowserID or Persona? How about Paul Irish or other developer relations type
people? Somebody has to have said something even if it was 'unofficial'.

------
csixty4
I'm genuinely curious. I did my bachelor's thesis on the identity ecosystem. I
was an early adopter of CardSpace, iNames, OpenID, and any other digital
identity solution that came along and I watched them wither from lack of
interest. I was continually told that passwords are good enough, and that
nobody is interested in a digital identity solution.

Persona doesn't sound that different from solutions that came before it. It
sounds really similar to CardSpace, especially with how easily you can
integrate it into a site. So why would Persona have a chance at succeeding
where so many others have failed? Is it just a matter of timing, coming after
some major password leaks, or are they hoping the Mozilla name will buy them
support from the developer community?

~~~
Yoric
I am not familiar with CardSpaces, but a considerable difference between
OpenID and Persona is a matter of anonymity. With OpenID, your OpenID provider
(e.g. Google) can track you as you log to your various accounts. By
opposition, with Persona, the Persona provider does not get any meaningful
information that can be used to blow your anonymity.

~~~
csixty4
tl;dr - Here's a video demonstration: <http://youtu.be/0_6rC025sK0?t=34m16s>

CardSpace was a Microsoft project led by Kim Cameron, the godfather of digital
identity. They originally wanted to make it part of Windows Vista, but it was
dropped for lack of interest. It was an open standard, and there were browser
plugins to make it work in other browsers and operating systems. Microsoft
knew they couldn't make it a Windows-only thing if they wanted people adopting
it. They just wanted to be at the forefront of security for once.

A developer would add meta tags to a site's login page with a URL to post
identity info to and a list of information it's requesting. That would trigger
the browser (or plugin) to open a modal display of identity "cards", which the
user could choose from. Then it would show what information the site requested
and they could deny individual pieces of info. The data would be posted back
to the site, along with a unique signature for that user & site.

Cards could be self-issued or issued by a third party, like your employer or
bank. They could have graphical backgrounds applied so they looked more like
ID cards or credit cards. It was a great UI for identity, and easy for
developers to use. But I think the Microsoft name tarnished it. I know people
outside the identity community were making comments about how this was
Microsoft's attempt to become Big Brother & so forth, even though Microsoft
was completely out of the communication loop between the user and the site.

~~~
wmf
You lost at "browser plugins". Persona uses a JS shim that requires no plugins
or browser changes.

~~~
pgeorgi
CardSpace was 2003ish.. "browser plugins" were the standard option for all
kind of things, while JS shims merely provided <blink> on non-MS browsers.

------
xyzzy123
Some thoughts from a privacy perspective:

Technically, I think this is vastly superior to the currently available login
solutions. But one of the things I never liked about centralised or even
federated auth was all the links between accounts.

One thing I don't like: ideally, all a site should need to know is that I'm
the same entity I claimed to be last time. I only want to be locally unique on
the site, not a globally unique value which can be correlated between sites.
Also, it should be my choice as to whether I disclose my email address to
sites.

In practice, email addresses are usually required for signups, and it's easy
enough to create throwaways. I can absolutely see why it was designed this
way, but it would still be nicer if the protocol did not disclose more than it
needed to.

In this case, the email address (and equivalently the public key the browser
holds for that email address) can be correlated between sites.

I thought a bit about making a mailinator-like IDP (i.e. a convenient way to
hack around this). Unfortunately, I can't see a good way right now to get both
these properties at the same time:

a) The IDP doesn't know what site (RP) the user is logging in to b) The IDP
can auto-generate a persistent unique id for each site (RP) (e.g:
<type-4-uuid>@idp...)

I guess the degenerate case would be an IDP which signs <anything@idp...>. Not
super useful, but OK for sites where you didn't really want to have a login
anyway, I guess... true mailinator style, but for logins.

A few other points:

* Would also be good to have a privacy option to force the browser to generate a fresh keypair every time a new user certificate is requested; at least then we can only be tracked by identity and not so much by device over time as well.

* There is the obvious timing attack, where if the RP doesn't cache the IDP's public key, it may disclose what site the user is logging in to, to the IDP.

* Also, verifier.persona.org will know who is logging in where, if you use their JS (since you pass the assertion and the audience via REST).

* I am not 100% sure at this stage what stops a malicious user from simply asking the browser to perform an identity assertion and grabbing email (or clickjacking the user into doing it) when they already have a user cert; haven't looked at it in depth though.

------
gwillen
I worry about Persona, for exactly the same reason OpenID chose the design it
did: It's a serious mistake to permanently tie email to identity.

It's still possible within the framework of Persona to fix this -- the browser
/ identity provider needs to support freshly-generated opaque "email
addresses" for each new site that needs a login. This prevents tracking and
spam problems, but will also require both providers and relying parties to
downplay the 'email address' token in the UI, which I fear is far too much to
ask.

~~~
StavrosK
Just use <somethinghere>@mockmyid.com.

It doesn't even ask for a password. I don't think it would be too much work to
create a Persona service like 33mail.com, which provides your own domain for
email _and_ authentication. That way, you would enter
"myaddress@domain.33mail.com", the site would send you there for auth, 33mail
would reply that you are logged in to your account (if you were, obviously),
and that'd be all.

------
hackerboos
Persona - An identity system by Mozilla

Personas - Skins for the Firefox Web Browser

This is an issue that needs to be resolved.

~~~
ecaron
They've resolved it in planning ([http://www.ghacks.net/2012/03/02/mozilla-
personas-renamed-to...](http://www.ghacks.net/2012/03/02/mozilla-personas-
renamed-to-background-themes/)), but the implementation just hasn't been
completed. Yet.

"To sum it up:

* BrowserID renamed to Mozilla Persona

* Personas renamed to Background Themes

* Themes are now Complete Themes"

~~~
petitmiam
Background Themes/Complete Themes - sounds like they just created a new
problem. Throwing the word 'theme' in there for backgrounds is just asking for
confusion.

I think most people understand Wallpapers (Backgrounds) / Themes.

------
yafujifide
I don't understand why this is better than just using a public/private key to
represent identity. Why involve the email operator? Why can't I log in by
having my browser sign a certificate, without involving a third party at all?

~~~
sergiotapia
Because my mother doesn't give two shits about public/private key. She just
wants to authenticate and the easiest way both logistically and mentally to do
that is to just sign into her email.

I fully support this idea from Mozilla and I hope it kills OpenID, as even
that's a pain in the ass sometimes.

~~~
Ntrails
Surely the real win here is the massive reduction in password re-use on 'less
secure' environments.

Obviously google/microsoft etc are not immune to screwing up and having their
database hacked - but I'd rather put all my eggs in that basket than having a
single egg in lots of baskets with differing levels of security that
subsequently enable access to all of my eggs anyway and...

Yeah. So the eggs metaphor doesn't really work. Sorry.

------
ernesth
> OpenID uses URLs as identities.

True, the fact that URLs identify them confuses some people. However,
<http://> being usually superfluous, I don't see why roger.example.com is more
confusing than roger@example.com.

> Most sites would like at least an email address to be able to contact you,
> so will almost always require an additional step after logging in for the
> first time.

And openId provides an email if the site asks for it.

> OpenID is a jarring login process.

The difference is that the provider page is a full page rather than a popup?

> Both OpenID and oAuth allow your identity provider (be it Google, Facebook,
> Twitter) to track every website you sign in to.

So does mozilla persona as your identity provider is your browser ! I remember
an opera unite app that acted as an openId provider. How is Persona
different/better than that?

> oAuth is complicated for developers to implement [...] several versions of
> the protocol, [...]

That is true. And it will also be true of persona in two years when you will
have to support firefox15 to 20, chrome 33 to 35, ie11, opera14, opera15,
webkit-beta-nameless-browser, webkit-alpha-nameless-browser and others' own
versions of persona

~~~
MatthewPhillips
> True, the fact that URLs identify them confuses some people. However,
> <http://> being usually superfluous, I don't see why roger.example.com is
> more confusing than roger@example.com.

Because roger.example.com is not what most people's OpenID is. Google uses the
same OpenID url for all accounts. If you have a Gmail account, your OpenID URL
is: <https://www.google.com/accounts/o8/id>

How the hell can you not find that confusing?

~~~
drivebyacct2
I have been confused about that every, single, damn, time I've ever used
Google OpenID, whether it was supporting it or using it. Thanks for opening my
eyes.

I knew I liked BrowserID and you've pointed out around reason why.

------
GregWright
I would love to use this, but apps I work on are both web browser based and
native clients. Persona does not _yet_ work with native apps (Android, iOS
native apps); it only supports browser based auth right now.

Browser only auth doesn't get me all the way there. I can look at wrapping
UIWebKit, or whatever, in my apps, but I bet I am just asking for some hurt.
:-)

------
lifeisstillgood
This just beats OpenID hands down. And I will be very interested to see how
fast Google et al support it.

I think they may be a bit evil.

------
alter8
The recent wave of password and hash theft might become an incentive to move
to this login method. I was skeptic about the possibility of BrowserID
catching on, thinking the Google/Twitter/FB wouldn't give up tracking users
with their ID methods. But if there is a way to make this widespread (though I
can't imagine how) I'd really like it to happen.

Will Mozilla provide native support or an extension? Or they feel like it
would hurt if someone could implement a bad login page that still works if the
browser has native support?

~~~
romaniv
Password/hash thefts have been happening for as long as there have been
systems with passwords. What changed recently is that we now have centralized
services with huge numbers of important accounts. There are more service with
large number of accounts and more services that affect multiple aspects of
your digital life. When someone steals hashes from _those_ , the press and
people are more likely to notice.

I think most people overemphasize the importance of the particular
authentication scheme used and overlook the problems created by extreme
centralization of stuff.

------
drdaeman
This Persona/BrowserID kludge makes me sick. I don't get why everyone is so
optimistic about it. I believe there's absolutely no reason why one just can't
be a source of their own identity (as it naturally happens), with so-called
"identity providers" actually being "identity notaries."

In BrowserID they _do_ generate keypair, but then tie identity not to it, but
to an email address, something user lends, but never actually possesses.
Completely the same as with OpenID, where identity is tied to URI. Actually,
the only change is URI scheme part: http/https to mailto — which is nice UX-
wise, but that's about all the advantages.

OpenID was _heavily_ criticized for that (remember all those "did I sign up
with Google or Facebook?", URI changes/account rename issues, identity
providers being temporarily down, and so on?), and now those who criticized
OpenID are praising system that have _most_ of the same problems.

I can only hope Persona would silently fail and never gain any significant
popularity, so users won't have to struggle with another hype wave, to only
lose their trust (if there's any left) in non-centralized identity systems.

------
dreamdu5t
Chrome, IE, and Opera need to natively incorporate browserid ASAP.

Please, put your egos away and get this done for the sake of everyone who uses
the web.

------
jellicle
A well-crafted solution desperately in search of a problem to solve.

~~~
nine_k
If registering at yet another site (forum, online store, government site, etc)
and remembering the password when you get back to it 2-3 month after is not a
problem for you, I admire your memory. Or maybe you're not visiting these
types of sites as much as I do.

~~~
Revisor
Another solution to this is a password manager, eg Keepass. It still
centralizes your identity under one roof, in the encrypted DB, but only
locally.

~~~
LeonidasXIV
But the overhead is much larger and let's be honest, this solution is only
used by a tiny minority of (mostly tech) users. Mozilla Persona could be used
by everybody because for the end user it is exactly as complex/easy as it is
currently or even easier.

------
mightytightywty
Tying email addresses to a user's identity is a terrible idea.

\- I don't want to give my email address to every site I use. It should be
available to the site only if I approve their request.

\- I use a unique email address for every site that needs one.

\- What if I want to start using a new email address?

~~~
Arelius
I wouldn't actually say it's a terrible idea, for 99% of users it should work
better, faster, and easier for them, since -very- few people have the same
habits as you.

However, having said that, I do otherwise agree with you, I also don't want to
give my email out to all of them, and when I do, it may be one of a few
address, depending on how much I trust them, or care about the responses. I'm
given very little option in that regard.

~~~
nicolasp
> it may be one of a few address, depending on how much I trust them, or care
> about the responses. I'm given very little option in that regard.

You are given the choice of which email address you want to use to log in.
Isn't that exactly what you want?

------
lazyjones
I don't see a compelling reason, especially since I'm in the EU and don't want
my e-mail address, password and website usage statistics transferred to
Mozilla's servers in the US, where they can be accessed and possibly misused
by authorities.

~~~
jerf
Mozilla has the only implementation at the moment as they are still developing
it, but the intention is that any email provider can provide this in the
future. They have not written themselves into the spec. In fact they have
commented that the more successful this standard is, the less important they
become.

~~~
da_n
Commendable goals, but in my opinion somewhat conflicts with the 'Mozilla'
prefix in the name, if they hope to make it a widely adopted standard they
need to drop their branding and just call it 'Persona'.

~~~
whatusername
Read the article. The protocol is called BrowserID. The Mozilla service to try
and help adoption is called "Mozilla Persona"

------
peterwwillis
tl;dr Uses an e-mail address to make public key crypto easier. Sounds nice.

Unfortunately, most people fuck up PKI and now we're relying on a third party
(Mozilla) to authenticate all our logins.

You could also just implement client certificates without a third party. Issue
your users a cert when they register or log in. This would be similarly
"automatic" authentication without relying on Persona to be stable and secure
24/7. I wonder why they didn't just make a browser plug-in that simplifies
using client certificates (without the expense of supporting a highly reliable
3rd-party site and extra code to make it work)

~~~
JackC
_I wonder why they didn't just make a browser plug-in that simplifies using
client certificates (without the expense of supporting a highly reliable 3rd-
party site and extra code to make it work._

So the goal is basically: I have a computer at work, a computer at home, a
computer in my pocket, and a computer I just borrowed to check something at a
friend's house. I want to be able to go to the same random site on all four
devices and have it recognize that I am the same person, without (1)
remembering a special password for that site, or (2) trusting that site in any
way.

So there are two ways to do that. One involves generating a certificate on one
of my devices and somehow communicating it to the others without a central
authority. The other involves a central authority that each device can
communicate with.

The first way will be, let's say, extremely challenging to get working
reliably across all devices and platforms in a way that average users can
handle. So Mozilla went with an extremely flexible version of the second way.
It goes like this: users remember a Username and URL, in the form
Username@URL. They also remember a Password which is only shared with URL.
When I want to identify myself to that random website on any of my four
devices, Mozilla helps me get a verifiable statement from URL to send to the
random website that I am Username@URL.

There are two things mixed in to make it more likely this will take off.
First, users are already used to remembering Username@Url / Password
credentials, so they don't have to learn anything new to identify this way.
And second, because existing Username@Url identities are email addresses,
Mozilla can offer an intermediate identification service based on the ability
to receive email, until other identity servers come online.

TL;DR: By using an intermediate ID server and credentials that look like email
addresses, Mozilla has created a path to cross-device, cross-platform user ID
that solves the problems of user adoption, technical adoption, and
independence -- it can be implemented in existing browsers, understood by
existing users, and offers a clean transition to completely decentralized
identification. Very cool.

~~~
peterwwillis
This makes it easier for people to use one login for all the websites they
use. That also makes them inherently less secure.

Multiple accounts is a good idea because it creates separate security domains
which cannot be broken. You crack my Facebook password, there's no way you can
get into my completely separate Citibank account. The one-login-for-all model
is less secure because it centralizes your accounts into one general security
domain: the ID provider.

If you hadn't made it a requirement that you can use the computer at your
friend's house, this would be more secure, because you could keep your private
keys just on your trusted devices. But now you're on a foreign device and you
didn't bring your keys - so you have to either get them from your ID provider,
or generate new ones.

Now an attacker can either A. break into the ID provider and steal the keys
for _all the sites you use_ , or B. intercept the username/password login to
your ID provider.

The risk of A. is of course possible, plausible, and given the track record of
companies with the highest security reputations in the land being pwnd by lame
phishing expeditions, likely to actually work (eventually).

If you were using your home computer with the keys already stored in the
browser, B. would be impossible, but you're at a friend's house with no keys.
And my guess is there will be malware developed just to disable browser keys,
force a u/p login, collect the creds, and try all online banks using this
system to find your account and siphon funds. (This is exactly what malware
does today, only they usually use direct injection of your normal banking
browser sessions or steal saved logins)

Of course you can use separate accounts with Persona. They advertise you using
a work e-mail and personal e-mail to make separate accounts. But let's be
realistic: who the hell wants to complicate their logins further? People will
probably use one e-mail for all their accounts - _because it's easy_.

I have a solution for these security concerns. It's to _stop trying to making
security easy_. If you forced people instead to jump through hoops for the one
or two accounts which really need to be extra secure, they'll deal with it
(once) and get on with their lives.

Banking is one example. You can step a user through generating and storing a
client certificate, and then they never have to do it again until they use a
new computer. If they need access from outside their home (WHICH IS A BAD
IDEA, BUT ANYWAY,) they can use a temporary e-mailed login token which is only
good for one session and requires things like login rate limits, additional
identity verification, etc. We can do this today without any new technology.

Facebook, Twitter, etc aren't sensitive accounts and thus don't need
ridiculous security - Persona would be fine for these. Crack my social media
accounts, fine, but don't allow things like banks and e-mail accounts to be
linked as well. It's like clipping blank checks to your house or office keys.

------
eddieroger
I get that I'm probably not the target market for OpenID since I'm already
more tech-friendly than the average user, but I've never thought it was super
complicated or "jarring," to use the definition in the article. I set up the
URL on my web server years ago (thus securing me as more technical, I know),
but it's been great. I can change providers in the background, and I only need
to remember one URL. No more usernames or anything. Sure, it could be easier
and more widely adopted (chicken and egg), but I have thought it was
relatively pleasant for a while.

------
latchkey
I really want to see HN adopt Persona.

~~~
shardling
I'm a big fan of how they used to support OpenID but quietly dropped it,
locking me out of my original account.

No, wait, that was terrible!

------
wccrawford
I personally like OpenID, especially in combination with GMail. But if this is
easier for most users (and it seems to be) then I could be fan of it as well.

One thing that I don't see is what happens if I sign up as a user now (with my
GMail address) and then GMail later starts providing their own service,
instead of the fallback. Do I lose my account on all the services I signed
into?

~~~
takluyver
As I understand it, you're identified to the site by an email address. So if
GMail becomes an ID provider, you keep using the same identity, but with
Google confirming it rather than Mozilla. I'm by no means an expert, though.

~~~
wccrawford
Okay, so there's no token being passed? If someone manages to spoof the
system, they could be anyone and just accept my access request?

I haven't thought it all through, but it feels like there's a weakness there
that's just waiting to be exploited.

~~~
takluyver
I think there is a token being passed, but it's authentication, not identity.
It's a signed declaration that you own that identity, and it must be either
from the domain that issued it, or another source that the site you're
visiting specifically trusts (i.e. Mozilla, at present).

I trust Mozilla to have done a good job of this. If there's a weakness, it's
not going to be anything so obvious that you can see it from my stumbling
attempts to describe the protocol. If it sounds like there is, I'm probably
describing it wrong. Have a look at the details here: <http://lloyd.io/how-
browserid-works>

~~~
wccrawford
Thanks. That link explained it, and at least took care of my current worries.

------
mtgx
If this ever becomes popular, I can imagine law enforcement agencies will want
to link e-mail address to people even more, and mail vendors such as Google,
Yahoo and Microsoft will become a much more popular target for subpoenas and
such.

I just don't like the idea of all the passwords being centralized in one place
and being so very easy to obtain by the US Government.

------
Perceptes
I am really hoping this takes off. I'm currently implementing it in an app
and, although the API is a little awkward, it was pretty easy to do. The only
snag I've run into is that it has issues in Chrome if third-party cookies are
disabled.

------
leetreveil
I like the implementation but I don't like that it has a brand (Mozilla)
attached to it.

Stripe is doing this right, when you make a payment on a website you have no
idea that you're using Stripe.

~~~
shardling
I won't put credit card details into a site unless I have _some_ trust in the
system they're using. The lack of a brand isn't necessarily a good thing here.

In any case, the brand is for marketing to developers right now -- once
"Persona" becomes a thing in and of itself, this will be a nonissue.

------
hayksaakian
As good as it may be, I have a hard time seeing this grow beyond Mozilla
browsers, what with their reliance on browserid

~~~
scottlinux
Works in any modern browser. Check this out:
[https://developer.mozilla.org/en-
US/docs/persona/Browser_com...](https://developer.mozilla.org/en-
US/docs/persona/Browser_compatibility)

