

Introducing Mozilla Persona, An Identity System for the Web - ojr
http://www.mozilla.org/en-US/persona/

======
stickfigure
My company is one of the early adopters of Persona/BrowserID. You can see our
dual-auth (with Facebook) system here:

<https://www.voo.st/>

We've been live for several months now in the Real World - our userbase
(amateur athletes) is primarily nontechnical. About half of our users choose
Persona/BrowserID and half choose Facebook. We were initially concerned about
the BID login flow (in particular, the immediate email roundtrip) but it
hasn't been a problem and the UX has been refined quite a lot over the last
month or two.

For a mass-consumer audience, the combined FB/Persona solution is excellent:

* Facebook unquestionably has the slickest auth experience, even eliminating the followup name/sex/bday questions. However, a significant percentage of the world (possibly > 25%) either Hates Facebook or wants to keep their Facebook account isolated. This is unlikely to change in the near future and could even get worse depending on what sleeping dogs Zuckerberg decides to kick next week. We don't have the option of alienating the FB haters and we wouldn't want to anyways.

* The Persona UX is good and rapidly getting better. BigTent integration with gmail, yahoo, hotmail will bring one-click login to those users. A native experience is being built into browser chrome. All this is coming without me having to write code. It may not be as slick as Facebook, but I like where this train is headed.

* Integration is simple compared to writing a username/password system. The API is incredibly easy to work with. Dual-auth with Facebook is a little more complicated, but a complete Persona-based auth system is a question of hours, not days.

* The fact that identity is just an email address makes it easier to integrate with existing login systems. In our system, you can log into the same account with both Facebook and Persona as long as the emails match. No, email is not a perfect identifier, but even nontechnical users understand it immediately and really - what other option is there? "What email address did I use?" is a lot better than "What weird combination of letters and numbers did I use as a login name?"

* Support on the Mozilla dev-identity list has been fantastic.

We're pretty happy. Honestly, I don't ever see myself writing another
username/password login system ever again. Persona is less work for a better
UX.

~~~
dabeeeenster
OK so I tried to sign up to your site with BID and am pretty confused:

I'm using Chrome. Don't know if that affects things. Anyway.

Hit Browser ID, asks me for my email address. OK fine, add that in. It then
says (quickly, and temporarily as it's an AJAX load), that it's looking up my
email provider (Google Apps). It then asks me for my password.

So now I'm totally confused. I've not signed up with your site or BID before,
so I dont know if it wants my GAPPS password or a new password. I don't feel
like I want to put in my GApps password, as there is no Google branding
anywhere and the URL is not Google.

So I try putting in my GAPPS password, because I use 2 factor, and it doesn't
work. Most likely because I use 2 factor, and I can't authenticate with just
my standard GAPPS password.

So it failed. I guess I'm an edge case as most people don't enable 2-factor on
their Google account, but I was still really confused when it asked for my
email password.

EDIT:

Same thing happened with Firefox version whatever the latest one is.

I'd say it's completely confusing, all in all.

~~~
jstalin
I just tried it and once I entered my email address, it then asked: "Next,
choose a new password you'll use when you sign in with Persona."

Not sure why you're confused.

~~~
jackalope
From <https://developer.mozilla.org/en/BrowserID/>

_"Website operators still get a verified email address for their users, and
users only have to remember a single password. BrowserID is also intuitive,
since email addresses are commonly understood to be associated with
identities."_

Mozilla is really stressing the _"email address/single password"_ concept. If
they really mean _"email address/separate dedicated Persona password"_ then
they should make this clear.

~~~
callahad
The language around the number of passwords you need is really hard to get
right. If you have suggestions, please let me know.

In a world where every email provider supports Persona natively, Persona truly
is a "no new passwords" authentication system, since it delegates to your
provider. If your email address isn't supported, Persona asks you to create a
single new password at login.persona.org. You can then add many other
unsupported addresses, without needing more passwords. So it's an "at most one
new password" system.

~~~
uvtc
Simply always refer to the Persona password as "Persona password".

> In a world where every email provider supports Persona natively, Persona
> truly is a "no new passwords" authentication system, since it delegates to
> your provider.

I don't know what this means. I won't give Persona my gmail/yahoo-mail email
password.

~~~
callahad
Yeah, it's confusing. If your email provider is supported, your browser talks
directly to your email provider, without Mozilla in the middle. We don't want
your passwords, honest! :)

