On November 30th, 2016, Mozilla shut down the persona.org services. Persona.org and related domains will soon be taken offline.
For more information, see this guide to migrating your site away from Persona:
The Persona identity system uses public key cryptography to ensure trust and security in authentication.
Why does the system described in the Persona IdP overview work?
Chain of Trust
The user's browser locally stores a few pieces of information for each of the user's identities: an email address, a keypair, and a certificate from the associated Identity Provider.
The user's keypair is a standard DSA or RSA cryptographic keypair, and it's generated and stored locally in the user's browser. The certificate is signed by the IdP associated with the user's chosen identity. These certificates are designed to last no more than 24 hours, and may be silently re-provisioned whenever they expire, so long as the user has an active session with the IdP. User keypairs are neither shared across computers nor across browsers.
As described in the Protocol Overview, the user's browser is able to generate and sign ephemeral site-specific identity assertions. When taken together with the information in a user certificate, a site is able to verify the identity of a user. The authenticity of certificates must be verified by retrieving the IdP's( identity provider's) public key, which is published in a document available over SSL.
Thus, Persona's security relies on the user's private key remaining secret, the domain's private key remaining secret, and the SSL connection to the IdP being secure. A break at any one of these points could undermine the security of a user's identity.
Generating IdP Keypairs
For IdPs (Identity Providers ), the jwcrypto package provides a command line utility,
generate-keypair, which generates keys suitable for use with Persona. Because the generated keys are already JSON-serialized, the public key is suitable for direct inclusion into the public-key field of an IdP's /.well-known/browserid.
Certificate and Assertion Format
Please refer to the BrowserID spec for detailed information, but at a high level, both certificates and assertions are strings with three parts: a header, a body, and a cryptographic signature. Each part is separately base64url encoded and concatenated, with "
." characters delimiting each part. The body is not encrypted, so its plaintext is available if you base64url decode it.
Certificates and assertions are bundled together into a "backed assertion" when a user attempts to authenticate with a site. The bundle is created by concatenating a certificate and an assertion with a "
~" separating them.