
Announcing the First Beta Release of Persona - callahad
http://identity.mozilla.com/post/32395255498/announcing-the-first-beta-release-of-persona
======
Osiris
I just tried it on the Times Crossword page. The workflow is really simple and
elegant. I put in my email address. It took a second to determine there was no
Persona account, then asked for me to create a password. After that, I clicked
on an authorization link in my email account and as soon as I did that it
immediately logged me in. I clicked Log out and back in again and it
immediately recognized me and logged me in.

This is really what I was hoping to see with OpenID when it came out, but the
process to set up an account and get started is much more cumbersome.

I look forward to seeing native support for Persona in browsers.

~~~
notatoad
It does seem a pretty elegant way to log in, the only concern i have is that
it's kind of unclear what password i needed to use to login. I had already
created a browserID password at some point in the past, so when i went to the
times crossword and clicked sign in, i was prompted for a password. my first
thought was maybe i had already signed up for the times crossword, so i tried
the password i probably would have used to sign up for a site like that. nope,
but it said "authenticating with your email provider". So then i tried my
email password, thinking maybe it was integrating with my google account.
nope. Third try was the password i had used to sign up for persona.

Maybe in the future, if this sees wide adoption, they can get away with just
putting some mozilla branding in the corner, but for now there should really
be some explanatory text on the login window telling you that you need to
enter the password you created for mozilla persona, or this is just going to
confuse users.

~~~
Osiris
They've already stated that you'll be able to put your site logo and name into
the login box [1].

As far as the password, I thought it was pretty clear that the password they
are asking for is your Persona password, but maybe that's because I had just
signed up.

The point is that you'll only ever need one password, so it'll be great to be
able to have one strong password rather than tens of weaker ones.

[1] [http://identity.mozilla.com/post/32395255498/announcing-
the-...](http://identity.mozilla.com/post/32395255498/announcing-the-first-
beta-release-of-persona)

~~~
notatoad
>The point is that you'll only ever need one password

this will never be true. You'll only ever need one password _for mozilla
persona_. The user expectation will still be one password per site, and
allowing sites to brand the box will only make things even more confusing. It
needs a stronger mozilla branding, not a stronger client branding.

~~~
ozten
> this will never be true

Primary IdPs host the log in page, not Mozilla...

Say Google implements BrowserID for Gmail.

The user will see the same Gmail Auth log in screen they have seen many times
before. They only have to remember their gmail password (and any password
manager works like it always has on this form).

Most likely if your provider is webmail, then you'll already have an active
session... so you won't have to type a password in.

~~~
notatoad
Yes... assuming that every site on the internet implements this system. which
will never happen.

~~~
lifeisstillgood
Every new site will, every site under active development will. The ones where
two input boxes have been the same off grey colour for three years won't
change much agreed. It's just a question of whether the sites that ask for
username/password now are numerically the majority of login sites in three
years or not?

I give stackoverflow three days.

------
Too
After reading the text twice and watching both videos i still have no clue
what it actually does and _how_ it solves the problem. I'm a few pages of
skimming into the documentation now but there's no overview of what it
actually does in the background.

Just a load of buzzwords and awesomeness!1 of how this will revolutionize my
account management and how easy the API is.

Is it a password manager, a biometric system or some kind of account provider?

~~~
callahad
It's decentralized public-key based authentication, wrapped up in an extremely
user- and dev-friendly package. Francois Marier did a good job of explaining
it at Kiwi PyCon 2012: <https://www.youtube.com/watch?v=iZBTc7iEkQY>

(Think OpenID, but easier to use, easier to implement, and with better privacy
protection.)

In brief: instead of a username and password at login, you get a user's email
address and cryptographically signed assertion proving their ownership of that
address. The assertions are ephemeral and scoped to your site, so once you
verify it, you can set a session cookie and throw away the assertion. No more
password column in your database, yet you still retain a direct relationship
with your users.

Here's the underlying spec (working on getting it updated for Beta 1, but the
principles are all there) [https://github.com/mozilla/id-
specs/blob/prod/browserid/inde...](https://github.com/mozilla/id-
specs/blob/prod/browserid/index.md)

~~~
htmltablesrules
>No more password column in your database...

Who has liability when a user of mine says their account got hacked? The email
provider? My site? Mozilla?

If one of my users has $100 go missing from their account, then they are going
to expect me to replace it, not the email provider, not mozilla. I don't like
the idea of shifting security to a outside platform, because I still retain
all the liability when things go bad, and they always will (key loggers,
spyware...)

