FAQ

  • Revision slug: Persona/FAQ
  • Revision title: FAQ
  • Revision id: 316057
  • Created:
  • Creator: Callahad
  • Is current revision? No
  • Comment

Revision Content

What's the difference between Mozilla Persona and BrowserID?

Persona is a complete implementation of a new, distributed login system from Mozilla.

BrowserID is the open protocol that governs how Persona works.

As an analogy: Persona allows users to log into sites by implementing BrowserID. Similarly, Firefox allows users to browse the web by implementing HTTP.

How does Persona compare to OpenID?

Persona and OpenID have very similar goals and a similar architecture. Both systems reduce the number of passwords that a user needs, and both are designed to be decentralized. This means that any domain can present itself as an Identity Provider without relying on a central authority.

Despite these similarities, Persona is easier to use and easier to add to websites. Persona also does a better job of protecting user privacy. Specifically:

Persona is easier for users
Persona identifies users based on email addresses, which users already know, understand, and naturally associate with online identities. With OpenID, users are forced to learn a new username: an unintuitive URL.
Logging in with Persona is also easier: it just takes 2 clicks after a one-time setup process.
Persona is easier for developers
Persona has a {{ domxref("navigator.id", "simple API") }} that only takes an afternoon to get started with.
Persona identities are email addresses, so websites don't have to ask users for additional contact information during signup.
Because users know and understand their email address, developers don't have to build complex pages with login buttons for all the popular OpenID providers.
Persona better protects user privacy
By design, OpenID allows Identity Providers to track their users around the web: whenever a user logs into a website, their browser gets redirected from that site to the user's Identity Provider, and then back to the site that the user requested. These redirects fully expose to the Identity Provider where the user is going.
In contrast, the BrowserID protocol never leaks tracking information back to the Identity Provider. Rather, it behaves similarly to an ID card: users obtain signed credentials from their Identity Providers which can be presented to websites as a proof of identity. Websites can check the validity of these credentials without ever revealing a user's identity to their identity provider.

Why does Persona require JavaScript?

Persona requires JavaScript, but some users choose to selectively block JavaScript by using browser add-ons like NoScript. Many of these users are concerned about the privacy implications of enabling JavaScript, since it is often used to track visitors across websites. However, in the case of Persona, JavaScript is actually used to enhance user privacy, as it allows the browser to perform cryptographic operations completely on the client side. By doing these operations on the client, Persona avoids the need to store secret keys anywhere other than in the user's own browser.

Does Persona guarantee that I get a working email address for my users?

No, Persona only guarantees the user's association with an address. As with any email address in any login system, it's possible that the address no longer works or is not regularly checked by the user. For most users, the email address will be functional.

How does Persona verify a user's association with an address?

Persona asks the address's domain, which is free to verify its users in any way it chooses. If a domain is not a native Identity Provider, and thus can't verify its own users, the browser asks for verification from Persona's fallback Identity Provider at https://login.persona.org. Before certifying a user's identity, the fallback Identity Provider does test the address by sending an email to it and asking the user to click a link contained within.

How can I handle account recovery if users lose control of their email address?

Can I self-host include.js, or must I include it from https://login.persona.org?

The code in include.js is still subject to change. It's not yet recommended that you host it yourself.

Can I verify assertions locally, or must I use the remote verification service?

To ensure user privacy, it's important that identity assertions are verified locally rather than with the remote verification service. However, the format of assertions is still subject to change, so local verification is not yet recommended. Even with remote verification, Persona protects the user from tracking by their identity provider.

Once the protocol has stabilized, libraries will be available to simplify local verification. Follow the Identity Blog to find out when local verification is recommended.

What tips are there for migrating users who are currently using other sign-in methods?

Despite Persona's benefits, it's never easy to move all of your users to a new login system. Conveniently, Persona's focus on email addresses makes it easy to use alongside existing login systems, so you don't have to switch all at once.

One particularly low-friction approach is to suggest Persona to users who forget their password. Instead of resetting passwords, users can simply log in with Persona.

How should I signal that "Sign In" also handles new account creation?

How do I find out about major changes to BrowserID, such as new or deprecated APIs?

All major, backwards incompatible changes and deprecations are announced on the low-volume persona-notices mailing list. Please subscribe to it.

To find out about new features and enhancements, follow the the Identity team blog.

For development discussion, subscribe to the dev-identity mailing list.

Revision Source

<h2 id="What's_the_difference_between_Mozilla_Persona_and_BrowserID.3F">What's the difference between Mozilla Persona and BrowserID?</h2>
<p>Persona is a complete implementation of a new, distributed login system from Mozilla.</p>
<p>BrowserID is the open protocol that governs how Persona works.</p>
<p>As an analogy: Persona allows users to log into sites by implementing BrowserID. Similarly, Firefox allows users to browse the web by implementing HTTP.</p>
<h2 id="How_does_Persona_compare_to_OpenID.3F">How does Persona compare to OpenID?</h2>
<p>Persona and OpenID have very similar goals and a similar architecture. Both systems reduce the number of passwords that a user needs, and both are designed to be decentralized. This means that any domain can present itself as an Identity Provider without relying on a central authority.</p>
<p>Despite these similarities, Persona is easier to use and easier to add to websites. Persona also does a better job of protecting user privacy. Specifically:</p>
<dl>
  <dt>
    Persona is easier for users</dt>
  <dd>
    Persona identifies users based on email addresses, which users already know, understand, and naturally associate with online identities. With OpenID, users are forced to learn a new username: an unintuitive URL.</dd>
  <dd>
    Logging in with Persona is also easier: it just takes 2 clicks after a one-time setup process.</dd>
  <dt>
    Persona is easier for developers</dt>
  <dd>
    Persona has a {{ domxref("navigator.id", "simple API") }} that only takes an afternoon to get started with.</dd>
  <dd>
    Persona identities <em>are</em> email addresses, so websites don't have to ask users for additional contact information during signup.</dd>
  <dd>
    Because users know and understand their email address, developers don't have to build complex pages with login buttons for all the popular OpenID providers.</dd>
  <dt>
    Persona better protects user privacy</dt>
  <dd>
    By design, OpenID allows Identity Providers to track their users around the web: whenever a user logs into a website, their browser gets redirected from that site to the user's Identity Provider, and then back to the site that the user requested. These redirects fully expose to the Identity Provider where the user is going.</dd>
  <dd>
    In contrast, the BrowserID protocol never leaks tracking information back to the Identity Provider. Rather, it behaves similarly to an ID card: users obtain signed credentials from their Identity Providers which can be presented to websites as a proof of identity. Websites can check the validity of these credentials without ever revealing a user's identity to their identity provider.</dd>
