Persona Hosted Services

Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.

Pour réussir et être vraiment décentralisé, Persona a besoin du soutien de trois groupes différent :

  • Les Sites Web doivent permettre à leurs utilisateurs de se connecter avec Persona.
  • Les Navigateurs Web doivent implémanter l'API navigator.id.
  • Les Fournisseurs d'Email doivent devenir des Fournisseur d'identité (IdPs).

Cela crée un cercle vicieux : aucun de ces groupes n'auraient un intêret significatif tant qu'il n'y avait un grand nombre d'utilisateur, mais un système distribué ne peut pas avoir un grand nombre d'utilisateur sans le soutien des groupes ci-dessus.

Pour résoudre ce problème, https://login.persona.org enregistre trois resources :

  1. Un Fournisseur d'Identité de secours, qui es disponible pour les utilisateurs dont les fournisseurs d'email ne supporte pas Persona.
  2. A cross-browser, JavaScript implementation of the navigator.id APIs for browsers without native support.
  3. 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.

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : HushGon
 Dernière mise à jour par : HushGon,