Sites that deal with financial transactions will be reluctant to adopt this
for sure.

~~~
mixedbit
How can any website protect a user against key loggers, spyware or any other
form of a compromised client machine? If the client machine is compromised,
any login method is broken.

~~~
anon1685
As mentioned above, two factor authentication.

~~~
mixedbit
Not really. All 2 factor authentication schemes that I've seen give no
protection against a compromised client machine.

In theory you could probably device a scheme that would require the use of two
independent devices to perform any sensitive action and that would guarantee
that if only one of the devices is compromised, the attacker would have no way
to perform any action in a name of the user. But I'm afraid any such scheme
would be a complete failure from a usability perspective.

~~~
mseebach
When the second factor is a "rich" device, such as a smart phone, attaching
transaction information to the interaction would be a trivial - instead of
texting "The code is 1234", text "Transfer $100 to account 9876" or "Login
attempt from IP 1.2.3.4, FooCom Inc, Springfield, Oregon, USA.", followed by
"If correct, enter code 1234. If not, DO NOT enter the code and contact us at
.. "

------
binarymax
Have been messing around with BrowserID since it first went public last year
(with a node.js backend) and I love it. Its so much more straightforward to
implement than oauth and openid, and the fact that it's tied to your email
address is perfect. I'm definitely going to be using it as my primary auth
system going forward. Great job Mozilla!

~~~
DASD
Do you have examples of sites that don't use Persona as the BrowserID
implementation? I'd like to see how sites are handling the user prompt when
there are going to be alternative providers to Mozilla's Persona service.

~~~
JoshTriplett
Doesn't work that way; Mozilla's Persona service just serves as a shim for
browsers without native support for BrowserID. On browsers with native
support, Mozilla's server won't get involved at all.

------
JakeSc
My major concern with this, beside the eggs-in-one-basket issue, is that this
places even more value on my email account.

Years ago, my email account was simply used for exchanging short pieces of
text with acquaintances and companies. Now it's the central key to all my
authentication sessions and finances, and therefore presents a huge target for
attackers.

I've been looking for ways to reduce the risk associated with losing access to
my email account, should that ever happen. Yet for all its benefits, Persona
still places yet more importance on protecting my single email password.

~~~
graue
You could say the same about any traditional username/password signup that
sends a confirmation email and allows you to reply to an email to reset your
password. Ultimately, that's just relying on the security of your email, too.
So while you are correct that Persona doesn't solve that problem, it doesn't
make that problem any worse compared to the default option of an email-
confirmed username and password.

~~~
gambler
Considering that it's a new protocol, why not try to solve that old problem?
At the very least, they could allow you to disable email-based password reset
in favor of printed code. That would be a smart thing to do.

You would get a random code or several codes you print out and put into a safe
place. If you ever forgot your password, you would dig it our and supply to
the website to trigger a reset (which could include or not include email-based
verification). The codes would only be usable for passwords resets.

~~~
path411
Google's 2 factor auth does this already.

------
BryanB55
This seems to be a nice solution if you are on your own home/work computer and
have your email open. They didn't really explain much on HOW it works but the
problem I'm seeing is that if I am at a public computer and want to login I
have to log in to my email account first and click on the persona link. I
guess the benefit here is that I only need to remember 1 password (my email
address password) but my email password is usually a 50 character random
string that I don't like entering on public computers if I even could.

So if I want to log in to a crossword puzzle I almost feel like I have to
compromise my email password which is much more valuable, if say the public
computer has a key logger or something.

Maybe I'm over thinking. I could see how this would be useful if I have my
desktop mail client running and just click a link to log in though.

~~~
stdbrouw
That's not really how it works. You verify your email address once, and after
that you can just log in with your address and password. You don't have to
click on an email link every single time you log in.

------
qikquestion
Let me add my understanding. Please correct me if it is wrong.

Actual user case if everything is in place:

