mozilla

Compare Revisions

Persona Hosted Services

Change Revisions

Revision 297454:

Revision 297454 by wbamberg on

Revision 298931:

Revision 298931 by Callahad on

Title:
Bootstrapping Persona
Bootstrapping Persona
Slug:
Persona/Bootstrapping_Persona
Persona/Bootstrapping_Persona
Content:

Revision 297454
Revision 298931
n8      To be successful as a decentralized, easy-to-use authentican8      To be truly successful and decentralized, Persona needs sup
>tion system, Persona needs help from three different groups.>port from three different groups:
n12        <strong>Web sites (Relying Parties)</strong>: need to letn12        <strong>Web Sites</strong> must let their users sign in w
> their users sign in with Persona>ith Persona.
n15        <strong>Web browsers</strong>: need to implement the Brown15        <strong>Web Browsers</strong> must implement the <a href=
>serID <a href="/en/DOM/navigator.id" title="navigator.id"><code>n>"/en/DOM/navigator.id" title="navigator.id"><code>navigator.id</c
>avigator.id</code></a> APIs>ode></a> APIs.
n18        <strong>Email providers</strong>: need to act as identityn18        <strong>Email Providers</strong> must become Identity Pro
> providers>viders (IdPs).
n22      But there's a chicken-and-egg problem here: none of these gn22      This creates a chicken-and-egg problem: none of these group
>roups will support Persona unless it has a critical mass of users>s would significantly benefit unless there was a critical mass of
>, but it can't get a critical mass of users without support from > users, but a distributed system can't get a critical mass of use
>them all.>rs without support from the above groups.
n25      To solve this we've set up <a class="link-https" href="httpn25      To solve this problem, <a class="link-https" href="https://
>s://login.persona.org" rel="freelink">https://login.persona.org</>login.persona.org" rel="freelink">https://login.persona.org</a> h
>a>, which hosts three services:>osts three resources:
n28      <li>a fallback identity providern28      <li>A fallback Identity Provider, which vouches for users w
 >hose email providers don't support Persona.
n30      <li>a portable implementation of the <code><a href="/en/DOMn30      <li>A <a href="/en-US/docs/persona/Browser_compatibility" t
>/navigator.id" title="navigator.id">navigator.id</a></code> APIs>itle="/en-US/docs/persona/Browser_compatibility">cross-browser</a
 >>, JavaScript implementation of the <code><a href="/en/DOM/naviga
 >tor.id" title="navigator.id">navigator.id</a></code> APIs for bro
 >wsers without native support.
n32      <li>a remote verification servicen32      <li>A hosted verification API to make it easy for sites to 
 >verify user credentials.
n36      Together, these services enable web sites to offer Persona n36      Together, this allows web sites to offer Persona to users r
>without web browsers needing to change or email providers needing>egardless of browser and without email providers needing to get i
> to get involved.>nvolved.
n39      All three of these services are temporary, and will become n39      These services are temporary, and the Persona system is des
>less relevant as Persona implementations mature. Eventually we wi>igned such that they transparently and automatically drop away as
>ll be able to remove them entirely, and at that point <a href="ht> native support gets added to browsers and email providers. Thus,
>tps://login.persona.org" rel="freelink">https://login.persona.org> they will become less relevant as Persona matures, and may event
></a> won't feature at all in the Persona system.>ually be removed all together. At that point, <a href="https://lo
 >gin.persona.org" rel="freelink">https://login.persona.org</a> won
 >'t feature at all in the Persona system.
