Persona Hosted Services

  • 리비전 슬러그: Persona/Bootstrapping_Persona
  • 리비전 제목: Persona Hosted Services
  • 리비전 아이디: 486073
  • 제작일시:
  • 만든이: ohkyouson
  • 현재 리비전인가요?
  • 댓글

리비전 내용

To be truly successful and decentralized, Persona needs support from three different groups:

  • Web Sites must let their users sign in with Persona.
  • Web Browsers must implement the navigator.id APIs.
  • Email Providers must become Identity Providers (IdPs).

This creates a chicken-and-egg problem: none of these groups would significantly benefit unless there was a critical mass of users, but a distributed system can't get a critical mass of users without support from the above groups.

To solve this problem, https://login.persona.org hosts three resources:

  1. A fallback Identity Provider, which vouches for users whose email providers don't support Persona.
  2. A cross-browser, JavaScript implementation of the navigator.id APIs for browsers without native support.
  3. A hosted verification API to make it easy for sites to verify user credentials.

Together, this allows web sites to offer Persona to users regardless of browser and without email providers needing to get involved.

These services are temporary, and the Persona system is designed such that they transparently and automatically drop away as native support gets added to browsers and email providers. Thus, they will become less relevant as Persona matures, and may eventually be removed all together. At that point, https://login.persona.org won't feature at all in the Persona system.

Fallback Identity Provider

Any domain can become an Identity Provider as long as relying parties are willing to trust the certificates issued by that domain. We expect email providers to act as an IdPs for the addresses they administer, making the user experience of Persona seamless for those users.  It allows the user to leverage their existing relationship with the email provider when authenticating at other sites.

However, email providers won't become IdPs until there is significant demand from their users. In the meantime, Mozilla operates a fallback IdP at https://login.persona.org. This fallback allows users to sign into sites with their existing email address, regardless of whether or not the email provider supports Persona. The fallback IdP will certify email addresses from any domain using its own authentication flow and its own password, so long as the user is able to prove control of an address by clicking a link in a verification email.

Once an email provider supports Persona natively, its users will transparently begin use it instead of the fallback IdP.

Cross-browser API Library

For Persona to work, the user's browser must support the navigator.id API. Eventually, browsers will add native support for these APIs, but until then a cross-browser implementation is available at https://login.persona.org/include.js. By including this file, web sites can already begin using Persona. Once native implementations of the API are available, the library will automatically defer to those.

Remote verification service

At https://login.persona.org Mozilla hosts a remote verification service that web sites can use to verify identity assertions sent from users. This makes it simpler for web sites to support Persona as it takes care of parsing the assertion and cryptographically verifying user identities.

Once the Persona data formats stabilize, verification will most likely be done locally on each site's server. This transition is especially important for user privacy, since it will make it impossible for the fallback IdP to track its users. Even with remote verification, users of native IdPs can't be tracked by that IdP.

리비전 소스

<p>To be truly successful and decentralized, Persona needs support from three different groups:</p>
<ul>
  <li><strong>Web Sites</strong> must let their users sign in with Persona.</li>
  <li><strong>Web Browsers</strong> must implement the <a href="/en/DOM/navigator.id" title="navigator.id"><code>navigator.id</code></a> APIs.</li>
  <li><strong>Email Providers</strong> must become Identity Providers (IdPs).</li>
</ul>
<p>This creates a chicken-and-egg problem: none of these groups would significantly benefit unless there was a critical mass of users, but a distributed system can't get a critical mass of users without support from the above groups.</p>
<p>To solve this problem, <a class="link-https" href="https://login.persona.org" rel="freelink">https://login.persona.org</a> hosts three resources:</p>
<ol>
  <li>A fallback Identity Provider, which vouches for users whose email providers don't support Persona.</li>
  <li>A <a href="/en-US/docs/persona/Browser_compatibility" title="/en-US/docs/persona/Browser_compatibility">cross-browser</a>, JavaScript implementation of the <code><a href="/en/DOM/navigator.id" title="navigator.id">navigator.id</a></code> APIs for browsers without native support.</li>
  <li>A hosted verification API to make it easy for sites to verify user credentials.</li>
</ol>
<p>Together, this allows web sites to offer Persona to users regardless of browser and without email providers needing to get involved.</p>
<p>These services are temporary, and the Persona system is designed such that they transparently and automatically drop away as native support gets added to browsers and email providers. Thus, they will become less relevant as Persona matures, and may eventually be removed all together. 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>Any domain can become an Identity Provider as long as relying parties are willing to trust the certificates issued by that domain. We expect email providers to act as an IdPs for the addresses they administer, making the user experience of Persona seamless for those users.  It allows the user to leverage their existing relationship with the email provider when authenticating at other sites.</p>
<p>However, email providers won't become IdPs until there is significant demand from their users. In the meantime, Mozilla operates a fallback IdP at <a href="https://login.persona.org" rel="freelink">https://login.persona.org</a>. This fallback allows users to sign into sites with their existing email address, regardless of whether or not the email provider supports Persona. The fallback IdP will certify email addresses from any domain using its own authentication flow and its own password, so long as the user is able to prove control of an address by clicking a link in a verification email.</p>
<p>Once an email provider supports Persona natively, its users will transparently begin use it instead of the fallback IdP.</p>
<h2 id="Cross-browser_API_Library">Cross-browser API Library</h2>
<p>For Persona to work, the user's browser must support the <a href="/en/DOM/navigator.id" title="navigator.id">navigator.id</a> API. Eventually, browsers will add native support for these APIs, but until then a <a href="/en-US/docs/persona/Browser_compatibility" title="/en-US/docs/persona/Browser_compatibility">cross-browser </a>implementation is available at <a href="https://login.persona.org/include.js" title="https://login.persona.org/include.js">https://login.persona.org/include.js</a>. By including this file, web sites can already begin using Persona. Once native implementations of the API are available, the library will automatically defer to those.</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> Mozilla hosts 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 identity assertions sent from users. This makes it simpler for web sites to support Persona as it takes care of parsing the assertion and cryptographically verifying user identities.</p>
<p>Once the Persona data formats stabilize, verification will most likely be done locally on each site's server. This transition is especially important for user privacy, since it will make it impossible for the fallback IdP to track its users. Even with remote verification, users of native IdPs can't be tracked by that IdP.</p>
Revert to this revision