1\. you are in a website using browserid protocol/persona (eg.
<http://crossword.thetimes.co.uk/>)

2.hit the login link. Give your email address (superuser123@gmail.com or
superuser123@yahoo.com)

3.it prompts for your password - gmail password or yahoo password

4.post authentication it takes you to the website with user session as
superuser123@gmail.com/superuser123@yahoo.com - eg crossword.thetimes.co.uk

5.In a nutshell, end user doesn't need to create a new userid & password for
using the website, as long as he knows his emailuserd/emailpassword

Present use case - since few things are missing

1\. you are in a website using browserid protocol/persona (eg.
<http://crossword.thetimes.co.uk/>)

2.hit the login link. since gmail & yahoo as email providers not implemented
browserid/persona protocol, you will asked to create an account in persona.org
with any of your existing email address.(gmail / yahoo).

persona.org will send you a verification link to check if you really own your
email address. Click on the verification link and you are verified to use
persona.org account in all the places where browserid is supported

3.in the login page - it prompts for a new password if you are a new user or
existing password if you are a returning user - this is the password for the
email address used in persona.org registration.

4.post authentication it takes you to the website with user session as
superuser123@gmail.com/superuser123@yahoo.com - eg crossword.thetimes.co.uk

5.In a nutshell, two things will change in future - no login window from
persona.org & no need to create account in persona.org

~~~
callahad
That's completely spot on. Right now, if your email provider doesn't have
native support, we ask you to create a persona.org account so that Mozilla can
vouch for you. In the future, this goes away.

Similarly, the UI is all displayed in response to navigator.id.* functions. If
a browser implements those natively, the Persona UI at login.persona.org
completely goes away.

The more successful Persona is, the less Mozilla is involved in the login
process. :)

~~~
zerostar07
So if i signup now with my @gmail account through persona.org, what happens
when google starts supporting browserid natively?

~~~
callahad
Then you'll start seeing an authentication page hosted by Google, instead of
the Persona fallback. Native options are always tried first, both for client-
side navigator.id functions, and for server-side authentication. If one of
those is missing, then login.persona.org fills in for that component.

------
johnkchow
I personally feel the pain point of password/identity management across
different websites, and I'm using LastPass to help. While LastPass's browser
integration is great, its UX is... lacking. Mozilla's strategy to associate
Firefox browser with identity is IMO awesome and the first sign that it's
pioneering vs reacting to Chrome (before this news, I've always viewed Firefox
as Chrome's successful but still little brother in terms of features, polish,
performance, support, etc.).

BUT (and this is a big "but" I feel), this is contingent with their execution
of browser integration. W/O rock solid browser integration with fluid UX, this
would just add noise to identity services and cause more consumer confusion.

Ultimately, I'm rooting them on because a) I'm concerned about my security and
b) I have too many passwords and c) I'm hella lazy.

~~~
fmarier
Can you be more specific as to how you find the UX lacking?

Getting UX right is a priority for Persona.

~~~
johnkchow
I was referring to LastPass's Chrome extension specifically, not Persona's UX.
Sorry for the confusion.

~~~
pwman
Can you be more specific as to how you find the LastPass UX lacking? Getting
UX right is a priority for LastPass too!

~~~
vidarh
Another LastPass user here. The two big obvious ones:

\- Completely non-standard menu behaviour and appearance \- I to this day can
not associate the shortcut icons for copy/edit etc. with the password. Maybe
that's just m.. \- The one single function I use the most often is "generate
password", and it's hidden one menu down from the root. \- The second most
frequently used function for me is to view the password, when I need to enter
it somewhere where I haven't got Lastpass installed (on another device, so
copy/past isn't sufficient), yet that requires me to click on the site, "edit"
and "show password".

------
DASD
Are there any websites with implementations that don't prompt directly for
Mozilla's site(i.e. asking for your preferred BrowserID provider)? I'd like to
see how clunky the interface becomes when there are more providers(such as if
I want to become my own provider) than just Mozilla. Is the user then confused
by asking for a provider..ala OpenID? Am I correct in presuming Persona is an
implementation of BrowserID?

