mozilla

Revision 297454 of Persona Hosted Services

  • Revision slug: Persona/Bootstrapping_Persona
  • Revision title: Bootstrapping Persona
  • Revision id: 297454
  • Created:
  • Creator: wbamberg
  • Is current revision? No
  • Comment
Tags: 

Revision Content

To be successful as a decentralized, easy-to-use authentication system, Persona needs help from three different groups.

  • Web sites (Relying Parties): need to let their users sign in with Persona
  • Web browsers: need to implement the BrowserID navigator.id APIs
  • Email providers: need to act as identity providers

But there's a chicken-and-egg problem here: none of these groups will support Persona unless it has a critical mass of users, but it can't get a critical mass of users without support from them all.

To solve this we've set up https://login.persona.org, which hosts three services:

  1. a fallback identity provider
  2. a portable implementation of the navigator.id APIs
  3. a remote verification service

Together, these services enable web sites to offer Persona without web browsers needing to change or email providers needing to get involved.

All three of these services are temporary, and will become less relevant as Persona implementations mature. Eventually we will be able to remove them entirely, and at that point https://login.persona.org won't feature at all in the Persona system.

Fallback identity provider

In Persona anyone can act as an identity provider, as long as relying parties are willing to trust their certificates. Usually, though, we expect the user's email provider to act as an identity provider for the emails it administers. This makes the user experience of Persona much better, because it means that users don't need a separate password, to go through a separate sign-up step, or to bring a new party into the picture. Instead, the user can leverage their existing relationship with the email provider.

In the past we've called these types of providers primary identity providers, although we've now deprecated that terminology.

But until enough web sites support Persona, email providers won't offer identity provisioning. So we've set up our own identity provider at https://login.persona.org to bridge that gap, and enable web sites to sign users in using their existing email address, whether or not the email provider supports Persona. This provider will certify email addresses from any domain, using its own authentication flow and its own password. This is what we used to call a secondary identity provider, but we now call it a fallback identity provider.

Once an email provider supports Persona, its users won't need to use our provider any more any more.

Implementation of navigator.id in include.js

For BrowserID to work, the user's browser has to support the navigator.id APIs. Eventually we expect browsers to add native support for these APIs, but until then we've provided an implementation of them in include.js. Just by including this file, web sites can use the BrowserID APIs in all modern browsers.

Remote verification service

At https://login.persona.org we host a remote verification service that web sites can use to verify assertions sent from users. This makes it simpler for web sites to integrate BrowserID, as it takes care of parsing the assertion and verifying signatures and certificates.

Eventually we expect verification to be done locally, on the web site's server. This is an important step, as it will make it impossible for identity providers to track users.

Revision Source

<p>To be successful as a decentralized, easy-to-use authentication system, Persona needs help from three different groups.</p>
<ul>
  <li><strong>Web sites (Relying Parties)</strong>: need to let their users sign in with Persona</li>
  <li><strong>Web browsers</strong>: need to implement the BrowserID <a href="/en/DOM/navigator.id" title="navigator.id"><code>navigator.id</code></a> APIs</li>
  <li><strong>Email providers</strong>: need to act as identity providers</li>
</ul>
<p>But there's a chicken-and-egg problem here: none of these groups will support Persona unless it has a critical mass of users, but it can't get a critical mass of users without support from them all.</p>
<p>To solve this we've set up <a class="link-https" href="https://login.persona.org" rel="freelink">https://login.persona.org</a>, which hosts three services:</p>
<ol>
  <li>a fallback identity provider</li>
  <li>a portable implementation of the <code><a href="/en/DOM/navigator.id" title="navigator.id">navigator.id</a></code> APIs</li>
  <li>a remote verification service</li>
</ol>
<p>Together, these services enable web sites to offer Persona without web browsers needing to change or email providers needing to get involved.</p>
<p>All three of these services are temporary, and will become less relevant as Persona implementations mature. Eventually we will be able to remove them entirely, and at that point <a href="https://login.persona.org" rel="freelink">https://login.persona.org</a> won't feature at all in the Persona system.</p>
<h2 id="Fallback_identity_provider">Fallback identity provider</h2>
<p>In Persona anyone can act as an identity provider, as long as relying parties are willing to trust their certificates. Usually, though, we expect the user's email provider to act as an identity provider for the emails it administers. This makes the user experience of Persona much better, because it means that users don't need a separate password, to go through a separate sign-up step, or to bring a new party into the picture. Instead, the user can leverage their existing relationship with the email provider.</p>
<p>In the past we've called these types of providers primary identity providers, although we've now deprecated that terminology.</p>
<p>But until enough web sites support Persona, email providers won't offer identity provisioning. So we've set up our own identity provider at <a href="https://login.persona.org" rel="freelink">https://login.persona.org</a> to bridge that gap, and enable web sites to sign users in using their existing email address, whether or not the email provider supports Persona. This provider will certify email addresses from any domain, using its own authentication flow and its own password. This is what we used to call a secondary identity provider, but we now call it a fallback identity provider.</p>
<p>Once an email provider supports Persona, its users won't need to use our provider any more any more.</p>
<h2 id="Implementation_of_navigator.id_in_include.js">Implementation of navigator.id in include.js</h2>
<p>For BrowserID to work, the user's browser has to support the <a href="/en/DOM/navigator.id" title="navigator.id">navigator.id</a> APIs. Eventually we expect browsers to add native support for these APIs, but until then we've provided an implementation of them in <a href="https://login.persona.org/include.js">include.js</a>. Just by including this file, web sites can use the BrowserID APIs in <a href="/en/Persona/Browser_compatibility" title="en/BrowserID/FAQ#Which_browsers_are_supported.3F">all modern browsers</a>.</p>
<h2 id="Remote_verification_service">Remote verification service</h2>
<p>At <a href="https://login.persona.org" rel="freelink">https://login.persona.org</a> we host a <a href="/en/Persona/Remote_Verification_API" title="en/BrowserID/Remote_Verification_API">remote verification service</a> that web sites can use to verify assertions sent from users. This makes it simpler for web sites to integrate BrowserID, as it takes care of parsing the assertion and verifying signatures and certificates.</p>
<p>Eventually we expect verification to be done locally, on the web site's server. This is an important step, as it will make it impossible for identity providers to track users.</p>
Revert to this revision