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 authentication and provisioning values to obtain certification of their user's identity.

For more information, including how domains can delegate to other IdPs, see the /.well-known/browserid documentation.

How browsers interact with IdPs

To demonstrate how Browsers and IdPs interact, let's look at what needs to happen the first time alice@example.com tries to use Persona to log into a website.

1. Alice's browser fetches the support document from https://example.com/.well-known/browserid.
2. Alice's browser invisibly loads the provisioning page for example.com and asks it to sign a public key certifying Alice's identity.
3. Before signing the key, example.com needs proof that the user is Alice, so it tells the browser that she needs to authenticate.
4. Alice's browser shows Alice the authentication page for example.com, and she signs in, establishing a new session at example.com.
5. Alice's browser reloads the provisioning page and again asks it to sign a public key certifying Alice's identity.
6. The provisioning page 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 alice@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 alice@example.com, 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 example.com.

Security and trust

The BrowserID protocol, and thus Persona, are built on standard public key cryptography techniques.

Feel free to explore our documentation on the cryptographic concepts behind how a Persona IdP works or read more detail on how IdPs are implemented.