Identity at Mozilla

New Persona Beta: Millions of Users Ready to Log In using Any Browser

Tue, 09 Apr 2013 08:00:00 -0700

Persona, Mozilla’s easy and safe way to log into your favorite websites, using any modern browser, is now in Beta 2. The goal of Persona is simple: we want to eliminate passwords on the Web. This release, packed with performance improvements and new features, brings us another big step closer to that goal. In particular, we’ve made it easy for users with existing Web accounts to log in without creating a new account or password. This brings secure login within two clicks for hundreds of millions of users worldwide, regardless of whether they’re on a desktop, tablet, or mobile phone.

We’ve recently seen a few notable sites implement Persona, including: Born This Way Foundation, Firebase and the Orion Project. These deployments highlight Persona’s simple implementation, ease of use, user-safety, and the fact that, because Persona is built by a non-profit, users – and only users – own and control their identity. Let’s show you Persona Beta 2 in action:

Identity Bridging

The most important feature of Persona Beta 2 is Identity Bridging, where users can log into Persona-supporting web sites with their existing accounts. We’re starting with yahoo.com. Try it now on our sample site 123done.org: click “Sign in”, enter your yahoo.com email address, and go!

Websites that use Persona benefit from this improvement immediately: hundreds of millions of Web users are now ready to log in with just a few clicks. Users have complete choice and a simple flow: click one login button and select your preferred email address. Identity Bridging kicks in dynamically based on the user’s chosen email address.

The technical details behind Identity Bridging are detailed on the Mozilla Hacks blog. You can also read a detailed Q&A with Lead Engineer Lloyd Hilaiel.

More Improvements

Twice as Fast. We know performance is important to every site, so we made our button and popup load twice as fast. We’re working on more improvements as we go.

Use your Existing Accounts. We’ve bridged yahoo.com, but of course we built an open system: any domain can now become a Persona Identity Provider so users can reuse their existing accounts on any site that uses Persona.

Built Into Firefox OS. We built in support for Firefox OS and made Persona much faster on all mobile devices. This gives Firefox OS apps an even better experience when using Persona.

Adoption

Our adopters make us blush with the nice things they have to say about Persona.

Tara Tiger Brown of Born This Way Foundation commented: “Our mission at Born This Way Foundation is to promote a kinder, braver world where youth feel empowered to be themselves in a safe and supportive environment. In order to support our mission, we must keep our Born Brave Nation members’ identities and information safe. Mozilla Persona is a single sign-on online identity system that respects user privacy, very user friendly and simple to setup and maintain.”

Anant Narayanan of Firebase, makers of a scalable real-time backend that lets developers build apps fast without the hassle of managing servers, said “We added support for Persona as one of the authentication mechanisms for our Simple Login service, and we are very pleased with the result! The distributed nature of Persona and its elegant API makes it the ideal candidate for the types of apps we want people to build with Firebase.”

Ting, Tucows’s mobile phone service that makes sense, implemented Persona and said “The fact that user privacy is one of the foundations on which Persona is built means it’s the first single sign-in solution that we feel is worthy of recommendation and of implementation.”

Barry Warsaw, who runs the omnipresent GNU Mailman mailing list manager, added “GNU Mailman 3 chose Persona as our primary authentication mechanism because its email-based login system is a perfect fit for our mailing list software. All we need to identify a person is confirmation that they own their subscription address, and integrating Persona made that verification easy. Ideally, we’d like to do away with passwords altogether, and with Persona, this is now possible.”

Simon Kaegi of the Orion Project added “Persona is the simplest means of high quality authentication I’m aware of. In our UX review, Persona was clearly superior to OpenID.”

Discourse, the company rebooting online discussion forums, added Persona support to its codebase and enabled it on its own discussion site, adding “It has a very slick user experience, so we hope people try it out.”

Julius Schorzman of DailyCred, the instant CRM package for any web site, implemented Persona and remarked “We’ve seen from our internal metrics that more than 70% of users still prefer email and password authentication over social log-in like Facebook. Implementing Persona is actually easier than Facebook Connect, or any OAuth implementation we’ve seen.”

