Para poder ser realmente exitoso y descentralizado, Persona necesita el apoyo de tres grupos diferentes:
- Sitios Web que deben permitir a sus usuarios registrarse con Persona.
- Navegadores Web que deben implementar las APIs
- Proveedores de Email que deben ser Proveedores de Identidad (IdPs —por su sigla en inglés).
Esto da lugar un problema del tipo "el huevo o la gallina": ninguno de estos grupos se beneficiaría significativamente a menos que haya una masa considerable de usuarios pero un sistema distribuido no puede conseguir una masa considerable de usuarios sin el apoyo de los grupos mencionados anteriormente.
To solve this problem, https://login.persona.org hosts three resources:
- A fallback Identity Provider, which vouches for users whose email providers don't support Persona.
navigator.idAPIs for browsers without native support.
- 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.