I'm not likely to use this myself as this little gem from Mozilla's privacy
policy (<https://login.persona.org/privacy>) gives me the shivers: "As part of
the normal operation of the Persona service, Mozilla will retain a log of
which sites you have disclosed your email to."

~~~
callahad
> _Are there any websites with implementations that don't prompt directly for
> Mozilla's site_

That's the OpenID model. BrowserID works somewhat differently. Your ID is an
email address, so your provider is that email's domain. Because few domains
support it directly yet, Mozilla operates an optional, centralized authority
that can issue credentials to other users. But you don't have to use that if
you add support on your own domain.

After that, the UI is also provided by Mozilla's cross-browser JS shim, but
it's just a polyfill for `navigator.id. _`. If your browser has native support
for those methods (Firefox will, soon), then Mozilla's UI is completely
uninvolved.

Basically, we're starting with a single, optional point of centralization:
login.persona.org. As native support comes online from various domains and
browsers, our central fallback will automatically drop out of the picture.

> _Am I correct in presuming Persona is an implementation of BrowserID?*

Yep! BrowserID is the protocol, Persona is Mozilla's cross-browser UI and
optional centralized services. It's kind of like how Google Login is really
OpenID/OAuth under the hood, but more meta.

> _"As part of the normal operation of the Persona service, Mozilla will
> retain a log of which sites you have disclosed your email to."_

Yeah, that line sounds super bad. IIRC, it's a relic of a previous design of
the cross-browser shim that needs to be removed. I'll follow up with Mozilla's
legal folks.

~~~
DASD
Are there any browsers that currently implement BrowserID? I just fired up
Firefox 15 and still get the pop-up for login.persona. Or links to near future
impementations?

Thanks for you and otzen for shedding light on all of this.

~~~
callahad
I believe Firefox OS will have the first enabled-by-default, user-visible
implementation around Q1 next year. Bits are starting to land in Firefox, but
they're super, super experimental and not totally functional yet.

------
lifeisstillgood
Got it spliced into the site i am working on, checked in to github, and my
laptop crashes. Karma oh karma.

This looks great, I got an identity service plugged in in hours, into a OSS
website and this will kick openids bottom.

Brilliant - Mozilla is hitting some incredible high notes right now

~~~
ozten
I'm seriously digging the positive, participation and hacking vibe in these
comments!

The web and OSS is _so amazing_.

------
don_draper
One reason this looks good to me is that I trust Mozilla more than most
organizations.

~~~
htmltablesrules
I don't trust any "organization" to store and manage my passwords. A single
subpoena to mozilla for a divorce proceeding or whatever could unleash
cascading consequences upon you.

~~~
ozten
The system is designed to allow your email provider or another Identity
Provider that you trust, to store your password instead of Mozilla.

Your identity provider just has to implement the BrowserID protocol
[https://developer.mozilla.org/en-
US/docs/Persona/Identity_Pr...](https://developer.mozilla.org/en-
US/docs/Persona/Identity_Provider_Overview)

~~~
htmltablesrules
So what happens if my email account gets hacked? Won't this compromise all my
accounts then?

~~~
ozten
This problem exists today. I can do "forgot my password" on many sites and
owning your email account can change the passwords and log in to them.

Persona doesn't attempt to solve this existing problem.

------
AndrewDucker
I'm hoping that a large email provider (like gmail) will support this soon.

Getting providers onboard with this will be the make or break factor. And I'd
really like it to succeed.

------
forgotusername
I really want to believe in something like this, however you'd getting much
better traction by explaining a few key details:

* What the hell does the JS assertion object look like?

* How do I run an independent service?

* In a single page, walk me through the steps to integrate?

Videos, dodgy music, overenthusiastic PFYs appeal to me much less than good
documentation

~~~
callahad
> _What the hell does the JS assertion object look like?_

Needs to be updated a little bit, but check out the spec:
[https://github.com/mozilla/id-
specs/blob/prod/browserid/inde...](https://github.com/mozilla/id-
specs/blob/prod/browserid/index.md#backed-identity-assertion)

Note: You don't have to implement this yourself! You can POST assertions to
<https://verifier.login.persona.org/verify> instead, and we'll return a JSON
blob that lets you know if it was valid or not. Or you could run that same
verifier locally (it's a stateless node.js server, code's on github in the
mozilla/browserid repo). The exact data formats are still in flux (waiting /
hoping for IETF standardization around some crypto things), so we don't
recommend doing verification yourself just yet, unless you run our node.js
verifier and frequently update it. We'll get that stuff locked down in one of
the next Beta releases.

> _How do I run an independent service?_

[https://developer.mozilla.org/en-
US/docs/Persona/Implementin...](https://developer.mozilla.org/en-
US/docs/Persona/Implementing_a_Persona_IdP)

> _In a single page, walk me through the steps to integrate?_

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

~~~
forgotusername
Huh :) I went in circles on the MDN site for a few minutes.

------
icebraining
Support for Persona in HN would be _awesome_...

~~~
fmarier
...and assuming it's written in Python (is it?), it should be pretty easy to
do: [https://github.com/mozilla/browserid-
cookbook/blob/master/py...](https://github.com/mozilla/browserid-
cookbook/blob/master/python/python.cgi)

~~~
icebraining
Nope, HN is written in Arc:
<https://en.wikipedia.org/wiki/Arc_(programming_language)>

------
dmthompson
Awesome work by Mozilla. I've added this to a small project of mine, and it
was super simple and fast to do. I really excited to see this gain traction.

------
Ygg2
This is just great. I do hope this replaces Facebook connect as authentication
provider, though I doubt it since getting all that user info is priceless for
most sites using Facebook connect.

It looks very lovely.

~~~
latchkey
I don't think it'll replace Facebook, it'll just be an alternative to it.
We've integrated both Persona and Facebook into our site and it works great.

For my business, we need more personal details about each person that we get
by default with Facebook (name/age/sex). So, that integration will always be
cleaner than Persona because it is just a few clicks.

We've been working with BID/Persona for a while now (we're linked from the
/about page) and we're huge fans. If you want to play around with it...
<https://www.voo.st/>