Acros Security, the third-party reviewers we brought in to audit Persona, told us “We’re quite impressed with the level of security [of Persona] and, although paranoid by design, we will be able to trust it with our own online identities.”

Your Turn

We’re building Persona in the same way we do everything at Mozilla: in the open, with your help and contributions. Now it’s your turn. Deploy Persona on your web site. Turn your domain into a Persona Identity Provider. Tell us what you need to make Persona even better. Want to fix it yourself? Send us a patch.

Together, in the open, we will continue to build a login system that is better: Better for users, better for web sites, and better for the Web.

UPDATE: We mistakenly attributed a quotation to the Eclipse Foundation’s Ian Skerrett. It should have been attributed to the Orion Project’s Simon Kaegi. The text above shows the correction.

Persona on Firefox OS phones

Thu, 04 Apr 2013 09:25:41 -0700

You’ve probably heard about Firefox OS, Mozilla’s major effort to create a free mobile phone ecosystem using HTML5 as the one platform you need to develop rich mobile apps. You can expect Firefox OS phones in stores in South America later this year.

What you may not yet know is that we built Persona into Firefox OS. When invoked on Firefox OS, Persona presents a natively-optimized, trusted interface for logging into your favorite app or web site, including the Firefox Marketplace. If you use Persona, you don’t need to change a thing. You’ll get the native interface automatically on Firefox OS devices. That’s the beauty of the JavaScript shim approach we took: it works on all browsers, and it automatically improves on devices that support the Persona API natively.

we don’t need another silo

We could have done what every other company does: simply build Firefox OS accounts optimized for our operating system, focused purely on Mozilla. But that’s not how we do things. Our mission is to give users sovereignty over their Internet experience, to help and defend the Open Web. So we built Persona, an Identity System for the Web, and we’re iterating it to make sure it provides tremendous user and developer value while preserving real user choice. Then, we built Persona into the Firefox OS phone.

faster, especially on data connections

We’ve done a good bit of work to make Persona faster on slower data connections. We optimized our font delivery. We optimized our crypto library. Overall, Persona is now twice as fast now as it was a few months ago. And we’ve got more tricks up our sleeve to continue to make Persona fast.

innovation: from mobile to desktop

We started by innovating on mobile, with native Persona on Firefox OS. The mobile constraints helped us focus our native implementation and make the right engineering compromises. Now, we’re taking those lessons and bringing them to Firefox on Android and Desktop. Native Persona support on all versions of Firefox is coming.

As always, we welcome your questions and comments on our mailing list, or via the #MozillaPersona hash-tag on Twitter.

Persona is distributed. Today.

Tue, 26 Mar 2013 16:25:00 -0700

With Persona, you can log into web sites using the email address of your choice. The first time you use an email, our servers send you a confirmation link. By following that link, you confirm your identity to Persona, which then vouches for your ownership of that email address.

Of course, in the long term, Persona is meant to be distributed: alice@example.com should be verified and certified by the administrators of example.com. If example.com wants to use 2-digit passwords, they can. If they want to use retinal scans powered by your webcam, they can. It’s up to them. With each domain able to customize its authentication protocol with its users, the Web becomes more secure.

Did you know that Persona supports this today?

If you own a domain, you can claim your users without asking Mozilla. Just follow the Persona Identity Provider protocol as described in our Identity Provider Guide. You can also start with the code for eyedee.me, our example Identity Provider. Just connect this code to your user database and advertise your domain as a Persona Identity Provider.

Pragmatic, Gradual Distribution

We don’t expect the world to switch over to a distributed authentication protocol overnight. In fact, we expect to be running the Persona Identity Provider, which we call the Fallback, for a long time and for a lot of users. Building new distributed protocols takes time.

That said, we’re not waiting around to make Persona capable of distributed authentication. For those users and domains who want it, Persona is already distributed. We think that’s pretty cool.

As always, we welcome your questions and comments on our mailing list, or via the #MozillaPersona hash-tag on Twitter.

we're changing our privacy policy

Fri, 22 Mar 2013 09:47:40 -0700

“We’re changing our privacy policy…” Does that sentence fill you with dread? Most of the time, unfortunately, it should. Too many web services change privacy policy to increase collection and use of your data. It’s often hard to keep up with these changes.

