L’iden­tité avec Mozilla


Mozilla avance sur la gestion de l’iden­tité dans le navi­ga­teur, et c’est une bonne chose. Malheu­reu­se­ment je crains qu’ils ne se four­voient, et ça c’est beau­coup moins bien.

Avant d’en lire ma critique je vous propose de lire l’aperçu initial de Clochix. Bien rédigé, il vous permet­tra de vous faire une première idée avant que je vous embrouille la tête.

Complexité

Si je résume, pour le serveur email le système se repose sur la créa­tion de clefs de chif­fre­ment spéci­fiques à chaque utili­sa­teur, leur entre­pôt et leur gestion, sur un nouveau proto­cole (qui ne m’a pas semblé décrit dans les spéci­fi­ca­tions) pour échan­ger une signa­ture avec le navi­ga­teur, et sur le système de décou­verte WebFin­ger pour publier la clef publique vis à vis du site qui souhaite authen­ti­fier.

Il faudra aussi que le pres­ta­taire email mette en place un méca­nisme pour révoquer les signa­tures / auto­ri­sa­tions données aux navi­ga­teurs afin qu’on ne donne pas un chèque en blanc illi­mité et qu’on puisse casser une auto­ri­sa­tion qui a été divul­guée publique­ment.

Pour le site qui souhaite authen­ti­fier il faut implé­men­ter une API javas­cript simple avec le navi­ga­teur, la décou­verte et la délé­ga­tion WebFin­ger, et la partie algo­rith­mique pour véri­fier la signa­ture four­nie par le navi­ga­teur.

Parce qu’au départ aucun pres­ta­taire ne supporte le système, il faut aussi implé­men­ter le système de décou­verte vers le tiers de confiance Mozilla, via une API que je n’ai pas vu décrite.

Pour gérer les navi­ga­teurs qui n’ont pas encore le méca­nisme, il faut aussi implé­men­ter une alter­na­tive simi­laire à OpenID qui se base sur des redi­rec­tions http, des jetons et une authen­ti­fi­ca­tion stan­dard (le tout n’étant pas décrit dans ce que j’ai pu lire lors de mes recherches).

Que celui qui ose me dire que tout ça est simple se dénonce. Pour­tant c’est l’ar­gu­ment présenté initia­le­ment. À côté, OpenID qui est jugé complexe par certain, fait presque rêver.

Not inven­ted here

La solu­tion met en avant un argu­ment de simpli­cité par rapport à OpenID mais j’y vois bien plus un syndrome « not inven­ted here » et une réin­ven­tion de la roue.

Au final l’al­ter­na­tive pour ceux qui n’ont pas Fire­fox ressemble bien à OpenID. On ne fait qu’y ajou­ter WebFin­ger. C’est une bonne idée mais il n’y avait pas besoin de recréer la roue pour ça : La liai­son entre WebFin­ger et OpenID existe déjà.

Le tiers de confiance ? quitte à utili­ser des tiers de confiance sur des certi­fi­cats cryp­to­gra­phiques, on a déjà des certi­fi­cats X.509 qui certi­fient l’iden­tité par l’adresse email et qui se basent sur des tiers de confiance. Ces tiers de confiance on en a la liste dans tous les navi­ga­teurs et même si ça reste centra­lisé, ça l’est moins que de réin­ven­ter une liste de tiers de confiance « Mozilla ».

Le push d’une authen­ti­fi­ca­tion avec éven­tuel­le­ment une inter­face navi­ga­teur pour ne pas avoir plein d’al­ler-retours et un mauvais work­flow utili­sa­teur ? j’ai déjà WebID, qui a le bon gout de pouvoir simple­ment s’in­ter­fa­cer avec WebFin­ger et ne pas néces­si­ter un support aussi impor­tant du gestion­naire d’iden­tité.

Je ne dis pas que toute cette pile de tech­nos est simple. Elle ne l’est pas, et elle est en bonne partie toujours en concep­tion. Mais en même temps la propo­si­tion de Mozilla aussi est complexe et toujours en gesta­tion.

Plutôt que de réin­ven­ter la roue, faire une exten­sion qui embarque OpenID dans le navi­ga­teur on l’es­père depuis long­temps et ça résou­drait une grosse partie du problème.