~~~
JoshTriplett
I've seen some preliminary discussions of linking personal information to a
Persona and optionally supplying it to the site at login time. If you have a
need for that, you should chat with the Persona/BrowserID developers.

~~~
latchkey
It wouldn't be ideal because there would only be a limited number of people
who ever took advantage of it. The model for Persona is different than
Facebook. Facebook requires this data on account creation and so do we... so
we just present the user with a lock out until they give it to us.

~~~
JoshTriplett
Persona could potentially note at login time that you require that information
to create an account, and thus require supplying it before attempting to log
in.

That said, looking at what your site does, why do you _need_ that information?
I can understand why you _want_ it, but what functionality of your site won't
function without it?

~~~
latchkey
Yes, we require it. Having the persons name is obvious. For the rest, the site
is very specific in its purpose, which is to allow people to register for USA
cycling events.

There are some crazy rules around who can enter which race (based on age/sex)
and we do our best to help guide people into the right event during
registration.

Location is a nice to have so that when we show the list of participants, they
can see where each person lives. Future versions of the site will use this
information to help people connect with ride sharing to events.

Keeping the UX of asking for this information within our site makes sense when
logging in with Persona since it doesn't have the social networking aspects
that Facebook has. Most people who are entering bike races won't lie about
their age/sex on Facebook (because bike racing is a relatively small
community), so generally this information is pretty accurate. Once someone
gives us their USA Cycling license number we also validate against the
database we have of that information too.

------
sandGorgon
What is the self-hosted equivalent of this ? I have been struggling with this
problem quite a bit.

I have a bunch of web apps which are quite a bit different - off the shelf
forum software, wordpress, custom code, etc. - and I want to tie them all
together using a single signon. What should I be using ? I distrust myself
enough to know that I would prefer not rolling my own security protocol.

I know that there are solutions like Kerberos, etc. but is it really practical
for a bunch of websites running on Rackspace + EC2 ?

~~~
ozten
Which pieces do you care about being self-hosted?

If you use Persona on all your sites, it feels very much like SSO.