You can try out the supported email provider workflow by signing up for a
dummy account at eyedee.me, and then using that account to sign in at, say,
123done.org.

~~~
jackalope
Wait, if this system works with a dummy account, then a valid email address
isn't necessary at all. Any domain can set up an identity provider to support
user@domain. Why drag email providers into the discussion, then? It confuses
everyone.

~~~
stickfigure
It confuses _you_ because you are a technologist. For 99.99% of the world,
user@domain == email address.

"Sign in with your email address" gets the point across. "Sign in with your
user identity at a controlling DNS authority" may be more accurate, but will
_actually_ confuse everyone.

------
nnethercote
That link is to a very high level, non-technical overview, which is not a good
link for HN.

Try these links, which go into much more detail, answering the "why bother"
questions.

<https://developer.mozilla.org/en/BrowserID/Why_BrowserID>

[http://identity.mozilla.com/post/7899984443/privacy-and-
brow...](http://identity.mozilla.com/post/7899984443/privacy-and-browserid)

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

Note that BrowserID was the old working name for the project.

------
glassx
I believe that a native implementation has been on their plans from the start,
but I haven't heard much about it lately. Here's some mockups:

[http://people.mozilla.com/%7Efaaborg/files/projects/firefoxA...](http://people.mozilla.com/%7Efaaborg/files/projects/firefoxAccount/index.html)

There's also some work on integrating existing e-mail providers, so you can
get instant identities:

[http://identity.mozilla.com/post/17207734786/id-provider-
sup...](http://identity.mozilla.com/post/17207734786/id-provider-support-now-
live-on-browserid)

This is probably the web-thing I'm most excited about today, even though the
development is kinda slow. I really want to implement it as a sole identity
provider on my websites some day.

EDIT: I also began writing a Safari extension that would work like the mockup
above, but gave up halfway since it was too convoluted and totally insecure...
maybe I should try writing a SIMBL plugin or something like that.

~~~
egs
A website relying on a single service to serve as a sole identity provider
seems replete with risks. That sounds remarkably similar to Microsoft's
Passport, an idea that was a non-starter for everyone except Microsoft.

~~~
glassx
It's hard to explain, but it's not much a "service" - the current
implementation is just a "shim", since no browser supports it natively.
Client-wise, it's just a JavaScript API. In the future, your browser will
store your keys, not Mozilla.

But even with the current implementation it is possible to validate the
assertion in your server without contacting browserid.org, but AFAIK nobody
did it yet.

(I tried to find a reference for that, but they took it down from their Wiki.
It used to say "You may choose to validate assertions on your own server":
[https://github.com/mozilla/browserid/wiki/How-to-Use-
Browser...](https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-
Your-Site/5a1abdd205221e39621c17d7cc3050b3f3b97eed) \- the verification code
is still online, though)

~~~
callahad
Your browser already stores your keys, even with the shim. :)

Faaborg's mockups are awesome, but they're well over a year old and not really
guiding our current work. Still, definitely take a look at them, if nothing
else than for the cool way of doing mockups!

You can definitely do your own verification without having us in the loop, but
we'd urge you to hold off until this fall; the IETF is still standardizing
some of the data formats we're using, so the exact serialization of keys and
assertions might change between now and then. By using our verifier, you're
certain to be up to date.

The easiest way to verify-it-yourself is to just run our code locally; it's
all open source, after all :) <https://github.com/mozilla/browserid>