Mieux, juste amélio­rer les inter­faces qui permettent de gérer les certi­fi­cats clients dans le navi­ga­teur permet­trait d’im­plé­men­ter WebID main­te­nant, tout de suite. Ça deman­de­rait beau­coup moins de travail à tout le monde, que ce soit côté navi­ga­teur, côté gestion­naire d’iden­tité ou côté consom­ma­teur d’iden­tité. C’est là que j’at­ten­dais Mozilla.

Pour ne rien gâcher il y a une stan­dar­di­sa­tion W3C sur le sujet et la brique qui manque c’est vrai­ment l’in­ter­face navi­ga­teur. Se baser sur les travaux de stan­dar­di­sa­tion en cours, ou y poin­ter dès main­te­nant ce qui pose problème plutôt que de faire son truc dans son coin, c’est aussi ça parler d’ou­ver­ture.

Tiers de confiance

Mais ce qui m’agace le plus c’est ce dont je parlais il y a peu : le web ouvert recule.

Le méca­nisme choi­sit sera diffi­cile à faire implé­men­ter dans beau­coup d’or­ga­ni­sa­tions. Dans le meilleur des cas la progres­sion sera lente.  Mozilla a donc eu la bonne idée d’im­plé­men­ter un méca­nisme tempo­raire qui permette de passer par un tiers : le tiers de confiance.

Sauf que comme on le pointe avec perti­nence, le système ne fonc­tionne que si on n’ac­cepte pas n’im­porte qui comme tiers de confiance, que si la liste est réduite. À court terme le tiers de confiance est quasi obli­ga­toire, donc tout le monde peut et doit se repo­ser dessus.

Vu le confort d’avoir un tiers de confiance vis à vis la complexité d’al­ler cher­cher la clef publique via WebFin­ger, autant dire que la plupart risquent de se conten­ter du tiers de confiance.  On vient de réin­ven­ter le centra­lisé avec un saupou­drage de décen­tra­lisé dont il est évident qu’il ne sera que mineur pendant des années, si ce n’est plus.

La notion de tiers de confiance est un drapeau rouge qui doit immé­dia­te­ment indiquer qu’on part dans la mauvaise direc­tion. Il aurait fallu une solu­tion décen­tra­li­sée dès le départ, ou un réseau de confiance, ou un système de délé­ga­tion, ou d’autres systèmes, mais ne pas encou­ra­ger le démar­rage en centra­lisé. Il est illu­soire de croire qu’on en sortira.

OK, je vais aller plus loin, j’es­saie­rai de passer du temps pour montrer quelles inter­faces il manque et où Mozilla peut agir pour s’in­ter­face avec ce qui existe, mais il y a déjà un très bon aperçu au W3C. Bref, je vais tenter de décrire la voie qui selon moi serait à suivre histoire d’être aussi construc­tif.