I use the browserid plugin (<http://wordpress.org/extend/plugins/browserid/>)
on my personal Wordpress site.

We actually had an SSO project based on CAS v2, which we killed because
Persona was a better solution.

~~~
sandGorgon
I agree about the Persona bit, but many times you are not ... shall we say
"allowed" to.

Since you built an SSO, could you point me in the right direction amongst
self-hosted solutions. Some comparisons and pitfalls would be most welcome.

------
donrhummy
Can someone explain how this is distributed and not using a central
"authority"? I know it caches things locally, but it still requires Mozilla's
Persona.org servers, correct? And you need a password that Mozilla stores, so
aren't their servers still vulnerable? And couldn't (dumb) people still choose
"123456" as their persona password? I understand that this makes the sites
with crappy security implementations better, but some of the weaknesses are
still there, right?

~~~
tofumatt
I believe the aim is to have email providers be able to auth your persona
email instead of Mozilla, but Mozilla exists as a sort of polyfill if the
provider (eg. hotmail.com, gmail.com, your-custom-domain.net) doesn't do
persona yet.

Also, yes: people can still choose crummy passwords. Personally, I don't think
the appeal is in better security; it's convenience of single sign-on without
it being tied to a. identity or b. Facebook (or twitter or google or whatever
other service that harvests my data).

~~~
donrhummy
Right, but the email providers are only authenticating you to Persona. As far
as the websites using Persona are concerned, it's persona.org that
authenticates you.

And the appeal that Mozilla is pushing is definitely better security (as well
as a distributed security authentication versus one for-profit authority - I
definitely trust Mozilla MUCH more than Facebook or twitter, but it's still a
central authority). You can especially see this in the talk they gave
introducing it: <http://www.youtube.com/watch?v=iZBTc7iEkQY>

~~~
ozten
As a website you can do local verification of the log in assertion.

Mozilla hosts a verifier as a convenience, but you don't have to use it.

~~~
donrhummy
But the assertion only gets sent if the user logs in to persona first (with
their email and _persona_ password)

~~~
callahad
Ah! Right. There _is no_ Persona password if your email provider supports
Persona natively. If your provider has native support, you _only_ authenticate
with them, and the site you're logging into sees a credential issued by your
provider. Mozilla is completely out of the transaction in that case.

You can try this yourself with a demo identity provider we have at
<http://eyedee.me/>

------
petepete
I thought [1] Mozilla Personas were themes?

[1] <http://www.getpersonas.com/en-US/>

Evidently I need to pay more attention.

~~~
timmclean
Used to be: [http://identity.mozilla.com/post/18038609895/introducing-
moz...](http://identity.mozilla.com/post/18038609895/introducing-mozilla-
persona)

~~~
benatkin
I told them that they need to rename it with a 301 several weeks ago. They
haven't. _sigh_

------
romaniv
I think the general idea of building better auth into browsers is a wonderful
and highly necessary development. However, this implementation will completely
fail if the user has JavaScript blocked and there is no fallback. And yes,
this is a real issue. (Though I will probably get a lot of replies that try to
dismiss it in various ways.)

~~~
callahad
That's a great point. Persona doesn't work well in non-JS, non-browser
contexts, yet. The nice thing is that you can use it for progressive
enhancement. Users have JS? Auth with Persona. Users don't have JS? Use a
traditional email address / password system.

So long as you can associate email addresses with accounts on your backend,
you can use Persona with the same database you have right now.

~~~
Johngibb
Is there any way to use it for say an iPhone app interacting with web services
authenticated as a user?

~~~
ozten
There have been iPhone (pancake) and Android (soup the AMO marketplace) apps
and you can find the source in github.

We're working on an iOS SDK, to make this polished and easy.

Patches welcome, get involved!

* mozilla.dev.identity mailing list * #identity on irc.mozilla.org

------
glassx
Interesting changes to the API. We now have an observer API, instead of just a
function that invokes the login window.

<https://developer.mozilla.org/en-US/docs/DOM/navigator.id>

I believe this merges the old BrowserID Session Management parts with Persona,
or am I wrong?

~~~
callahad
Yep! The Observer API does session management automatically. (Some folks don't
want that, so the previous `.get()` API is still available.)

------
Sidnicious
I’m not in _love_ with Persona because it puts everyone’s eggs in one basket.

I like OpenID because it works like email — choose whichever provider you
fancy. If one goes sour or a nicer one pops up, websites don’t have to add
support it before you can use it. And, websites can choose to expose nice
“sign in with X” buttons instead of making you type in your OpenID address to
sign in.

On the other hand, I realize that Mozilla has made big advances in ease-of-use
(for users and developers). I just hope those advances turn into an open
protocol someday.

P.S. I had a fleeting hope that they were announcing browser extensions (with
a fallback to the way it works now). There’s still a risk of sketchy websites
phishing for your Persona login.

\- - -

All right, clearly I need to read some more docs. I apologize for making
unfounded complaints against what seems to be a pretty darn awesome protocol.

~~~
callahad
> _I like OpenID because it works like email — choose whichever provider you
> fancy._

Persona works like email because every identifier _is_ an email address, not
an opaque OpenID URL. You don't have to have the NASCAR-esque "Sign in with
OpenID Provider X, Y, or Z" login page if users can actually use an identifier
that that already know. :) (To be fair, OpenID Connect is working on fixing
that problem)

> _I just hope those advances turn into an open protocol someday._

You're in luck! :) The protocol is open and completely decentralized:
[https://github.com/mozilla/id-
specs/blob/prod/browserid/inde...](https://github.com/mozilla/id-
specs/blob/prod/browserid/index.md)

Mozilla operates a few centralized services to solve the chicken-and-egg
problem while bootstrapping, but they're completely optional, and they
automatically fall away when a browser or email provider have native support
for the BrowserID protocol.

~~~
waffle_ss
> Persona works like email because every identifier is an email address, not
> an opaque OpenID URL. You don't have to have the NASCAR-esque "Sign in with
> OpenID Provider X, Y, or Z" login page if users can actually use an
> identifier that that already know.

