Le projet "verified email" se compose d'un protocole, en cours de définition, de services hébergés par Mozilla pour fournir les outils utilisés par le protocole en attendant qu'ils se diffusent plus largement, et bien sûr d'implémentations du protocole dans des clients, notamment Firefox.

mise à jour du 15 juillet : le projet s'appelle à présent BrowserID, a un site web et la liste de discussion a été réparée.

Nos adresses de courriel sont les clés de nos identités numériques

Plutôt que d'inventerdemander aux internautes de se créer[1] un nouvel identifiant, comme c'est souvent le cas avec OpenID, l'idée est d'utiliser l'identifiant le plus courant et le mieux compris: l'adresse de messagerie électronique, le mail. La majorité des internautes est consciente que l'adresse "alice@site.com" représente une personne (ou un groupe) connue du site site.com, qu'elle identifie une personne physique. Les adresses mail ont de plus quelques caractéristiques intéressantes: c'est un système distribué, n'importe qui peut créer son propre serveur et gérer son adresse, une personne peut avoir autant d'adresses qu'elle veut, on peut aisément créer des pseudonymes, etc. Toutes ces caractéristiques permettent de répondre à la plupart des cas d'utilisation d'un identifiant qui offre aux internautes liberté et fiabilité.

Beaucoup de sites utilisent déjà l'adresse mail pour identifier leurs utilisateurs. A partir du moment où ils fournissent une fonction pour récupérer l'accès à son compte via l'envoi d'un courrier, ils disent implicitement "ce compte utilisateur appartient à la personne qui contrôle cette adresse mail". L'adresse mail est donc déjà largement utilisée comme réceptacle de l'identité en ligne. L'idée de Verified email est de pousser plus loin cette assertion, de garantir qu'une adresse mail suffit à identifier une personne.

Verified email, comment ça marche ???

Le principe est le suivant:

  • l'utilisateur enregistre dans son navigateur ses adresses mails;
  • le navigateur vérifie auprès des serveur de messagerie que ces adresses sont bien contrôlées par l'utilisateur;
  • lorsque l'utilisateur se connecte à un site en utilisant une de ces adresses, le navigateur fournit au site les moyens de vérifier son identité;

Le navigateur a un rôle central dans ce processus. Et ça tombe bien, puisque c'est l'élément sur lequel l'utilisateur a le plus de contrôle. Ses identités et les moyens de les contrôler ne sont pas stockées en ligne, mais en grande partie dans son navigateur.

Sous le capot