In this case, you can rest easy. We’re making the Mozilla Persona privacy policy better for users. We simply noticed that we claimed we were retaining data which, in fact, we do not retain. Specifically, we do not retain the list of sites you visit with Persona. We’re tightening the language of the privacy policy to state that explicitly.

At Mozilla, we use your data only to serve you. We also work hard to minimize how much data we collect: we don’t collect data preemptively, “just in case” we need it for future features. Check out the Mozilla Privacy Principles.

And since all our code is public, you can review the privacy policy patch we just committed to our public code repository. This policy should go live in the next couple of weeks.

As always, we welcome your questions and comments on our mailing list, or via the #MozillaPersona hash-tag on Twitter.

Users don't like social login

Wed, 20 Mar 2013 10:06:28 -0700

We were very happy to see the revamped “Log In with Google Plus” product from our friends across town: big improvements in user experience, great mobile integration, and clearer privacy controls. Still, we think Identity on the Web can be better: easier for developers, true choice and control for users.

In particular, we think login should be personal and minimal first, social later. We’re not the only ones who think so, as TechCrunch reported:

Some people don’t have Facebook or Twitter accounts. Others have deleted them to live a more “real” existence. Then there are those with social accounts, but who don’t want to give their most private data to just any developer. Their biographical info, location, interests, and the ability to post things to their friends are not things they want to give away without some vetting.

[…]

Rockmelt co-founder and CEO Vishria tells me his company learned a big lesson […]: “because of privacy implications, people want to try an app with email and then add social later if they like it.” I call this “try before you pry,” and Vishria explains “there’s a certain level of trust that builds over time.”

That’s why a login with Mozilla Persona delivers only the user’s preferred identity to the site.

Users, not Sites, should choose their Identity Provider

We also noticed that users dislike the NASCAR-style plastering of branded login buttons. If the user recognizes none, she’s forced to use a new identity provider. If the user recognizes one, the others are distracting. If the user recognizes more than one, she’ll likely forget which one she used the first time, click another one the second time, fail to retrieve her data at the web site in question, groan, and start again.

We can do better. The user should see only options relevant to her!

With Persona, the user chooses any email address she wishes. Only the user’s own email addresses are ever displayed. When returning to a site, the last-used address is even pre-selected.

Privacy, even from the Identity Provider

When logging in with Google Plus, users choose how much to reveal to their friends. However, users still cannot choose how much to reveal to Google: Google learns every user’s login at every site. It’s as if a hotel receptionist called up the Department of Motor Vehicles to inform them of your checkin because you provided a driver’s license as identification. A bit jarring, in our opinion.

We built the Persona protocol to reduce data sharing to the minimum needed for the user to easily log in: the browser mediates the login without leaking data to the identity provider. In the end, Persona is the easy login solution that respects users.

Want to add Persona login to your site? Read our quickstart. Or, if you’re more adventurous, you can turn your domain a Persona Identity Provider and directly certify your domain’s users.

As always, we welcome your questions and comments on our mailing list, or via the #MozillaPersona hash-tag on Twitter.

Persona plays well with Firefox's third-party cookie policy

Mon, 25 Feb 2013 14:36:31 -0800

Firefox is experimenting with a new third-party cookie policy. Alex Fowler, Mozilla’s Lead on Privacy and Public Policy, puts it this way:

On Friday, Mozilla released a Firefox patch into its “Nightly” channel that changes how cookies from third party companies function. Users of this build of Firefox must directly interact with a site or company for a cookie to be installed on their machine.

Firefox is exploring this change because we believe it’s good for the Web. We did not test other Mozilla web sites first, because we do not play favorites. For example we didn’t know for sure, when the change was applied to Firefox Nightly, whether Persona would continue to function as expected. We believe this Firefox cookie policy change is good for users, and all of our products should live by the rule we’re proposing.

Of course, since Persona is built to respect user privacy, we don’t set a cookie unless you directly interact with Persona. So it is without much surprise that our first tests indicate that Persona works just fine with Firefox’s new third-party cookie policy.