(PS: The docs are now on MDN, instead of the GitHub wiki:
<https://developer.mozilla.org/en/BrowserID> )

------
rubberband
So we have this, Open ID, Facebook, Twitter, Google, Microsoft Passport/Live
ID, and probably like five other major players I'm forgetting. I apologize for
being pessimistic, but this just doesn't seem like a solvable problem. I
_want_ it to be solvable, but players like Facebook benefit far too much for
them to _not_ push their particular version of "universal" login on everyone.
Every player seems to think they are the One True Solution... But so far, it's
all one big mess. I don't see it getting better any time soon.

~~~
Alex3917
I think if you look at Kim Cameron's Laws of Identity, it's clear that the
research team at MS has had it right for at least a decade, it's just that
none of their ideas have made it into production.

<http://www.identityblog.com/stories/2004/12/09/thelaws.html>

Ballmer had both the plans and source code for an identity product that would
have been 10x more advanced than Facebook, but they decided to axe the project
so they could make the Zune instead.

~~~
nl
_Ballmer had both the plans and source code for an identity product that would
have been 10x more advanced than Facebook_

 _ANYONE_ can make an identity product that is 10x more advanced than
Facebook.

The problem is making an identity product that is 10x _SIMPLER_ than Facebook,
without relying on a single source of identity verification.

------
greggman
I know this probably fits only me but I never use my email address as id.

Every company and every account I sign up for I give a different email
address. I'm not about to use a single one for my ID. Especially when they are
easy to spoof (any one can send mail as you@there.com) and they are easy to
spam and abuse. I had an email address that got 3000 spams a day. That's why I
never give use email as ID because I want to be able to disable any email
address that's giving me trouble.

So, not interested in BrowserID I think. Or maybe I didn't grok it.

~~~
rfk
There is a lot of scope for one-time emails, pseudonymous emails and other
kinds of not-my-primary-email authentication systems within Persona. One
simple example of how this might work is MockMyID:

    
    
        https://mockmyid.com/
    

Try logging into a Persona-enabled website with anything@mockmyid.com - you
will be able to authenticate without entering any password or giving away any
personal information. Of course, so can anyone else, but it might give you an
idea of the possibilities in this space.

~~~
eps
But what is being authenticated exactly in this case?

My understanding of Browser ID is that it's a way to provide an email address
to a site operator that doesn't need to be confirmed. It's a single-step
subscribe/account creation, rather than an authentication per se.

~~~
rfk
BrowserID provides a way to say to a site "I own this email address", as well
as a protocol for the site to verify such an assertion. What the site chooses
to do with the information is up to them. It can be used for account creation
or signup, but works equally well for authentication to an existing account.

In the mockmyid case, you are saying "I own the address xyz@mockmyid.com". But
the MockMyID server will happily let anyone make such an assertion, so you get
a simple kind of mock identity.

Of course, you shouldn't use that as your identity on any sites that you care
about. Mail to anything@mockmyid.com doesn't go anywhere, and there's nothing
to prevent other people from using the same @mockmyid.com address. But it's a
neat example of the sort of thing that is possible.

------
nostromo
One of the reasons FB and Twitter OAuth became so popular is because they
solved a problem for the user (remembering passwords) and also gave the site
owner a big carrot (social growth mechanics, more user data).

This seems much more one sided -- it's good for the user that doesn't use FB
or Twitter but 'meh' for the website. I'm not sure we'll see fast adoption
like we have for OAuth.

~~~
callahad
One of the biggest wins for sites is that we reduce account creation / sign in
friction for your users, so you get an awesome, easy flow through your funnel
without having to give up ownership of your user data.

We also let you reach many, many more people, since you're not forcing users
into joining an anointed social network. Everyone has an email address, and
people understand what it means to reveal it.

Also, there's no lock-in, because we're not giving you an opaque, one-way
identifier for your users. Instead, you always get a verified email address.
Want to switch away from Persona? Add a 'password' column to your database and
send a few emails.

Edit: I should also note that we're really, really easy to implement. Like,
roll-your-own-integration in less than 3 hours with zero previous experience
easy. I want to see us become the de facto auth solution for weekend projects,
but we're also a really nice option to put alongside your social login. If
you're already offering Twitter and Facebook, why not provide a vendor-neutral
option, too?

~~~
saurik
Wait, it relies on email address? ( _quickly reads up on it._ ) ... and it
doesn't have user identifiers other than the email address? That is not
reasonable: normal people (as in, people who don't know much about what they
are doing with computers) tend to have piles and piles of email addresses,
none of which hold any canonical weight to them: they have email addresses
from ISPs, from schools, from work, and they often have multiple email
addresses from sevices like Gmail. If they lose track of one they just get
another one (as email addresses aren't even important anyway), and they never
remember which one they've used with any given site. I've even seen people
purposely get a new email address every now and then as their way of dealing
with spam and "people I don't want to talk to anymore". They don't think far
ahead, so the notion that their email address from school will be retired a
year after they graduate _and given to someone else_ doesn't occur to them
(and seemingly didn't occur to you either, as it undermines the argument that
it is a reasonable way to do password resets): email addresses are about the
worst possible (while still plausible) "unique" identifier you could have come
up with. :( (And yes: this is coming from someone who has had a single
canonical email address for over 15 years: I also run a popular website
frequented by tens of millions of users, many of whom are non-technical
customers, and I have had to realize that they are nothing like me.)

~~~
ollysb
Here's what would be great for users, being able to sign in with _any_ of
their email addresses and passwords. If you could register all of your email
addresses and passwords then login would become as easy as entering the first
set of details you think of.

~~~
ciex
That's an interesting idea. How would you go about collecting all these emails
first though?

Would you tell the user to "just enter all email addresses you ever
registered" and then send confirmation emails to all of them? I'd imagine this
ending with one or two confirmed email addresses and maybe 3 additional
unconfirmed ones.

When the user then tries to use one of the unconfirmed addresses to sign in —
what do you do? Refuse log in because the address is not confirmed? Send
another confirmation email to that account and ask the user to confirm it?
List those confirmed addresses in the account and ask the user if he wants to
sign in with one of them?

~~~
nileshtrivedi
No need to send confirmation emails. Let him login with any email address. If
the authentication is successful, you let him in. At this stage, it is a new
account so give him an option to link this new account with his existing
account with your service. If he had already provided all his email addresses
with the first account, there is no need to authenticate one more time.
Otherwise, simply authenticate once more with the original email and link the
accounts if successful.

------
zaroth
I read a comment that the email provider can allow anyone to log into your
accounts because they can sign any public key they want to say it's valid.
This seems to be true from my 10 minutes reading the spec.

I know a password reset function that uses only email is basically the same
level of trust in the email provider, and I'm no fan of email based password
reset, but this feels even worse -- literally abdicating your security
entirely into your email providers hands? Gmail is great because it's free,
but I didn't join gmail with the idea of giving them the keys to my life.

Another thing I don't fully grok yet is the 'issued-by' concept. Does this
mean that 'Relying Parties' need to whitelist all the secondaries they are
willing to trust? How can that possibly fly?

Finally, in a native implementation, how is the keyring persisted on disk kept
safe from malware extracting your private keys? If the browser can decrypt the
keyring, so can malware.

Ok I lied, one more thing... Is there a password prompt when you first sit
down at the native BrowserID implementation? Or does it just assume that your
browser means its you sitting there?! Then of course the next question is, how
do you tell your browser you are walking away (akin to logout) and is it going
to expire all sessions that were tied to your identity when that happens? So
much to worry about...

~~~
callahad
> _I didn't join gmail with the idea of giving them the keys to my life._

Nor did I, but as you acknowledged, that sort of control has entered the
status quo. Anyone who can break into your email account can trivially reset
your password on many sites, at which point, per-site passwords just become
another liability. We get rid of those, and empower you to independently
decide who to trust with your identity.

> _Does this mean that 'Relying Parties' need to whitelist all the secondaries
> they are willing to trust? How can that possibly fly?_

The idea of a secondary (or fallback) isn't central to the BrowserID protocol;
it's just a convenience so that we can actually bootstrap a fully
decentralized system. In practice, all libraries trust Mozilla's fallback
Identity Provider by default. As email providers add native support for the
BrowserID protocol less and less traffic passes through our fallback until it
simply and automatically drops out of existence.

> _If the browser can decrypt the keyring, so can malware._

Yep, that's true. Same with your password manager, though we are trying to
mitigate this by making the certificate itself relatively short-lived. To wit,
each client has its own ephemeral keypair with certificates that expire
regularly, requiring a silent renewal with the Identity Provider. This creates
an opportunity for the Identity Provider to refuse to renew a certificate,
should one of your machines become compromised.

> _Is there a password prompt when you first sit down at the native BrowserID
> implementation? Or does it just assume that your browser means its you
> sitting there?!_

If you have a valid, unexpired certificate available, you'll be able to log in
to things straight away. If not, you'll need to authenticate with your
identity provider to get a fresh cert. Native clients are, of course, free to
implement additional security measures before allowing access to the keystore.

~~~
zaroth
Thanks for taking the time to respond.

At least in the case of password resets, it's the site deciding they want
"email" to be the weakest link, and many sites will require at least a little
bit more (like secret questions) after a reset. In this scheme, email is by
definition the weakest link.

The secondaries can never go away, unless sites are willing to straight up
refuse customers based on their email address. There is an extremely long tail
of corporate email servers out there, and those corporate employees are our
users. I guess we just gracefully degrade back to standard usernames and
passwords?

So the certa expire AND the key-pair is ephemeral, so if the user doesn't stay
logged into their email account, they are going to get login prompts every 6
hours. If you use multiple emails, that means constantly cycling through your
various gmail accounts every time the certs expire.

I think you need to allow flushing the key pair manually or else you're saying
there really is no way to "Log out" with this. Worse, a user will click 'Log
out' on their site, but the cert is still active so anyone can walk up / pick
up the device and log right back in. So what we've been taught "make sure you
log out and then quit the browser" wouldn't actually apply anymore.

Last thing for the night... If a site falls victim to a XSS vulnerability,
does this mean an attacker can call id.get() and steal a users assertion, send
it to themselves, and login as a user of my site by replaying the assertion?
This is like stepping back to IE5 where cookies couldn't be HttpOnly!

~~~
callahad
Oh, sorry, there absolutely are prominent ways to log out / flush the keypair
manually. It's after 02:00 local, so I need to get some sleep :).

As to XSS, the assertion that's transmitted to a site is scoped to that
specific site, and is only valid for, iirc, 2 minutes. So replay attacks are
severely constrained. Plus, the only meaningful data they contain is the
user's email address, so phishing doesn't get you much of value or put the
user at risk.

~~~
zaroth
So that's a 'yes' this exposes authentication to XSS, albeit the attacker will
have to hijack sessions in real-time as the assertions are forwarded to their
server.

That's a huge step _backwards_ in web security. Why pass the assertion to the
RP via the most insecure channel possible, i.e. the client-side javascript?
That was just the easiest way you could find so the RP could tie it to
client's session id?!

Obviously the assertion must be sent from the browser plugin directly to the
RP. You could do it by injecting an HttpOnly cookie for the RP's domain with
the encoded assertion. Javascript can never see it.

In the case of a secondary, the secondary already has an HttpOnly session id
with the end user, since they're authenticated in the first place. The
secondary would post the assertion back to the RP _directly_ at a well known
URL, and the RP returns a URL to the secondary with a nonce built in. The
secondary redirects the end-user to that nonce URL so the RP can give them an
HttpOnly authenticated session id. I think you can do this in a way such that
neither the assertion nor the nonce will be visible to client javascript.

Saying, 'oh your account can only be logged into by attackers for 2 minutes if
they can XSS the RP' is beyond disappointing, it's borderline negligent.

------
dendory
For most people, it goes like this: click on the Facebook login button, done.
OR, click on personaID, have a new window open, enter email, enter password,
go through setup, get back to site. This will be hard for most web users to
adopt.

~~~
Angostura
For other people it goes 'click the Facebook login button' - What? This POS
uses Facebook? What access does it get to my Facebook account? Is it one of
those weird things that posts all over my Facebook wall? [cancel]

~~~
27182818284
Generally I've noticed people are fine with FB login as long as you add "Don't
worry we won't spam your friends without your permission" or "We won't spam
your feed, we just want to know it's you." or something like that

------
Flimm
Mozilla Persona (AKA BrowserID) is exciting stuff. However, it doesn't seem to
have changed much since the last time it hit Hacker News [0].

There are websites that have chosen Persona as an authentication method. We
now need to see the following two pieces implemented:

\- It needs to be implemented in the browser's GUI, like in this old
screenshot [1]. People will be able to see the usability and security benefits
of having a standardised way to log in that's built-in into the browser. Could
we at least have a Firefox extension or a nightly build of Firefox that does
this?

\- At least one email provider needs to be a Persona "ID provider", which
would eliminate the need to create a Persona password and to click on a link
in an email. My guess is that getting Gmail to support this would be slow
work, why not try persuading smaller email providers like Fastmail to be the
first to openly support Persona?

Fortunately, Persona does work even without these two pieces, using fall-back
servers and a shim. But most of the benefits of Persona are only valid once
the browser and the email provider deliberately support it.

[0] - <https://news.ycombinator.com/item?id=2764824>

[1] - <http://i50.tinypic.com/2ptyv80.jpg>

~~~
callahad
Much has changed, but we haven't written about it yet. We're working on it.
This post to HN caught me by surprise. The new design went live, but we
weren't planning on announcing things until early next month. Trying to
stabilize and polish the new APIs, etc.

Native support should be coming in Firefox 17, albeit off-by-default. Native
support _will_ be enabled on phones running Boot2Gecko, which ship in Q1 next
year.

------
rangibaby
Random thoughts:

• The name "Persona" is odd considering something by the same name already
exists in Mozilla-land, a fact they seem to be aware of.

• I hope sites use this instead of forcing Facebook login!!

~~~
mcpherrinm
The other personas (aka "lightweight themes") are supposedly being re-branded
(thought I don't remember what they're calling them). It apparently hasn't
happened yet, which will surely lead to some trouble.

~~~
shalmanese
Why don't they call them lightweight themes?

~~~
gamzer
This comment sounds so innocent but it really started me thinking. When should
one call things simply by their name and when should one create a new name?

Would Twitter be the same if it was for short text messages? Or are Tweets so
different that they deserve their own name?

~~~
Angostura
Brands have value that can be protected with trade marks. You can't protect
generics with trade marks (easily)

------
jackalope
As an email provider for multiple domains, I have a hard time seeing what this
actually has to do with current email infrastructure. It seems the only time
the email address is used is to support a fallback notification, in which case
many of the claimed benefits of BrowserID are lost (as you've fallen back to a
single centralized identity provider).

Correct me if I'm wrong, but BrowserID/Persona assumes that for a
user@example.org identifier there is a corresponding <https://example.org>.
That's not true for most of the domains I support. In many cases, example.org
doesn't even resolve to to an IP address and web servers are only run on
subdomains (and not all subdomains have HTTP servers). Does BrowserID/Persona
support a DNS mechanism to discover the location of the required HTTPS web
server, similar to an MX record?

The opposite problem is where a user has a single email account with multiple
valid addresses at multiple domains, such as user@example.org,
user@foo.example.org, user@bar.example.org, etc. I work for an organization
approaching a million users where this is the case and isn't going to change
anytime soon. Once again, you can't assume there is an identity provider
running on a web server at all of these domains. Is there a DNS-based method
of discovery to solve this problem?

Does BrowserID/Persona allow users to authenticate against the same system
they use when accessing email? If so, why does the OpenPhoto example ask for a
password? I thought the whole point was that users avoid sharing credentials
with sites. That implementation is very confusing and looks like a scary
phishing attack.

Finally, it's not very clear what I should expect in the way of connections
from other computers, _whether I'm running an identity provider or not_. This
is crucial information to avoid tripping an intrusion detection system (IDS)
during unexpected connections, especially from my own users.

------
wmf
Now if we can just get Chrome to agree on the same protocol.

~~~
nightpool
Technically, this will work with chrome as-is, it just won't have a slick
native interface. The basics are already implemented by Mozilla as a HTML/js
library you can use on any browser.

~~~
drivebyacct2
It wouldn't even be that hard to have an extension scan the dom and offer the
signed assertion automatically as Firefox would/could.

------
qznc
I tried the OpenPhoto example. One thing that introduces friction compared to
username-password: The first time, I have to create a Persona account.
Unfortunatelly, I'm not logged in afterwards.

Most sites nowadays log you in right after account creation and just wait for
email-verification later. Is that even possible with Persona?

~~~
callahad
Yeah, that totally sucks, and we're working on it.

OpenPhoto is still using our old API, which can't handle post-verification
redirects. Our new API does this automatically. Grab a mailinator account and
try signing in to <http://123done.org>.

As for creating a Persona account, we're trying to fix that, too. Next month
we'll be turning on a feature (codenamed "bigtent") that verifies Gmail,
Hotmail, and Yahoo users by sending them through their respective provider's
OpenID or Oauth endpoints. No more new account creation. No more email
verification loop. Just three clicks and you're done.

~~~
Flimm
The webpage should suggest a website other than OpenPhoto, then. First
impressions count. (I say this as someone who's really excited by Persona and
who wants it to spread as quickly as possible.)

------
hinting
Honest question: As an app builder, why would you use this instead of
facebook?

Many more users are going to have Facebook logins already, and it provides
social information that may be useful to your app.

(Hoping to hear answers other than the dev-centric 'I don't like facebook')

~~~
moxie
Exactly, and I think it's possible that Mozilla just doesn't understand this.
Webapps aren't attracted to identity providers because they want to avoid
managing a user table in their database, but because existing identity
providers like Facebook provide a set of "social" APIs that can support the
webapp. I can't see why a site would be drawn to BrowserID instead.

~~~
callahad
> _I can't see why a site would be drawn to BrowserID instead._

There's more to Persona than liberating you from your password column.

Nevertheless, there are still _huge_ classes of applications that don't
benefit from social features, but _do_ want the improved experience that
Persona can offer. Think banks, universities, corporations, and governments.

So even in the absolute worst case versus Facebook Connect, we still have
enormous potential for alleviating the pain of per-site passwords and
containing the damage from security breaches in day to day life.

------
sebastianmck
Was picking the name Persona such a good idea when it's so close to Personas,
another Mozilla product?

------
Lockyy
I've been sitting around thinking about implementing a user system on my
current (and first) website to try and keep people returning to the site to
see people responding to their stories etc.

Now I'm wondering whether to use Persona or build it myself from scratch.

------
allenap
First reaction: the bland beige looks terrible (maybe that's because I'm not
American; I always notice that 1/2 of everything is beige when I'm in the US).
Combine that with the name and I'm reminded of the Persona contraceptive
device.

------
SCdF
One thing that I don't get about BrowserID is how it's supposed to work on
shared systems / web cafes. There doesn't seem to be any obvious way to log
out. The best you can do is 'log me out after an hour', which is crap.

------
carlesfe
Okay, I have read the specs, the FAQ, the diagrams, and tried some examples,
but I can't really understand how it works.

Could somebody do a quick summary for me? I would appreciate it very much.

~~~
callahad
I really, really need to post something like this on our blog soon. Watch
<http://identity.mozilla.com/> for something more polished next week or so.
I'd also strongly urge you to just try implementing it on a site. It'll
literally take less than 30 lines each of javascript on the frontend and
python on the backend, and it'll really demystify the flow between the site
and the user.

As an analogy, we work really similarlu to showing a bouncer your ID. The ID
has identifying information on it, and it has features that allow you to know
that it's authentic and hasn't been tampered with. The bouncer can learn how
to validate IDs issued by many different authorities, and can remember this
when he sees other IDs from that same authority.

Our IDs are personal public/private keypairs, signed by the email provider.

So, quick and dirty, here's how we work:

I want to log in to 123done.org as foobar@eyedee.me, but to do that, I need an
ID with eyedee.me's digital signature on it. So in a popup, my browser sends
me over to eyedee.me to ask for that signature.

Before eyedee.me will sign a public key with my name on it, I have to prove
that I really am who I say I am. It's just between the two of us, so I can
prove my identity however eyedee.me wants. It could be a password, an RSA
keyfob, or entering a code from a text message. Whatever it is, eyedee.me is
happy that I am who I say I am, and they sign my key and hand it back.

I want to show this to 123done.org, but it's not enough for it to be valid,
since we have to prevent malicious websites or phishers from copying it and
masquerading as other people. For my ID to be a valid login token, I have to
add two more things: what site I'm logging in to, and a timestamp so it
expires soon after I hand it over. I then sign that with my private key.

I then take that whole bundle and hand it off to 123done.org.

123done verifies it by asking for eyedee.me's public key (which can be
cached), and seeing if that matches the first signature on the ID. If it does,
then 123done pulls out the validly signed public key, and checks if it matches
the second signature on the ID. If that matches, then the whole package is
valid, and 123done knows that I really am foobar@eyedee.me.

Does that make sense? It really just revolves around a document with two
signatures: An email provider's which says "This key is associated with this
account," and a user's which says "I am associated with that key."

~~~
Nic56
So in your example, eyedee.me is your email provider, right?

I made a Persona account just now. All I saw happening was that I clicked on a
link in a confirmation email. Was there also communication between mozilla and
my email provider? (I am with a small ISP who is serving my emails - I have my
own domain, so my email address is sthg like me@myname.com). What went on
behind the curtains, if anything, and why did it work with my small provider
right away?

~~~
Flimm
No. The fact that you had to click a link in an email is a workaround. If your
email provider did support Persona, you wouldn't have had to do this.

That's the great thing about Persona: it works even when email providers don't
support it. However, it works best when they do.

------
znq
What about native mobile apps? Is it possible to easily use Browser ID for
native iOS and Android apps? Or is it just too much of a hassle getting the
information out of the web view?

~~~
znq
I just found this <https://github.com/mozilla/browserid-ios> however haven't
tried it out, yet.

~~~
st3fan
Let me know if you need help with that code or if I can answer any questions
in general about Persona integration on iOS.

You can contact me through Github or through the project's issue tracker.

------
andyfleming
<http://mootools.net/forge/p/browserid>

^ adapted from this?

~~~
ubernostrum
That is an implementation of BrowserID :)

------
drivebyacct2
I really, really like Persona. It's federated and it gives the identity
provider a vast amount of control over the security protecting accounts.

Want to use SSH keys for auth? Okay. You can do that.

~~~
alberich
Do you have any links to specifications on it? I'm very interested on identity
federation. But the post doesn't give away much info on persona's
capabilities.

~~~
callahad
<https://github.com/mozilla/id-specs/>

Pull requests and new issues welcome :)

------
Of_Prometheus
Is there a list of all the sites, besides Open Photo, that have already
enabled BrowserID?

~~~
callahad
Mozilla has tons of stuff in production running Persona, so we're totally
dogfooding with Bugzilla, Mozpad, MDN, Add-ons Builder, Firefox Affiliates,
Firefox Flicks, Mozilla Marketplace, and Mozillians.

Voo.st, OpenPhoto.me, Crossword.TheTimes.co.uk, 5apps.com, Haskellers.com,
etc. We're also working to get Persona working with some larger sites, but
most of those are waiting to go live until after we formally announce API
stability next month.

------
five_star
Though this is something helpful, I find Mozilla a little slower than google
chrome.

------
rtyrtyrtyrty
EPIC FAIL:

<http://www.freeimagehosting.net/us75p>

This buq with webfonts are reporter year ego and stili NGASF on Windows xp
Firefox 13.01 its start on Firefox 4

~~~
nnethercote
I think you're in the wrong thread.