OpenID URLs need not be opaque - I use my regular <realname>.com URL as my
OpenID, and have a stub in the HTML of /index.html that points to the provider
that I want to use when I authenticate (which I can change any time I please).
It's called delegation. I think using DNS as an identifier is better than
email (as that's kind of what it was built for), but not a viable option for
the masses. Mozilla did a good job with Persona.

~~~
seanmonstar
Not everyone supports that though. I do the same thing for OpenID, and sites
that "support" open-id like The Verge cannot figure out mine in that way.

------
olivier1664
As far as I understand <http://lloyd.io/how-browserid-works> , the browser
will hold a "certificate of ownership of the email". Since browser do not yet
implement Persona, it is done in javascript with
<https://login.persona.org/include.js> .

I do not yet understand what prevent me to steal these 'certificate of
ownership of the email' by creating a web site with my own version of
'include.js'. In this malicious version, the "Assertion Generation" also send
the private key to the server. After that, the server can uses the user login
as he wants. It seems there is a timeout, but it allow the malicious server to
log so long the time out is not ellapsed. Where I'am wrong?

------
scribu
I can see why they're calling it a beta release. The UX during creating a
profile on developer.mozilla.org has several rough edges. For example:

    
    
      1. Clicked "Sign In" and successfully create a Persona account.
      2. Created a profile on MDN, with the wrong user name (oops).
      3. Cancelled my Persona account in a separate tab.
    

I'm still logged in on MDN and the "Sign Out" button doesn't work now. After
5-10 minutes, I get a "Permission Denied" page, which is correct, but not
exactly the expected workflow.

Also, LastPass doesn't seem to play well with Persona, but I'm hopeful it will
in the future.

------
spoletto
If I understand correctly, the browser stores a certificate that proves you
own your email address. These certificates are only valid for a certain amount
of time, even if you check that you own this computer. So what happens when
your cert expires? Do you have to go back to your email and re-click the link
that gives you a new cert to be stored in your browser?

Also, if I'm using a public computer, is there a way for me to manually revoke
a cert when I'm done using the machine? It seems that even a 1hr expiry is too
long for this case.

~~~
callahad
This is the part that gets kind of confusing because there isn't a clear
delineation between Persona the UI and Persona the fallback identity provider
(IdP).

When your cert expires, you need to get a new one from your IdP. If you
already have an active session with your IdP (either by logging into your
webmail, or clicking the "this is my computer" button for Mozilla's fallback),
then your browser can get a new cert completely invisibly.

If your session _and_ your cert have expired, then you get prompted to
authenticate again. For the Persona fallback, this means you'll be prompted
for your Persona password (instead of sending you back to your email, because
that's super annoying and users end up not logging into your site). If your
email provider has native support for Persona, then you'll get prompted by
them however they normally do login.

> _I'm using a public computer, is there a way for me to manually revoke a
> cert when I'm done using the machine?_

Go to login.persona.org and click "sign out." We're working on universal
signout (at least for users of the fallback), but I'm not sure if that's
landed in production yet.

~~~
bwood
Thanks for the detail, I really like what I see with Persona so far.

------
egfx
Oh, This is perfect. Today was Persona implementation day for the project I'm
working on and now this announcement comes. This is great for a developer area
login.

------
johnkchow
As a user I definitely appreciate the emphasis of privacy first as well as its
clear responsibility for identification. However, from how I see it on the
surface, it currently doesn't have the market reach as, say, FB Connect or
Google, and I don't want to "flood" my users with too many options for
authentication. What's the practical arguments of rolling out my own
authentication (Rails + Devise) vs using Personas?

~~~
callahad
It's available to any user with an email address -- you don't have to limit
yourself to users that have, and are willing to use, a Facebook or Google
account.

Versus rolling your own, you don't have the friction of account creation /
password management for new user signups if the user has _ever_ used Persona
before, and we'll be dramatically improving first-contact before the end of
the year. You can completely forget about storing passwords. You don't have to
send email verifications or handle forgotten passwords.

~~~
johnkchow
Ah so true, email verifications and forgotten passwords can become a hassle.
Thanks for the insight callahad.

------
benlower
What if I don't want a site to know my email address? I currently create
unique email addresses for each site. How do I do that with Persona?

~~~
timmclean
It looks like it'd be pretty easy to continue that practice -- just verify
more than one email address, and pick the correct one when signing into each
site. Try it here: <http://myfavoritebeer.org/>

Also, there are Mailinator-like services: <https://mockmyid.com/>

~~~
seanmonstar
Exactly. And there's even this service that tries to automate this _into_
Persona: <https://github.com/nmalkin/janus>

------
opendomain
I can not get Persona to work. I go to Mozilla developer network:
<https://developer.mozilla.org/en-US/> , see the login button and click on it
and it redirects me back to the same page. I am using Firefox 15

~~~
ozten
The first run on MDN can be a little confusing.

Does it work for you on <http://crossword.thetimes.co.uk/> ?

If not, we'd love to help identify your issue
<https://github.com/mozilla/browserid/issues/new>

~~~
opendomain
Yea - there was nowhere for me to sign up. I think the problem may be the pop-
up did not work on Firefox. I used Chrome and was able to create an account
and then everything worked. I also tested on IE8 and had some javascript
error, but just hit refresh twice and was able to login.

------
zachinglis
That intro video really doesn't explain much. I know it takes 15 minutes to
integrate into my site, and works with any browser, but I have no idea why I
truly want to spend those 15 minutes doing so.

------
Flenser
Perhaps making signing in to websites really simple, in a way that verifies
the users email address to the site, isn't a good idea. Once it's widely
adopted spammers will start using it.

------
zerostar07
I don't know if it's appropriate but can we list some of websites where one
can login through browserID? I 'm a big fan of browserID, and would gladly
beta test your integration.

~~~
jedp
Sure thing. In addition to many of Mozilla's own sites, here are some
examples:

\- Times Crossword: <http://crossword.thetimes.co.uk/>

\- Openphoto: <http://current.openphoto.me/>

\- Voost: <https://www.voo.st/>

Our test application is this notepad application: <http://123done.org/> (which
you can clone from github)

~~~
zerostar07
Been using it for a while on <http://noteplz.com/> too

------
pablocubico
For those of you asking, you can find some more background on how BrowserID
here:

<http://lloyd.io/how-browserid-works>

------
asymmetric
This looks really great. Only problem I see is the lack of support for IE 6
and 7, and it seems they won't be in the future. Anybody knows why that is?

~~~
callahad
The Persona cross-browser support shim needs window.postMessage and the HTML5
storage APIs, which IE 7 doesn't have. Working around it didn't seem worth the
security and maintainability cost to the codebase, nor the opportunity cost
over working on other features.

------
SODaniel
Seems pretty interesting, though I have to say that watching only the
introduction video gives you basically NO IDEA of what the product solves or
how.

------
Tipzntrix
I wonder if this will be developed into a standard, or whether Mozilla will
have to be the only ones operating this service.

~~~
ozten
BrowserID Protocol Spec

[https://github.com/mozilla/id-
specs/blob/prod/browserid/inde...](https://github.com/mozilla/id-
specs/blob/prod/browserid/index.md)

------
mey
Am I entirely missing something, but once a password is selected, is there no
way to change it?

~~~
fmarier
You can manage your account (e.g. change password, remove emails) by signing
into <https://login.persona.org> .

------
nagnatron
I would love to see this working.

------
betterth
I dislike that a Google search for "Mozilla Persona" returns Firefox Personas
first, meaning that Mozilla now has 'Persona' and 'Personas' projects that are
totally and completely unrelated to one another.

Something has to give because if it confuses a Hacker News reader, it's going
to go completely over the head of the average computer user.

~~~
zerostar07
Supposedly, end users will only face the "login with browserid" buttons. But
yeah, i find the name change from browserid to Persona, as first time users
will be confused.

------
riffraff
the "check the documentation" link goes to
<https://developer.mozilla.org/it/Persona> which 404s for me.

Maybe not redirecting based on user location by default is a good idea.

~~~
kalv
Odd it worked for me and redirected to <https://developer.mozilla.org/en-
US/docs/Persona>

------
astro1138
Beta? I've made my own persona years ago: <http://www.getpersonas.com/en-
US/persona/95515>

------
sabret00the
Have the fixed the fact that it doesn't support autofilling passwords? That
alone makes it more annoying than any captcha that I've ever had to fill out.

~~~
sabret00the
Find it hilarious that this got marked down and yet it's something Mozilla
have spent the last week moving towards getting this fixed.

------
kin
how does it work with multiple users using the same browser?

~~~
fmarier
When you click the "Sign in with Persona" button on a website, the dialog that
pops up has a "This is not me" button which logs out the current user and
allows you to login with a different email.

------
jorangreef
Does Persona do MFA?