Persona will always strive to provide the easiest login solution for users and developers, all the while protecting user privacy. It’s good to see that our approach meets the criteria set by Mozilla’s very best privacy minds.

A Node.js Holiday Season

Thu, 20 Dec 2012 12:33:00 -0800

JavaScript is at the very heart of Persona: even its server-side components are written in JavaScript, thanks to Node.js.

The Persona team is currently writing a series of fortnightly blog posts on our experience with Node.js, and the first four articles are already available:

This is just the beginning of the Node.js Holiday Season blog series — we have eight more articles planned.

Announcing the First Beta Release of Persona

Thu, 27 Sep 2012 08:01:00 -0700

For the past year Mozilla has been working on an experimental login system that completely eliminates passwords on websites while being safe, secure, and easy to use. Today we’re casting off the “experimental” label and announcing the first “beta” release of Persona.

Persona is ready to use for authentication: it works in all major smartphone, tablet, and desktop browsers, the user experience has been thoroughly reviewed and polished, we’re committed to the core APIs, and its infrastructure is highly available and stable.

What’s it like to integrate Persona? Check out this video from The Times Crossword:

“[Persona] was definitely easier than OpenID or OAuth because it can almost all be done on the client side in JavaScript.” — David Somers, News International

We haven’t just refined Persona, we’ve also significantly improved it since we first introduced it. Over the past few months we:

Completely refreshed our brand, changing from the “BrowserID” codename to “Persona.”
Developed an entirely new (and better) API.
Streamlined the first-time user experience.
Added support for showing your site’s name and logo in the login dialog.
Enhanced the login dialog to optionally include links to your site’s terms of service and privacy policy.

