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.

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.

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

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.

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.

I give stackoverflow three days.

I've pasted your comments into a bug report: https://github.com/mozilla/browserid/issues/2539

Feel free to jump in if you have ideas on how we can phrase this better.

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?

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

Can I suggest a clearer explanation in the quick start guide of loggedInEmail and it's options and that there is a comparison of the name supplied from the site and name inside the browser - it is a bit confusing to see onlogin get called without a button being pressed. I would suggest walking a dev through what to expect - the code examples are great but the quick start is written by someone who understands what's going on behind the scenes - there is a sentence About currentusr that completely floored me - I could not understand how I was supposed to know bob was logged in if that was the first time he arrived at the site. In the end I gave up and read the docs !

Edit - needed bigger text box on ipad

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.

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.

The use case seems to be more for sites like twitter, hacker news, reddit, etc...

Basically, your browser knows your identity, so it can automatically authenticate you with any supporting website. You never have to set up an account with the website and you never have to enter a password.

That's my understanding of it anyway.

The developer reference has much more information: https://developer.mozilla.org/en-US/docs/persona

If you haven't tried it out yet I encourage you to do so...it only took me 30 minutes to get up and running the first time around.

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.

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.

That is, the Persona "forgot password" is a single point of failure which, if compromised, can provide access to a whole ecosystem of sites. And it will be tied to your email account.

Maybe it would help if we considered two hypothetical scenarios. A: Your email is compromised, and you're registered on 15 websites with that email, each of which has a "forgot password" option. B: Your email is compromised, and you've used Persona to sign into 15 websites. In what concrete, practical way is B a more damaging situation than A?

1) Fight to get your email account back

2) Visit each and every site and manually recover your account

You should definitely use 2-factor authentication for your email!

You're right. Gmail does an excellent job with ensuring account integrity. I've lost and subsequently recovered access to Gmail accounts, and I must say they do it right. And like you said, I especially appreciate their two-factor auth.

I hope lay people are coming to realize the security importance of their email accounts.

This is my concern; a compromised email account means a compromise of your account on every Persona-enabled site.

That’s just how their fallback provider works. BrowserID — the protocol — does not rely on email in any way. There’s no guarantee that if you have valid assertion for [email protected] there’s also an email account by that name.

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.

There is no message in my email that I care more about than the one that might give you access to my bank accounts.

This is very well phrased. Email sort of serves two purposes these days, each with very different security models: text-based communication, and external service authentication. Do you have any ideas for separating these two functions, or at least improving their security?

Or maybe not even that -- I use 2-factor for Google and FB -- where SMS is in the mix -- SMS could even be the recovery mechanism, moving even those messages out.

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 ([email protected] or [email protected])

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

4.post authentication it takes you to the website with user session as [email protected]/[email protected] - 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 [email protected]/[email protected] - 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

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. :)

Yes. In this case the "it" that prompts for your password will be an iframe served from gmail/yahoo. Once they support Persona natively, login.persona.org is no longer in the loop and your gmail/yahoo password goes directly to gmail/yahoo.

Why not redirect to GMail (openid-style) with a callback (or failing that, use a pop-up)?

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.

Getting UX right is a priority for Persona.

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

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

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.

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

Also, we still haven't completely shored up the IdP-facing API (there are a few rough edges to fix before committing to it), so the specifics are still subject to change. https://mockmyid.com/ and https://eyedee.me/ are both open source, example IdPs that we're using for testing.

Go to http://crossword.thetimes.co.uk/ - this is a non-Mozilla RP

Enter [email protected] - This is a Primary Identity provider, source at [1]

So you see there is no BrowserID provider choosing screen, it's naturally part of the flow. you enter [email protected] and the system checks for support and delegates to eyedee.com.

[1] https://github.com/mozilla/eyedee.me

login.persona.org is two things:

1) A JavaScript shim for cross platform support (Opera + BrowserID support would avoid this)

2) A Fallback Identity provider (eyedee.me avoids this)

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

The web and OSS is so amazing.

Plus, your keys are stored in the browser, according to callahad, so Mozilla doesn't have to know where you signed up: http://news.ycombinator.com/item?id=4232774

Also, in the future you probably won't even need to contact Mozilla anywhere in the process: your browser will store your certificates for you, natively.

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

Persona doesn't attempt to solve this existing problem.

You can use any browser and if it has native support, it will do the client side crypto. It will store your public/private keys in the client.

You can use any Identity provider (email provider probably) and if they have native support, they will store you password and do 2 factor auth or whatever.

This removes websites (relaying parties) from the password storage business. All they get is an email address and a way to cryptographically check to see that you owned it.

The crypto that powers the BrowserID protocol is an open standard, so you can vet it. It's been designed by crypto experts in an open forum.

After that the identity provider just gets requests from services that do not know its public key yet, but typically it is asked only once per service as the key is stored in a local cache. And even when the key is asked, the provider cannot know for which email verification address it is needed.

All in all I think this is a great system. It puts a lot of trust in the e-mail provider, but I think that's all right as the provider already has full control of your personal e-mail anyway and hence is trusted by default.

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

* 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

Needs to be updated a little bit, but check out the spec: https://github.com/mozilla/id-specs/blob/prod/browserid/inde...

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

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

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

It looks very lovely.

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/

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?

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.

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 ?

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.

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.

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

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

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

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

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

Evidently I need to pay more attention.

The Firefox themes were renamed to... background themes. It's just that the addons team (which owns getpersonas.org) has been hard at work on the new Mozilla Marketplace, and the Persona team has been hard at work on Persona. A few of the Persona devs are going to hack on this next month and try to get a disambiguation page deployed. We don't want theme-seekers to get lost, but we also don't want to lose people looking for the authentication system, so a straight 301 isn't ideal.

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.

So are there built-in, HTML-only versions for this in the works? It seems it should be possible to build some of this functionality into the browser, making it work without JS.

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.

I wouldn't call that progressive enhancement. Depending on whether the client has JS enabled, they would go through entirely different registration and auithentication processes, using different credentials. That can be very confusing to the users.

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

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?

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.

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

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.

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.

It's decentralized. It's an open protocol based on an older open protocol.

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?

  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.

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

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.

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.

I haven't found anything about manually revoking a cert, but I haven't looked either.

So you can do that before you leave that public computer, or you can use private browsing / incognito mode so that cookies and local storage stay in RAM and disappear when you exit.

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.

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

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

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

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

https://github.com/mozilla/id-specs/blob/prod/browserid/inde...

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.

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