n42      Fallback identity providern42      Fallback Identity Provider
n45      In Persona anyone can act as an identity provider, as long n45      Any domain can become an Identity Provider as long as relyi
>as relying parties are willing to trust their certificates. Usual>ng parties are willing to trust the certificates issued by that d
>ly, though, we expect the user's email provider to act as an iden>omain. We expect email providers to act as an IdPs for the addres
>tity provider for the emails it administers. This makes the user >ses they administer, making the user experience of Persona seamle
>experience of Persona much better, because it means that users do>ss for those users.&nbsp; It allows the user to leverage their ex
>n't need a separate password, to go through a separate sign-up st>isting relationship with the email provider when authenticating a
>ep, or to bring a new party into the picture. Instead, the user c>t other sites.
>an leverage their existing relationship with the email provider. 
n48      In the past we've called these types of providers primary in48      However, email providers won't become IdPs until there is s
>dentity providers, although we've now deprecated that terminology>ignificant demand from their users. In the meantime, Mozilla oper
>.>ates a fallback IdP at <a href="https://login.persona.org" rel="f
 >reelink">https://login.persona.org</a>. This fallback allows user
 >s to sign into sites with their existing email address, regardles
 >s of whether or not the email provider supports Persona. The fall
 >back IdP will certify email addresses from any domain using its o
 >wn 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 ve
 >rification email.
n51      But until enough web sites support Persona, email providersn51      Once an email provider supports Persona natively, its users
> won't offer identity provisioning. So we've set up our own ident> will transparently begin use it instead of the fallback IdP.
>ity provider at <a href="https://login.persona.org" rel="freelink 
>">https://login.persona.org</a> to bridge that gap, and enable we 
>b sites to sign users in using their existing email address, whet 
>her or not the email provider supports Persona. This provider wil 
>l certify email addresses from any domain, using its own authenti 
>cation flow and its own password. This is what we used to call a  
>secondary identity provider, but we now call it a fallback identi 
>ty provider. 
52    </p>
53    <p>
54      Once an email provider supports Persona, its users won't ne
>ed to use our provider any more any more. 
n57      Implementation of navigator.id in include.jsn54      Cross-browser API Library
n60      For BrowserID to work, the user's browser has to support thn57      For Persona to work, the user's browser must support the <a
>e <a href="/en/DOM/navigator.id" title="navigator.id">navigator.i> href="/en/DOM/navigator.id" title="navigator.id">navigator.id</a
>d</a> APIs. Eventually we expect browsers to add native support f>> API. Eventually, browsers will add native support for these API
>or these APIs, but until then we've provided an implementation of>s, but until then a <a href="/en-US/docs/persona/Browser_compatib
> them in <a href="https://login.persona.org/include.js">include.j>ility" title="/en-US/docs/persona/Browser_compatibility">cross-br
>s</a>. Just by including this file, web sites can use the Browser>owser</a> implementation is available at <a href="https://login.p
>ID APIs in <a href="/en/Persona/Browser_compatibility" title="en/>ersona.org/include.js" title="https://login.persona.org/include.j
>BrowserID/FAQ#Which_browsers_are_supported.3F">all modern browser>s">https://login.persona.org/include.js</a>. By including this fi
>s</a>.>le, web sites can already begin using Persona. Once native implem
 >entations of the API are available, the library will automaticall
 >y defer to those.
n66      At <a href="https://login.persona.org" rel="freelink">httpsn63      At <a href="https://login.persona.org" rel="freelink">https
>://login.persona.org</a> we host a <a href="/en/Persona/Remote_Ve>://login.persona.org</a> Mozilla hosts a <a href="/en/Persona/Rem
>rification_API" title="en/BrowserID/Remote_Verification_API">remo>ote_Verification_API" title="en/BrowserID/Remote_Verification_API
>te verification service</a> that web sites can use to verify asse>">remote verification service</a> that web sites can use to verif
>rtions sent from users. This makes it simpler for web sites to in>identity assertions sent from users. This makes it simpler for 
>tegrate BrowserID, as it takes care of parsing the assertion and >web sites to support Persona as it takes care of parsing the asse
>verifying signatures and certificates.>rtion and cryptographically verifying user identities.
t69      Eventually we expect verification to be done locally, on tht66      Once the Persona data formats stabilize, verification will 
>e web site's server. This is an important step, as it will make i>most likely be done locally on each site's server. This transitio
>t impossible for identity providers to track users.>n is especially important for user privacy, since it will make it
 > impossible for the fallback IdP to track its users. Even with re
 >mote verification, users of native IdPs can't be tracked by that 
 >IdP.

Back to History