Persona is no longer actively developed by Mozilla. Mozilla has committed to operational and security support of the persona.org services until November 30th, 2016.
On November 30th, 2016, Mozilla will shut down the persona.org services. Persona.org and related domains will be taken offline.
If you run a website that relies on Persona, you need to implement an alternative login solution for your users before this date.
For more information, see this guide to migrating your site away from Persona:
A Persona Identity Provider (IdP) is a domain which directly signs and certifies the identities of its users. Because Persona identities are based on email addresses, any domain which offers email to its users is a natural fit for becoming an IdP.
If you have a domain name, you can become a Persona IdP by implementing support for the underlying BrowserID protocol.
The IdP support document
Domains advertise their ability to act as IdPs by publishing a support document at
/.well-known/browserid. This JSON-formatted document contains three values:
public-key: The public part of the domain's cryptographic key.
authentication: The domain's page for asking users to log in.
provisioning: The domain's page for certifying its users' identities.
Websites use the
public-key to verify the authenticity of users' identity assertions.
Browsers use the
provisioning values to obtain certification of their user's identity.
For more information, including how domains can delegate to other IdPs, see the
How browsers interact with IdPs
To demonstrate how Browsers and IdPs interact, let's look at what needs to happen the first time
firstname.lastname@example.org tries to use Persona to log into a website.
- Alice's browser fetches the support document from
- Alice's browser invisibly loads the
example.comand asks it to sign a public key certifying Alice's identity.
- Before signing the key,
example.comneeds proof that the user is Alice, so it tells the browser that she needs to authenticate.
- Alice's browser shows Alice the
example.com, and she signs in, establishing a new session at
- Alice's browser reloads the
provisioningpage and again asks it to sign a public key certifying Alice's identity.
provisioningpage can verify Alice's identity by inspecting the new session. Satisfied, it signs a certificate containing Alice's public key, her email address, and an expiration date for the certificate.
For the duration of the signed certificate, Alice's browser can create valid identity assertions for
email@example.com whenever she wants to log into a website with Persona.
Steps 3-5 can be skipped if Alice already has a valid session with
example.com, for example, from logging into her webmail or an intranet portal.
How websites interact with IdPs
Let's say Alice wants to sign in to 123done.org. Her browser would generate and sign an identity assertion containing the certificate from above and present it as proof of her identity.
By comparing Alice's signature on the identity assertion with the public key inside the signed certificate, 123done can be confident that the certificate was issued to the same person that generated the identity assertion. However, 123done still needs to check that the certificate itself is valid by examining its signature.
Because the certificate was issued for
firstname.lastname@example.org, 123done fetches the support document from
https://example.com/.well-known/browserid. It then extracts the
public-key and compares that to the signature on Alice's certificate. If the key matches the signature, 123done knows that the certificate is legitimate and can finish logging Alice in.
Note that 123done never "phoned home" or otherwise revealed Alice's identity when she logged in. Rather, it only needed to request a single, cacheable document from
Security and trust
The BrowserID protocol, and thus Persona, are built on standard public key cryptography techniques.