Le W3C dit non à Google et Mozilla sur l’identité décentralisée

Lorsqu’on établit un standard technique, faut-il standardiser, en parallèle, des méthodes sur lesquelles il pourra s’appuyer ? Google et Mozilla, entre autres, ont avancé l’argument face au W3C… sans succès.

Le contexte ? L’élaboration de la spécification DID (Decentralized Identifiers). Celle-ci deviendra, début août, une recommandation, marquant l’étape finale de son processus de ratification. Ainsi le W3C en a-t-il décidé la semaine dernière, écartant par la même occasion les objections de Google et Mozilla.

La spécification ouvre la voie à des identités « décentralisées ». Qui, dans les grandes lignes, auront les caractéristiques suivantes :

– Indépendantes de tout émetteur central
– Persistantes (aucune dépendance fonctionnelle vis-à-vis d’une quelconque organisation)
– Authentifiables cryptographiquement
– Associables à des métadonnées

Ces identités prennent la forme d’un URI auquel on applique une méthode pour obtenir un « document ». Celui-ci contient des informations que le propriétaire de l’identité peut choisir de communiquer sélectivement aux services auxquels il souhaite de connecter.

La spécification ne présuppose aucune technologie. Elle laisse la porte ouverte à des DLT, des systèmes de fichiers décentralisés, des bases de données distribuées, des réseaux P2P, etc.

Des voix – dont celles de Google et Mozilla – se sont élevées à ce sujet. Avec notamment une crainte : que certaines méthodes, en particulier celles fondées sur un seul serveur, ne tendent vers une centralisation.

Plus généralement, les détracteurs de la spécification pointent son manque d’interopérabilité en pratique. Dans l’absolu, le W3C y liste plus de 50 méthodes déclarées conformes… mais effectivement dépourvues d’implémentations. Un volume qui, en outre, encourage à développer des méthodes supplémentaires plutôt que de se raccrocher à l’une de celles listées, de l’avis de Microsoft.

Le W3C tire des enseignements du passé

Que conseillent Mozilla et consorts ? Procéder comme lorsqu’on avait standardisé les URL ou la balise img. Dans le premier cas, un éventail de méthodes avait été standardisé en parallèle. Dans le second, les formats d’images exploités existaient a priori. Et d’ajouter : impossible de réaliser une impact sur une spécification sans faire de même sur les méthodes qu’elle utilisera.

Autre élément pointé du doigt : le coût, tout particulièrement environnemental, des méthodes impliquant des mécanismes de consensus de type proof-of-work.

Le raisonnement du W3C peut se résumer ainsi :

– Les discussions ont démontré qu’il serait plus compliqué de s’accorder sur des méthodes spécifiques que sur un socle commun

– La quantité de méthodes jugées conformes prouve la pertinence de ce socle

– L’histoire l’a montré avec beaucoup de standards d’Internet : engager des travaux mène à des améliorations

– Aller de l’avant en adoptant une recommandation va motiver les développeurs à lancer ces travaux

– Les questions sur la décentralisation et ses coûts ne suffisent pas à contrebalancer le bénéfice d’un passage au stade de la recommandation

Photo d’illustration © bluebay – Shutterstock