Le protocole utilise de la cryptographie asymétrique, comme le fait par exemple PGP. Très schématiquement, celle-ci repose sur l'utilisation d'une clé en deux parties, chaque partie permettant de défaire ce que l'autre a fait. Le propriétaire de la clé conserve une de ces parties, la clé secrète et diffuse largement l'autre, la clé publique. Cela permet de chiffrer des communications, mais également de les signer, de garantir leur origine et leur intégrité. Par exemple, pour signer un message, le logiciel calcule une somme de contrôle du message et la chiffre avec ma clé privée. Les destinataires déchiffrent la signature avec ma clé publique et vérifient que la somme de contrôle est exacte. Si oui, cela signifiera que la signature a bien été effectuée avec ma clé privée (et que le message n'a pas été altéré). S'ils ont pu par un autre biais vérifier le lien entre ma clé publique et moi, ils ont la certitude que le suis bien l'auteur du message.

Verified email utilise les mêmes technologies. Lorsque je déclare au navigateur une de mes adresses mails, celui-ci crée une paire de clés et envoie la clé publique au serveur de mail. Si celui-ci m'a identifié (par exemple parce que je suis actuellement connecté au webmail), il associe cette clé publique à mon compte.

Lorsque je me connecte à un site tiers compatible, mon navigateur lui envoie un message contenant diverses informations dont l'adresse mail avec laquelle je veux d'identifier. Ce message est signé avec ma clé privée. Le site récupère alors la clé publique auprès du serveur de mail et vérifie la signature. Si elle est correcte, il a ainsi la preuve que je suis bien la personne connue du serveur de mail sous cette identité.

Plus en détail

Le brouillon de spécification propose un exemple d'implémentation: pour enregistrer une adresse dans mon navigateur, il me faut d'abord me connecter au site Web de mon prestataire de messagerie, puis aller sur une page contenant un script qui indique au navigateur l'adresse à enregistrer et la méthode pour publier la clé publique. Par exemple un appel de ce type:

   navigator.id.saveVerifiedAddress( "bob@clochix.net", <callback>);

Le navigateur va créer une paire de clés pour l'adresse "bob@clochix.net" et envoyer la clé publique au serveur via la fonction de callback. Le serveur associe la clé publique à l'adresse mail. Il peut enregistrer plusieurs clés publiques pour chaque adresse, me permettant de déclarer mon adresse dans autant de périphériques que je le souhaite.

Si un site est compatible avec le protocole, sa page de connexion contient un script qui l'indique au navigateur et décrit la méthode pour envoyer une demande. Le butineur affiche alors un bouton de connexion directement dans son interface (probablement une fenêtre comme celle proposant actuellement d'enregistrer un mot de passe). Je peux sélectionner parmi les adresses enregistrées dans le brouteur celle avec laquelle je veux me connecter. Le navigateur crée un message contenant cette adresse, des informations complémentaires que j'y ai associées et une date d'expiration, signe le message avec la clé privée de l'adresse, et envoie le tout au serveur. Le serveur extrait l'adresse du message, découvre le serveur qui fait autorité pour cette adresse, récupère la clé publique de l'adresse et vérifie la signature. Le protocole ne précise pas comment découvrir le serveur qui fait autorité, mais suggère d'utiliser par exemple WebFinger.

Dans ce scénario, plus besoin de mot de passe pour me connecter au site: mon adresse mail suffit à prouver qui je suis.

Le navigateur peut proposer d'autres fonctions pour simplifier la gestion des connexions, comme par exemple mémoriser l'adresse utilisée pour se connecter à chaque site. Il pourrait également permettre à l'utilisateur de se connecter à un site avec plusieurs adresses différentes. Il devrait alors fournir une interface pour terminer la session sur le serveur et ouvrir une nouvelle session avec une nouvelle identité.

Déployer

La mise en œuvre de ce protocole risque de ne pas être simple, car elle implique de nombreux acteurs: les gestionnaires des serveurs de messagerie, et ceux des services en ligne. Les premiers doivent permettre d'associer des clés publiques à chaque adresse qu'ils gèrent, les second mettre en place les mécanismes parfois un peu complexe de découverte du serveur faisant autorité et de vérification de la signature. Pour que ces difficultés ne soient pas rédhibitoires, Mozilla propose des solutions alternatives, avec des "autorités secondaires" et des prestataires de vérification.

Imaginons qu'une de mes identités soit liée à une compte mail hébergé chez Gandi, qui n'a pas encore implémenté le protocole. Je décide d'utiliser comme tiers de confiance un site fourni par Mozilla. J'indique à Mozilla l'adresse que je veux valider, Mozilla m'envoie un mail contenant un lien vers son site. Si je clique sur le lien, cela prouve que j'ai accès à l'adresse, donc qu'elle m'identifie. Mozilla déclenche la procédure de création de clé avec mon navigateur, et stocke la clé publique de l'adresse. Le navigateur sait que la clé publique est hébergée par un tiers de confiance, l'autorité secondaire. Lorsque je veux utiliser cette adresse pour me connecter à un site, mon navigateur indique dans le message signé le tiers à contacter pour obtenir la clé publique. Au site de décider s'il accepte également de faire confiance à ce tiers. (attention, si le site fait confiance à n'importe quel tiers, tout le mécanisme s'effondre).

