Avant tout, la spec est loin d’être finie, elle est en cours d’élaboration, et les essais d’implémentation de ce qu’elle contient permettront de la faire évoluer. Je me suis basé dans mon billet essentiellement sur le premier brouillon, pour expliquer le principe général. Je n’ai pas lu dans le détail toutes les versions suivantes.

Echange entre le serveur de mail et le navigateur: la première version proposée par la spec est que le navigateur envoie la clé publique de l’adresse au serveur, qui la stocke.
L’inconvénient est que pour récupérer cette clé, les sites tiers doivent interroger le serveur de mail, qui peut donc connaître tous les sites auxquels l’internaute se connecte. Pour pallier ce soucis, le navigateur peut stocker lui-même la clé publique signée par le serveur, et la présenter aux sites tiers. Ceux-ci doivent alors récupérer la clé publique du serveur de mail, et non la clé publique de l’adresse, stockée sur le serveur de mail.
La partie qui n’est pas encore spécifiée, et pour laquelle WebFinger pourrait être utilisé, c’est la découverte par le site tiers du serveur ayant autorité sur l’adresse.
Le point d’entrée des échanges entre le navigateur et le serveur, c’est une API JavaScript. Tel que je vois les choses, tu te connectes à ton Webmail, et dans la page de réponse il y a un script indiquant au navigateur que tu es identifié sur ce serveur avec telle adresse. Ce script contient une autre fonction acceptant un seul paramètre, la clé publique généré par le navigateur. Le navigateur va alors demander à l’utilisateur s’il veut enregistrer cette clé et en cas de réponse positive, générer la paire de clés pour passer la clé publique à la fonction de callback. L’implémentation de celle-ci est libre, ainsi que la façon dont le serveur reçoit et stocke la clé. Par exemple la fonction peut poster un formulaire avec l’adresse, la clé publique et un token unique.

Je ne pense pas que la révocation soit laissée à plus tard. Elle n’est je crois pas encore définie, mais il m’étonnerait que la spec laisse ce point en suspens.

Pour la simplicité, dans le cas idéal où le serveur implémente la spécification, ce qui est quand même le but, la simplicité donc sera au rendez-vous: l’utilisateur se connecte à son Webmail, le navigateur lui demande s’il veut enregistrer cette adresse (comme il le demande aujourd’hui pour tout mot de passe que tu saisis), etc c’est tout. Ensuite, lorsque l’utilisateur veut se connecter sur un site compatible, le navigateur lui signale qu’il peut le faire avec une des adresses mémorisées. Il suffit d’en choisir une et le reste de la connexion est transparente.
Evidemment, si on doit passer par un serveur tiers, c’est un peu plus compliqué. C’est le pire des cas et ça se rapproche effectivement d’OpenID. Mais le pire n’est pas toujours certain, et on peut aussi parier que certains fournisseurs de mail jouent le jeu.

Pour terminer sur OpenID, effectivement, beaucoup de gens en ont un sans le savoir. Mais ne vont pas l’utiliser parce qu’ils ne savent pas ce que cela implique. Imagines-tu un site disant: « vous pouvez vous identifier avec votre compte Google, Yahoo, etc ». Je pense que beaucoup de gens ne le feront pas par peur de se faire voler leur mot de passe. Facebook a réussit sa communication autour de Connect. OpenID n’a malheureusement pas les moyens d’éduquer les utilisateurs pour les convaincre de l’utiliser.