A new API for Persona

Aug 1, 2012 — by callahad

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

Jul 24, 2012 — by stomlinsonmoz

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

Jul 13, 2012 — by warnermoz

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

Jul 11, 2012 — by benadida

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

Jul 10, 2012 — by fmarier

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

Jun 28, 2012 — by callahad

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

May 14, 2012 — by callahad

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

Feb 22, 2012 — by millsd

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

Feb 16, 2012 — by ozten-mozilla

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

Feb 7, 2012 — by millsd

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.

Identity at Mozilla