4 réponses à “L’iden­tité avec Mozilla”

  1. Il
    n’y a pas vraiment de « protocole » pour que le navigateur envoie la clé
    publique au serveur de mail, c’est un simple appel d’une fonction JS de
    callback: le serveur via une page web fournit une fonction à appeler
    pour associer une clé publique à une adresse, l’implémentation de cette
    fonction est à sa guise.
    Le
    mécanisme de découverte des clés publiques liées à une adresse n’est
    pas encore décrit dans la spec, et je ne sais pas si les auteurs
    considèrent qu’il entre dans le périmètre. WebFinger est un moyen
    possible pour découvrir la clé publique liée à une adresse mail, mais
    rien n’est fixé. Je ne sais pas par exemple si pour PGP il existe un
    protocole de découverte de clés autrement qu’en interrogeant des
    annuaires.
    La
    question de la révocation des certificats est clairement signalée dans le
    brouillon de spec comme quelque chose qui reste à définir.
    Pour
    simplifier les développements pour les sites qui souhaitent mettre en
    place cette authentification, ils pourront utiliser un service tiers de
    vérification: ils n’auront besoin que d’implémenter le javascript de
    récupération de l’adresse et de l’envoyer à un service qui la vérifiera.
    Charge à eux de trouver un service auquel ils feront confiance. Mozilla
    devrait mettre en place un tel service.

    Sur
    la simplicité, elle est à voir du point de vue de l’utilisateur, pas de
    l’architecture à mettre en place derrière. Ceci dit, les autorités
    secondaires et les services tiers de vérification peuvent se charger du
    plus gros du boulot. Si tu trouves un prestataire de confiance,
    l’implémentation sur ton site nécessite juste un peu de JS et un appel
    de web service.

    Par
    rapport à OpenID, le principal avantage que je vois est de pouvoir
    utiliser n’importe quelle adresse mail existante, ne pas demander aux
    gens de se créer encore un nouveau compte (je sais que beaucoup de gens ont déjà accès sans le savoir à OpenID via Gmail par exemple. Beaucoup mais pas tous les internautes. Tous par contre ont déjà une adresse mail. La « certification » d’une adresse mail existante, avec une interface agréable entre ton webmail et ton navigateur, est probablement plus intuitive que la création d’un OpenID.

    OpenID est séduisant sur le papier, mais pour l’instant ça ne prend pas et on voit de plus en plus de sites l’abandonner. De ce que j’ai lu, les gens du groupe de travail Identity de Mozilla considèrent que c’est un échec ( cf https://wiki.mozilla.org/Ident… ) et veulent explorer d’autres voies.
    Pour ce qui est de WebID, je ne connais pas assez pour te répondre.

    Sur
    le tiers de confiance, je partage tes inquiétudes. Il y a sûrement
    moyen d’enrichir la spec en rajoutant du réseau de confiance ou autre.
    Mais même spécifié, ça dépendra de la volonté des implémenteurs. Donc je n’ai pas grand espoir.
    Une chose est sure, il faut proposer une alternative à Facebook Connect qui offre davantage de contrôle à l’utilisateur. Verified emails va dans ce sens. Mais n’aboutira que si un consensus se fait pour l’implémenter dans suffisament de navigateurs.
    Je
    ne suis pas du tout spécialiste des question d’identification, j’ai
    voulu présenter la proposition de Mozilla pour lancer le débat, et sur
    ce point mon but semble atteint. Maintenant, j’attend de lire d’autres
    argumentaires.

  2. Pour l’échange entre le serveur de mail et le navigateur, je ne te comprends pas. J’avais compris que le navigateur présentait sa clef publique, le serveur mail la signait et renvoyait la signature. Tel que tu me le dos le navigateur envoie sa clef publique et le serveur de mail la stocke pour la présenter plus tard à qui la demande. Les deux me vont, mais les deux imposent un protocole à gérer, avec des acceptations, des refus, des points d’entrées, etc. Tout ceci n’est pas et ne peut pas être géré par WebFinger qui ne s’occupe que de la découverte et éventuellement de la présentation d’une clef publique par le serveur de mail.

    Bref, il faut faire plus et c’est une des parties complexes. Qu’elle ne soit pas spécifiée est gênant. Et non, ce ne peut pas être simplement délégué à une fonction js de callback vu que c’est purement de l’initialisation, ça ne fait pas partie du workflow géré dans la session entre le navigateur et le site consommateur.

    Idem, que la révocation soit laissée à plus tard pour moi c’est assez étrange vu qu’on touche au coeur de la validation. Si la proposition de Mozilla se contente de définir une API navigateur sans définir comment gérer la partie réellement importante, je ne lui donne même pas 50 centimes. J’espère que c’est en cours de réflexion.

    Sur la simplicité non, ce n’est même pas plus simple pour l’utilisateur. Tu me dis qu’il faudra créer un openid mais là il faudra initialiser l’association entre le serveur mail et le navigateur, pour cela il faudra s’authentifier quelque part avec une procédure très similaire à une création de compte. Il y a même toutes les chances pour que le serveur email ne gère pas le mécanisme et qu’il faille passer par le tiers Mozilla. Là il faudra bel et bien s’enregistrer, passer par une validation mail classique, bref : créer un compte. Sauf qu’en plus il faudra le refaire pour chaque navigateur.

    Bref, tu demandes n’importe quelle adresse existante, à condition de pouvoir créer un compte sur un intermédiaire tiers. On n’a pas réellement d’avantage par rapport à OpenID là. OpenID tu as déjà un identifiant si tu es sur Google, Yahoo, MSN, Orange, Blogger, etc. J’ai beaucoup moins de chances d’avoir à créer un OpenID que d’avoir à créer mon compte sur le tiers de confiance Mozilla.

  3. bon article. Il y a un bonne video qui explique WebID sur http://webid.info/ . Elle a été présenté au workshop « Identity in the Browser » en Californie qui a eu lieu dans les bureau de Mozilla. Mais il faut mettre de la pression sur ces navigateurs. Une bonne facon c’est de déployer WebID, de jouer avec, de faire grandir les utilisateurs et de leurs demander de voter sur les bugs:
    http://code.google.com/p/chrom
    https://bugzilla.mozilla.org/s

  4. 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.