</dl>
<h2 id="Does_Persona_require_JavaScript.3F">Why does Persona require JavaScript?</h2>
<div class="ace-line" id="magicdomid363">
  <span>Persona requires JavaScript, but some users choose to selectively block JavaScript by</span><span class="author-g-z122z84mm1qy2f9ywopl"> </span><span>using browser add-ons like NoScript. Many of these users are concerned about the privacy implications of enabling JavaScript, since it is often used to track visitors </span><span class="author-p-2470">across</span><span> websites. However, in the case of Persona, JavaScript is actually used to enhance user privacy, as it allows the browser to perform cryptographic operations completely on the client side. By doing these operations on the client, Persona avoids the need to store secret keys anywhere other than in the user's own browser.</span></div>
<h2 id="Does_Persona_guarantee_that_I_get_a_working_email_address_for_my_users.3F">Does Persona guarantee that I get a working email address for my users?</h2>
<p>No, Persona only guarantees the user's association with an address. As with any email address in any login system, it's possible that the address no longer works or is not regularly checked by the user. For most users, the email address will be functional.</p>
<h2 id="How_does_Persona_verify_a_user's_association_with_an_address.3F">How does Persona verify a user's association with an address?</h2>
<p>Persona asks the address's domain, which is free to verify its users in any way it chooses. If a domain is not a native Identity Provider, and thus can't verify its own users, the browser asks for verification from Persona's fallback Identity Provider at <a href="https://login.persona.org" title="https://login.persona.org">https://login.persona.org</a>. Before certifying a user's identity, the fallback Identity Provider does test the address by sending an email to it and asking the user to click a link contained within.</p>
<h2 id="How_can_I_handle_account_recovery_if_users_lose_control_of_their_email_address.3F">How can I handle account recovery if users lose control of their email address?</h2>
<h2 id="Can_I_self-host_include.js.2C_or_must_I_include_it_from_https.3A.2F.2Flogin.persona.org.3F">Can I self-host include.js, or must I include it from <a class="link-https" href="https://login.persona.org" rel="freelink">https://login.persona.org</a>?</h2>
<p>The code in <code>include.js</code> is still subject to change. It's not yet recommended that you host it yourself.</p>
<h2 id="Can_I_verify_assertions_locally.2C_or_must_I_use_the_remote_verification_service.3F">Can I verify assertions locally, or must I use the remote verification service?</h2>
<p>To ensure user privacy, it's important that identity assertions are verified locally rather than with the remote verification service. However, the format of assertions is still subject to change, so local verification is not yet recommended. Even with remote verification, Persona protects the user from tracking by their identity provider.</p>
<p>Once the protocol has stabilized, libraries will be available to simplify local verification. Follow the <a class="external" href="http://identity.mozilla.com/" title="http://identity.mozilla.com/">Identity Blog</a> to find out when local verification is recommended.</p>
<h2 id="What_tips_are_there_for_migrating_users_who_are_currently_using_other_sign-in_methods.3F">What tips are there for migrating users who are currently using other sign-in methods?</h2>
<p>Despite Persona's benefits, it's never easy to move all of your users to a new login system. Conveniently, Persona's focus on email addresses makes it easy to use alongside existing login systems, so you don't have to switch all at once.</p>
<p>One particularly low-friction approach is to suggest Persona to users who forget their password. Instead of resetting passwords, users can simply log in with Persona.</p>
<h2 id="How_should_I_signal_that_.22Sign_In.22_also_handles_new_account_creation.3F">How should I signal that "Sign In" also handles new account creation?</h2>
<h2 id="How_do_I_find_out_about_major_changes_to_BrowserID.2C_such_as_new_or_deprecated_APIs.3F">How do I find out about major changes to BrowserID, such as new or deprecated APIs?</h2>
<p>All major, backwards incompatible changes and deprecations are announced on the low-volume <a href="https://mail.mozilla.org/listinfo/persona-notices" title="https://mail.mozilla.org/listinfo/persona-notices">persona-notices</a> mailing list. Please subscribe to it.</p>
<p>To find out about new features and enhancements, follow the the <a href="http://identity.mozilla.com/" title="http://identity.mozilla.com/">Identity team blog</a>.</p>
<p>For development discussion, subscribe to the <a class="link-https" href="https://lists.mozilla.org/listinfo/dev-identity" title="https://lists.mozilla.org/listinfo/dev-identity">dev-identity</a><span class="link-https"> mailing list</span>.</p>
Revert to this revision