Mozilla envisage de fournir une telle autorité secondaire, en complément à son service de synchronisation de profils (Sync). Les utilisateurs pourraient enregistrer toutes leurs adresses auprès de ce service, et on peut espérer que du fait de la réputation de Mozilla, il soit reconnu comme autorité secondaire par de nombreux sites. Le protocole pourrait ainsi être rapidement déployé, même si les prestataires de messagerie de l'implémentent pas. Le service pourrait également offrir une API pour vérifier une adresse, simplifiant ainsi l'implémentation par les sites: ceux-ci n'auraient qu'à envoyer le message signé du navigateur au service qui se chargerait de vérifier la signature. L'implémentation de l'authentification par adresse vérifiée serait ainsi des plus simples: un peu de JavaScript pour récupérer l'adresse, et un appel à un service web pour la vérifier.

Un autre point risquant de ralentir le déploiement de cette solution est sa disponibilité dans les clients. Même si, rêvons, tous les fondeurs de navigateurs décidaient d'implémenter le protocole, des années s'écouleraient sans doute avant qu'une majorité d'internautes dispose d'un navigateur compatible. Mozilla propose donc un autre contournement, sous la forme d'une version HTML du client. C'est dans ce cas le site de l'autorité secondaire qui gère les adresses mail de l'utilisateur à la place du navigateur, et certifie son identité auprès des sites tiers. Le tout utilise toute la bonne vieille artillerie de la communication entre site en vieil HTML, iframes et compagnie, comme le service de connexion multi-sites d'un silo bien connu. Une démonstration est déjà disponible qui permet de se connecter à un site fictionnel via une autorité secondaire. Les sources de la démo sont sur Github et utilisent Node.js, ce qui me donne bien envie d'aller y regarder de plus près.

Travail en cours

La proposition de spécification n'est pas encore mature, et bien des questions restent ouvertes. Par exemple, un inconvénient du système est que les prestataires de messagerie sont contactés à chaque fois que je veux me connecter à un site, donc connaissent les sites auxquels je me connecte. Le protocole propose un mécanisme alternatif pour remédier à ce soucis: lorsque le navigateur lui envoie la clé publique associée à l'adresse, le prestataire de messagerie signe cette clé avec la clé privée du serveur et ré-expédie le tout au navigateur, qui stocke donc également la clé publique associée à l'adresse, signée par la clé privée du serveur. Lors de la connexion à un site tiers, il envoie directement la clé publique signée. Le site tiers récupère alors la clé publique du serveur de messagerie et l'utilise pour vérifier la signature. Si la signature est correcte, cela suffit à prouver que le serveur de messagerie a bien validé l'association entre l'adresse et cette clé publique.

Une autre faille du système est que les administrateurs d'un serveur ont généralement accès à tous les messages, et pourraient donc usurper l'identité de n'importe lequel de leurs utilisateurs. Rien n'est pour l'instant prévu sur ce point, qui est d'ailleurs commun à la plupart des services d'identification en ligne.

Il reste donc pas mal de travail pour finaliser la spécification, et je pense que tous les avis seront les bienvenus. J'ai essayé de résumer le protocole, mais le brouillon de spécification entre bien évidemment beaucoup plus dans les détails, je vous encourage vivement à aller le lire.

En conclusion

Verified Email essaie de bâtir en tirant les leçons du relatif échec de précédentes tentatives similaires, comme OpenID. Son maître mot est la simplicité: simplicité et transparence du processus pour l'utilisateur, simplicité de l'implémentation pour les éditeurs de sites, via les autorités secondaires et les services de vérification.