These changes have been well received and we’re seeing Persona gain traction outside of Mozilla. If you are a developer, now is the time to try Persona out. Persona is an open source project and we gladly welcome input and collaboration from the broader community via our mailing list or our IRC channel (#identity on irc.mozilla.org).

This is the first of many beta releases, and we have some fantastic things planned for the future.

So, what are you waiting for? Persona coexists well with existing login systems and only takes a single afternoon to integrate. What’s more, because Persona logins are based on email addresses, sites still maintain a direct relationship with their users. Check out the documentation and add Persona to your site today!

Committing to a Stable API for Persona

Mon, 17 Sep 2012 11:11:32 -0700

Later this month, we will be announcing the first “beta” release of Persona. Part of that announcement will include committing to long-term support for our APIs, so that developers can more confidently rely on Persona in their sites and applications. This post will serve to outline the deprecation strategy that Persona will adopt for its beta releases.

How is deprecation handled?

Before deprecating or making backwards incompatible changes to stable APIs, the Persona team will announce the change on the Persona-notices mailing list. The team will also add deprecation warnings to the relevant code and documentation.

The notice will be posted at least six months prior to the change taking effect. After posting the notice, the team will listen for feedback and monitor the ongoing use of the API. Depending on these metrics, the deadline may be extended once by an additional six months. Any extension will be communicated via the Persona-notices mailing list.

Can changes happen more quickly?

Yes. If a security vulnerability necessitates a backwards incompatible change to a stable API, then that change may be expedited and a message will be sent to Persona-notices.

Backwards compatible and cosmetic changes may also be expedited.

What APIs are covered?

Beta 1 will only stabilize the subset of Persona APIs that are necessary for authenticating users. Subsequent beta releases will eventually extend this commitment to the remaining APIs, Persona’s data formats, and the cross-browser shim.

Specifically, the first beta release will only commit to:

id.watch() and its loggedInUser, onlogin, and onlogout options.
id.logout() without any parameters.
id.request() with its oncancel, privacyPolicy, termsOfService, returnTo, siteName, and siteLogo options.
id.get() with its privacyPolicy, termsOfService, siteName, and siteLogo options.

What about APIs that are already deprecated?

APIs that are undocumented or already marked as deprecated may be removed more rapidly. This includes:

id.getVerifiedEmail().
The loggedInEmail and onready options for id.watch().
The privacyURL and tosURL options for id.request().
id.logout() when passed a callback as its first parameter.
The requiredEmail, silent, privacyURL, and tosURL options for id.get().

If you are using any of these undocumented or deprecated APIs, please update your code. As per usual, backwards incompatible deprecations will be announced on the Persona-notices mailing list in advance.

What resources are available to help with upgrades?

While the APIs are fully documented on MDN, the Persona team is committed to supporting developers that rely on Persona.

If you have questions regarding upgrading your code in response to a deprecation notice, please contact us via the dev-identity mailing list or stop by our IRC channel: #identity on irc.mozilla.org.

Lastly, if your site depends on Persona, or you are supporting people who do, please subscribe to the Persona-notices mailing list.

Application and Platform Integration of Persona

Thu, 06 Sep 2012 13:01:37 -0700

We are happy to see Persona gaining traction in the developer community, with dozens of sites and services integrating Persona to simplify and speed up the login process while simultaneously eliminating site-specific passwords for users. Some recent Persona adopters include:

LoginRadius, an embeddable authentication widget, permits quick integration of Persona and other authentication systems within many platforms, languages, and frameworks. We’re excited to see Persona amongst their login offerings, giving their partners a new, simple way to authenticate users.
Mahara, an open source e-portfolio system used by educational institutions around the world, has implemented Persona as an authentication system to allow users to log in to their portfolios and collaborate with others in groups on projects. Persona is included by default as of version 1.5 which was released in April 2012.
Koha, a popular integrated library system, is planning to include Persona as one of the default login mechanisms as of version 3.12. With this integration, both librarians and visitors will be able to access library resources using Persona.
The Eclipse Foundation is building Persona into the 1.0 release of Orion, an IDE that runs as a web application. By logging in with Persona, users will be able to organize projects and collaboratively develop software from the comfort of their browser.

For Ruby developers, OmniAuth offers a Persona module courtesy of Intridea. It’s available on GitHub at https://github.com/intridea/omniauth-browserid.

Similarly, Node.js developers can leverage Persona thanks to a Passport module from Jared Hanson of Helixent Technologies. The module is available on GitHub at https://github.com/jaredhanson/passport-browserid.

Lastly, a groundswell of community support has helped produce many more libraries and plugins, which you can find on our GitHub Wiki. If you’re curious about Mozilla’s own use of Persona, we’ll blog about that shortly. Until then, check out the django-browserid library — it already handles the authentication on sites like MDN.

If you’re considering adding Persona to your application or website, you can find documentation on MDN. Don’t forget to keep in touch via our mailing list or by tweeting with the #mozPersona hash-tag.

A new API for Persona

Wed, 01 Aug 2012 15:55:00 -0700

After gathering feedback from our users and our User Experience team, we’re excited to announce that we’ve implemented several important new features in Persona. These features include showing your website’s name and logo in the login dialog, a streamlined experience for first-time Persona users, and greater security thanks to global logout from any device.

In order to make these features a reality, we had to change our JavaScript API. Working with the community on our public mailing list, we’ve come up with a brand new way to use Persona on your site. We call it the “Observer API,” and we believe it’s the future of Persona.

We’ll be announcing a “Beta” release of Persona before the end of September, at which point the Observer API will become the recommended means of integrating Persona into your website. We do not plan to deprecate the previous API (navigator.id.get()) at this time. Nevertheless, we’re committed to working with our community to get everyone up and running with—and reaping the benefits of—the Observer API.

How Does It Work?

The Observer API consists of just three functions: At the time your page loads, you watch() for login/logout notifications from Persona. Whenever a user clicks the login button on your site, you request() a verified email from your user, which opens the Persona dialog. Finally, when a user logs out of your site, you tell Persona by calling logout().

This new structure is a great foundation for future refinements and improvements to the Persona experience: we couldn’t have delivered all of the aforementioned features without it! You can find out more by reading our documentation on MDN.

Where Can I Get Help Upgrading My Site?

As always, start with the docs. If you’re still stuck, drop us a line on our mailing list or stop by our IRC channel: #identity on irc.mozilla.org.

Let us know know what you think by tweeting with the hashtag #mozPersona!

Improvements to the First Time Sign-up Flow

Tue, 24 Jul 2012 09:28:00 -0700

The Persona team has always been interested in optimizing the user experience for developers and users alike. Some time ago we identified one area where we could improve: the first-time sign-up flow. We’ve been hard at work making this process as smooth as possible, read on to find out how!

The Challenge

The Persona sign-up flow is designed to leverage the user’s existing accounts and passwords if their email provider supports our protocol. For unsupported providers, we verify identities by sending a confirmation email. This flow potentially causes the user to leave the destination site to check their email, an action that can make it difficult to navigate back.

The Goal - Increase Completion Rates

The goal is simple - increase the completion rate. A completed user is one who has verified their email address, is viewing the destination site, and is authenticated to that site.

We previously experimented with redirecting users back to the destination site, but until recently there was no way to sign the user in. The new Observer API makes this possible - everything is now lined up to complete the flow.

The Observer API makes user verification seamless. Once a user completes* the Persona verification they are redirected to the destination site and automatically signed in. Information about the Observer API can be found on MDN.

Simplifying the Persona Sign Up Flow from Shane Tomlinson on Vimeo.

Redirect Verified Users to Alternate Endpoints

The new returnTo option to navigator.id.request allows a site to send users to an alternate endpoint after address verification.

returnTo is an absolute path, meaning it *must* start with “/”. Neither relative paths nor alternate domains can be specified.

navigator.id.request({ 
 ... 
 returnTo: '/pathToReturnTo.html', 
 ...
});

Support for returnTo and the other post-verification updates are live in production now. Check out the docs, give it a try, and let us know what you think. You can contact us through our mailing list, the #identity IRC channel on irc.mozilla.org, or on Twitter with “#browserid”.

===

* Only users who verify their email address using the same browser they used to start the signup will be redirected and signed in.

New Feature: Adding Your Website's Name and Logo to the Persona Login

Fri, 13 Jul 2012 06:55:00 -0700

One of the features we’ve added to Persona’s new Observer API is the ability for websites that use Persona (“Relying Parties”) to add their name and logo to the login screen. To do this, just add a siteName and/or siteLogo property to your navigator.id.request() call.

The default login screen only shows the website’s domain name, as illustrated below:

By adding siteName, you can put additional text in the right-hand RP area:

navigator.id.request({ siteName: "Tahoe LAFS" });

Or you can use siteLogo to add an image:

navigator.id.request({ siteLogo: "/logo.png" });

You can also use both, in which case the name will appear below the logo.

In all cases, the website’s domain name is displayed below the siteName and siteLogo, so the user knows for sure which site is going to receive their email address.

Restrictions (Use SSL!)

There are a few restrictions to be aware of:

siteName must be plain text: no markup is allowed. Unicode and whitespace is ok, but keep it short or the dialog box may clip.
siteLogo must be a site-relative URL with an absolute path (i.e. it must start with a ‘/’ slash). In the future, we’ll probably relax this requirement and enable absolute URLs and even data: URIs. Images larger than 100*100 pixels will be scaled down to fit.
siteLogo requires SSL. The login dialog is served over HTTPS, so the logo image must also be served over HTTPS (to avoid mixed-content warnings), which means your login page (the one that calls navigator.id.request()) must be served over HTTPS too. If you try to use siteLogo from an HTTP-served page, your users will actually get an “improper usage of API” error from the Persona code. But, as a respectable RP who cares about your user’s privacy, your whole site is already being served with HTTPS, right? Right?

Support for siteName and siteLogo rolled to production yesterday, so take a look at the docs and give it a spin. And let us know how it works for you, through our mailing list, the #identity IRC channel on irc.mozilla.org, or on Twitter with “#browserid”.

Mozilla Persona rebranding is live

Wed, 11 Jul 2012 20:59:34 -0700

You may have noticed that, as of tonight, https://browserid.org redirects to https://login.persona.org. The main site and login dialog have been re-branded, as we announced a few months ago, to Mozilla Persona. This is one big step in preparation for our Beta Launch in mid-August. If you used BrowserID before today, you will automatically inherit the new look-and-feel, and everything will continue to work for your users without interruption.

In the process, we added some great new features, which we’ll tell you about on this blog over the next few days. As always, we welcome your feedback via Twitter using #mozpersona or #browserid, and on our mailing list.

Security fix in Persona Verifier and new mailing list for important notices

Tue, 10 Jul 2012 14:47:55 -0700

Last Monday, we identified a security hole in the implementation of our Verifier. We deployed a fix in 6 hours. The full details of the issue are available on the wiki. If you’re running a site against our Verifier, you are safe.

We did our best to identify whether this issue affects other verifiers. To the best of our knowledge, there are no other implementations affected. If you happen to be running a custom verifier, please contact us so we can help you check.

Sign up for important Persona service announcements

We would also like to take this opportunity to introduce a new communications channel, persona-notices, for those who use Persona in production but don’t have time to read our developers list or this blog.

We will only post to the new list regarding topics that may require action by those who rely on Persona, such as:

security issues in popular Persona libraries and plug-ins
advance warnings about deprecations and incompatible changes to the API
changes to the URLs and/or IP addresses of the Persona services

In an effort to keep traffic to a minimum, fully backwards-compatible changes, like the introduction of new features, will not be covered on persona-notices.

We encourage all relying parties (RPs), identity providers (IDPs) and developers to join this list now.

If you have any other suggestions on how to improve our communication with those who rely on Persona, please let us know.

Deprecating requiredEmail

Thu, 28 Jun 2012 12:22:42 -0700

At the end of last year we introduced an experimental feature called requiredEmail which let websites ask a user to log in with a specific email address, rather than prompting users to select any address. Unfortunately, the use cases we had envisioned never materialized, and requiredEmail failed to find traction with our early adopters.

Since requiredEmail only acted as a shortcut through our UI, its removal will not break existing sites. Thus, after speaking with all known users of requiredEmail, we’ve decided on a rapid deprecation schedule.

Starting July 18th, the requiredEmail option will be deprecated and ignored. Websites using Persona will continue to work without interruption, as users will simply see the normal Persona login dialog which gives them the option of entering an email address of their choice.

While we expect to revisit this idea in the future, we’re taking the step of deprecating requiredEmail now so that we can focus on building a lean, stable, and well-supported foundation for Persona. On that note, let us know how we’re doing! Feedback is always welcome on our mailing list, in our IRC channel, or on twitter via the #mozpersona hash-tag.

Streamlining Login with Privacy Policy and Terms of Service APIs

Mon, 14 May 2012 07:25:00 -0700

A new feature landed in Persona last month that promises to make the sign-in process even smoother by asking users to consent to site-specific Terms of Service and Privacy Policies as a native part of the login flow.

This means that sites using Persona can easily present their own terms of service and privacy policy to users in an obvious, seamless, and uniform location. Moving user consent into the sign-in dialog also lets websites get rid of their “I agree” checkboxes, while still being certain that users were informed of and consented to the site’s terms on every sign-in.

Supporting this API is dead simple, saves users a click, and means one less form for websites to manage. We think it makes sign-in easier for everyone, and we’d love to see more sites using this new, optional feature. To learn more, check out our documentation and let us know what you think via our mailing list, IRC channel, or by tweeting with the #mozpersona hash-tag.

Introducing Mozilla Persona

Wed, 22 Feb 2012 12:54:00 -0800

This past year we’ve been building the core of a Web-scale identity system. We’ve been calling it BrowserID: our name both for the technology¹ and the Mozilla service that implements the technology. Today we’d like to introduce Mozilla Persona, our new name for the complete Identity offering from Mozilla: a collection of components and experiences we’re designing to manage the whole of a user’s online identity with our core values of user control, safety, and convenience.

The Persona name resonates with the idea of personhood as well as online identity as a facet of our lives, and therefore strongly tied to user identity. We’re very excited about this new name and the new features our identity system will offer. Some of the things we’re planning: an identity dashboard, user data interconnect features, and more.

What about “BrowserID?”

BrowserID remains the developer-facing name of the protocol. Websites, email providers, and browser implementors will continue to refer to the BrowserID protocol.

Over the next few months, we will begin to transition the Mozilla Web-based implementation of the BrowserID pop-up over to the new name. But don’t worry, we’ll work hard to make sure the transition is completely seamless for everyone.

Wait, what about Firefox’s Personas?

For the past few years, many Firefox users have enjoyed “Personas”—a quick and fun way to theme the background of the Firefox toolbar. The Addons team blogged about changing their name a couple of weeks ago. No doubt there will be some confusion during this transition, so if you have ideas for how to make the transition smoother, definitely let us know! We believe the long-term value of the Persona name will far outlast the short-term discomfort of change.

We hope you’re as excited about this change as we are. We look forward to an action-packed 2012 for our distributed Identity system under the Mozilla Persona umbrella!

As always, feedback and questions are always welcome on our mailing list, or by tweeting with the #browserid or #mozpersona hash-tag.

¹: Some of you may remember that BrowserID came from the Verified Email Protocol. We haven’t forgotten, of course—but BrowserID has become the name of the technology nonetheless.

BrowserID now available in 28 languages

Thu, 16 Feb 2012 13:49:12 -0800

We’re proud to announce that with the latest update to BrowserID the sign-in flow is available in 28 languages, in addition to English.

Like many of our previous updates, users and sites automatically benefit from the added feature without having to change anything. Users will see BrowserID in their preferred language, based on their browser’s settings.

Here’s what BrowserID looks like in traditional Chinese:

This change has been possible because of our amazing community of volunteers. Firefox ships in over 70 languages and that energy also powers our vision for a cross-platform identity management.

Along with ID provider support, shipping our service in multiple languages are two big milestones for BrowserID maturity.

Users of your websites can now have a native language experience in the following locales:

Afrikaans (af)	català (ca)	Čeština (cs)	Dansk (da)
Deutsch (de)	Ελληνικά (el)	Español (es)	Eesti keel (et)
Euskara (eu)	suomi (fi)	Français (fr)	Frysk (fy)
Gaeilge (ga)	Hrvatski (hr)	Italiano (it)	Ligurian (lij)
Nederlands (nl)	ਪੰਜਾਬੀ (pa)	Polski (pl)	Русский (ru)
slovenčina (sk)	slovenščina (sl)	Shqip (sq)	Српски (sr)
Svenska (sv)	Türkçe (tr)	中文 (简体) (zh-CN)	正體中文 (繁體) (zh-TW)

Dig Deeper

ID provider support now live on BrowserID

Tue, 07 Feb 2012 05:04:00 -0800

Last week we pushed out a BrowserID feature that gets us closer to the decentralized identity system we envision for the Web. But more than that, it enables a truly awesome user experience—registration flows go from 8 screens to one simple sign-in. Seriously! See for yourself:

Chicken or egg

Some context: Building a distributed system is a chicken and egg problem - you have to design a system that can demonstrate the power of your idea and the advantages of a distributed architecture while you bring in participants who will become actual nodes in the system. That’s why, so far, BrowserID has operated with scaffolding that uses the BrowserID service itself to vouch for email addresses.

With our latest update, however, we’re setting aside some of that scaffolding and allowing a fully decentralized system to emerge: Identity providers can become full-fledged participants in BrowserID and directly vouch for their users’ email addresses.

What’s changed and what you need to know

If you’re a website that’s already implemented BrowserID, you don’t have to do a thing: BrowserID is just better for you! Up to this point, Browser ID has been vouching for users’ email addresses on behalf of participating websites. Now email providers can directly vouch for their users, eliminating the need for an email confirmation step or a BrowserID password.

Note that this change only takes effect when the email provider for a given address implements BrowserID support. Other email addresses continue to work in the same way they do today, with an email confirmation and password from the BrowserID service.

With ID provider support, users will have a better, faster, smoother registration experience.

Give it a spin.

Attention email providers large or small: whether you’re an enterprise, an ISP, a university or institution, you owe it to your users to check out this key new feature of BrowserID. Now it’s easy and incredibly simple for any email provider to become an identity provider for their users.

Try out our demo ID provider at eyedee.me and your @eyedee.me address on any BrowserID site. Take a look at our code and documentation. Let us know what you think via our mailing list, IRC channel, or via the Twitter hashtag #browserid.