Outre l'utilisation d'un identifiant bien connu comme l'adresse mail, un des avantages de cette solution est de mettre le navigateur au centre du dispositif. Le navigateur est quelque chose que l'utilisateur peut contrôler (enfin s'il utilise un logiciel libre et auquel il fait confiance), donc si le protocole est largement adopté, c'est l'internaute qui en bénéficiera en ayant un meilleur contrôle sur ses identités numériques. Par ailleurs, le navigateur pourra offrir de nombreuses fonctionnalités complémentaires d'aide à la gestion des identités. Il pourrait par exemple afficher des informations sur la politique de confidentialité des sites (obtenues via P3P), créer automatiquement des adresses temporaires… Je fais confiance à la créativité des développeurs d'extensions pour inventer ces fonctions.

Pour résumer, Verified email, c'est donc:

  • un mécanisme permettant de s'identifier auprès de sites tiers avec son adresse mail, sans avoir besoin de mot de passe;
  • ce mécanisme sera directement intégré dans les navigateurs;
  • l'ensemble permet de gérer ses identités de manière décentralisés;
  • pas besoin d'attendre une implémentation dans tous les navigateurs et par tous les serveurs de mail, le protocole est utilisable dès aujourd'hui (bon, demain) via un client en HTML et des autorités secondaires;

Le projet lui-même comporte six étapes, vous pouvez vous référer au wiki pour suivre leur évolution :

  • la spécification du protocole (je ne sais pas s'il a été prévu de le soumettre à une autorité de normalisation type W3C ou IETF);
  • l'implémentation de trois versions du client: dans les versions fixes et mobile de Firefox, et sous forme d'application Web;
  • la mise en place d'un serveur d'autorité secondaire;
  • le développement d'une interface Web pour ce serveur;

Sources de ce billet

Appendice: un peu d'histoire

Mozilla s'intéresse depuis longtemps à la question de l'identité numérique. Les Labs avaient lancé au printemps 2010 une réflexion sur la gestion de ses identités en ligne. Deux extensions prospectives avaient vu le jour dans le cadre de ce programme:

Les deux étaient des expériences destinées à explorer des pistes, et ont été assez rapidement abandonnées.

C'est une des caractéristiques de Labs, lancer des projets enthousiasmants et les abandonner après quelques itérations. Ce sont sans doute les lois du genre de la R&D, mais c'est toujours un peu frustrant d'avoir aperçu à quoi pourrait ressembler le futur et de voir la porte se refermer. Elle ne s'est cependant pas complètement refermée, du moins sur le gestionnaire de comptes, car la troisième priorité de Firefox pour 2011 est d'Expand the Open Web Platform to include Apps, Social and Identity, notamment en créant des systèmes ouverts de gestion de l'identité et des interactions sociales. A vrai dire, dès la mi-2010, un ticket avait été créé pour intégrer la première extension dans Firefox 4. Les travaux ont été bon train durant quelques mois, avant une soudaine inactivité, le report de la fonctionnalité dans Firefox 5, puis finalement l'annonce de son abandon, sans plus d'explications. C'est en cherchant des informations sur Dan Mills, qui avait fermé le ticket en indiquant juste un changement d'orientation, que j'ai fini par tomber sur MozillaID / Verified Email.

Si je fait ce petit rappel historique, c'est en guise de mise en garde: souvent Mozilla varie, bien fol qui s'enthousiasme trop vite. Je n'ai pas réussi à trouver d'informations permettant de deviner si ce nouveau projet a de l'avenir ou va finir comme tant d'autres dans les poubelles du centre de recherche de la Fondation. Les commentaires de ce billet sont ouverts à toute précision, et je tâcherai de vous tenir informés des évolutions du projet.

Découvrir Verified email a en tout cas été une bonne surprise pour moi. Cela m'a redonné espoir que l'innovation pour Mozilla ne se borne pas à courir derrière la concurrence (je ne suis pas près de digérer le ticket 665580), mais continue à essayer d'inventer de nouveaux outils pour donner plus de pouvoir à l'utilisateur. Ouf, Momo rules toujours.

Notes

[1] reformulation de la phrase après la remarque de Stéphane Bortzmeyer