Qui tient le dictionnaire des noms ?

Dans les systèmes numériques, un « nom » n’est pas un simple label : c’est une poignée opératoire. Le Triangle de Zooko soutient qu’un système de noms ne peut pas être à la fois humain-mental (mémorisable), sécurisé et décentralisé — on n’obtient que deux propriétés sur trois. Les DIDs (Decentralized Identifiers — Identifiants décentralisés), normalisés par le W3C, prétendent recomposer ce triangle : des identifiants contrôlés par leurs détenteurs, résolvables sans autorité centrale, vérifiables cryptographiquement, et reliés à des preuves (verifiable credentials). Que résolvent-ils vraiment ? Et que laissent-ils ouvert ? (Wikipédie)

Le triangle de Zooko

Le Triangle de Zooko pose une contrainte simple et tenace : pour un système de nommage (noms d’utilisateurs, adresses, domaines, identités), on voudrait des noms mémorisables par des humains, sécurisés (difficiles à usurper) et décentralisés (sans racine d’autorité unique). La conjecture dit : choisissez-en deux. Le DNS (avec DNSSEC) est humain-mental et sécurisé, mais centralisé (racines ICANN). Les adresses bitcoin ou .onion sont sécurisées et décentralisées, mais illisibles pour l’humain. D’autres systèmes bricolent des répertoires locaux « de confiance » : humains et parfois sécurisés, mais qui ne passent pas l’échelle globale. (Wikipédie)

Cette trilemme a suscité, depuis vingt ans, des tentatives de « carré » : tout avoir. Les années 2010 ont vu émerger des solutions à base de blockchain (Namecoin, ENS, Handshake…) promettant des noms lisibles, sécurisés et décentralisés. Les papiers techniques restent partagés sur le verdict : gains réels (résistance à la censure, auto-authentification), mais coûts en gouvernance, risques de captation de noms rares et attaques Sybil si les mécanismes d’attribution sont faibles. Le triangle n’est pas renversé, il est déplacé : une propriété « gagnée » se paie ailleurs (allocation, arbitrage, lisibilité universelle). (arXiv)

C’est dans ce paysage que le W3C a standardisé les DIDs — Decentralized Identifiers (DID) v1.0 — Identifiants décentralisés — en Recommandation (19 juillet 2022). Un DID ressemble à ceci : did:method:clé, où method indique comment résoudre l’identifiant (dans une blockchain, un registre distribué, un service pair-à-pair…), et clé pointe vers un document DID (DID Document) qui contient des métadonnées : clés publiques, services de résolution, paramètres de rotation ou de révocation. L’idée : découpler l’identité d’une personne ou d’un service de tout registre central, tout en permettant la vérification cryptographique et la portabilité. (W3C)

Les DIDs prennent sens avec les Verifiable Credentials (VC — Justificatifs vérifiables), également normalisés au W3C — Verifiable Credentials Data Model v2.0 (Recommandation, 15 mai 2025). Un VC est un ensemble d’assertions signées (ex. « cette personne possède tel diplôme »), émis par une autorité (université, administration) à destination d’un titulaire, qui peut ensuite présenter ces preuves à un vérificateur — sans exposer plus d’information que nécessaire (sélective disclosure), et avec des mécanismes de révocation/expiration. L’émetteur et le vérificateur peuvent chacun être identifiés par des DIDs. Ensemble, DIDs + VC visent une promesse : sécurité, décentralisation, et — via des alias locaux — un certain confort humain. (W3C)

Où gagne-t-on par rapport au triangle ?

1. Sécurité : l’authenticité se prouve par cryptographie (signatures, preuves), et la rotation de clés limite l’usurpation durable. Pas besoin d’un certificat X.509 adossé à une CA géante ; on peut vérifier à la volée via le DID Document. (W3C)
2. Décentralisation : pas de racine unique ; chaque méthode DID (did:key, did:web, did:ion, etc.) définit son substrat (du simple fichier HTTPS aux ancrages sur des réseaux distribués). On substitue une fédération de méthodes à la pyramide DNS/ICANN. (W3C)
3. Humain-mental (partiel) : un DID n’est pas, en soi, mémorisable. Mais on peut lier un DID à un alias local (carte de contacts, carnet d’adresses, UI du portefeuille d’identité). L’humain ne retient plus la clé, il retient un nom de relation (petname). Zooko n’est pas nié ; on déplace l’exigence d’humanité vers la couche d’interface. (Wikipédie)

Où le triangle continue de mordre

• Lisibilité globale : si chaque communauté maintient ses alias, le conflit de noms ressurgit à l’échelle globale (deux « @alice » pointant sur deux DIDs différents). Les DIDs n’éliminent pas le problème social d’arbitrage des noms rares ; ils le déplacent. (Wikipédie)
• Gouvernance de méthodes : la méthode DID est un point de confiance (qui maintient la chaîne, le registre, le fichier HTTPS ?). On troque la racine unique contre des racines multiples — il faut auditer les méthodes. (W3C)
• Expérience utilisateur : sans bons alias, l’humain reste face à des chaînes opaques. Les projets de noms « blockchain » (ENS, etc.) offrent des alias globaux, mais réimportent captation spéculative et litiges. (arXiv)

En pratique, le paquet DID + VC + UI de petnames/contacts permet un compromis robuste pour ma série « Vrai nom » : on garde des noms opératoires (DIDs) découplés des personnes civiles, on atteste des attributs via des preuves révoquables, et l’on retrouve, côté humain, le nom vécu (alias de relation). Autrement dit : on sépare, enfin, nom qui agit et nom qui parle.

À quoi cela sert-il pour tes thèmes (golem / EMET→MET / gestes d’arrêt) ?

• Geste d’arrêt : un VC peut être révoqué, un DID roté — équivalents techniques de MET (désactivation) plutôt que de la lettre magique. Ici, l’arrêt est procédural, journalisé, auditables. (W3C)
• Réduction de surface : au lieu d’user du nom-civil (exposé, indexable), on présente un VC minimal (« +18 ans », « membre de X ») sans livrer plus — moindre emprise des « golems de papier ». (W3C)
• Traçabilité maîtrisée : par séparation des rôles (émetteur / titulaire / vérificateur), on limite les corrélations sauvages. Là encore, le pouvoir ne disparaît pas ; il devient conditionné.

Et les systèmes « tout-en-un » (ENS, Namecoin, Handshake) ?

Ils fournissent des alias globaux (lisibles), ancrés sur des chaînes publiques. Ils « semblent » battre le triangle : lisibles et décentralisés et sécurisés. En pratique, ils obtiennent le trio au prix d’autres contraintes : gouvernance (qui tranche les collisions ?), inégalités d’allocation (accaparement précoce), et interopérabilité (hors DNS). Les études académiques sur ENS ou Namecoin confirment ces déplacements : on gagne en résilience, on perd en médiation institutionnelle. (arXiv)

Encadré — Schéma minimal (triangle de Zooko, en texte)

        Humain-mental (mémorisable)
                 /\
                /  \
               /    \
      Sécure  /______\  Décentralisé
      (anti-   limites   (sans racine
     usurp.)  de Zooko)     unique)

Exemples rapides :

• DNS/DNSSEC → Humain + Sécure, pas Décentralisé.
• Adresses .onion / clés → Sécure + Décentralisé, pas Humain.
• DIDs + alias locaux → Sécure + Décentralisé nativement ; Humain via UI de relation (petnames). (Wikipédie)

Encadré — Ce que les DIDs résolvent / ne résolvent pas

Résolvent

• Vérification sans registre central (documents DID). (W3C)
• Rotation / révocation d’identifiants sans changer de « personne ». (W3C)
• Lien avec des preuves (VC 2.0) minimisant l’exfiltration de données. (W3C)

Ne résolvent pas

• Conflits de noms lisibles à l’échelle globale (si on veut un « @alice » mondial). (Wikipédie)
• Gouvernance des méthodes (qui garde le substrat sain ?). (W3C)
• Ergonomie sans UI de qualité (sinon chaînes opaques).

Lexique (réutilisable)

• Zooko’s Triangle — Triangle de Zooko : trilemme noms humain-mentaux / sécurisés / décentralisés (choisir deux). (Wikipédie)
• DID (Decentralized Identifier) — Identifiant décentralisé : identifiant vérifiable dont la résolution ne dépend pas d’une autorité centrale ; spécifié par le W3C DID v1.0. (W3C)
• DID Document : document associant au DID des clés, services et règles de mise à jour. (W3C)
• VC (Verifiable Credential) — Justificatif vérifiable : attestation signée (émetteur → titulaire → vérificateur), modèle W3C VCDM 2.0. (W3C)
• Petname — Nom de relation : alias local attribué par l’utilisateur (lisibilité sans prétention globale). (Wikipédie)

À retenir (pour la série « Vrai nom »)

Le triangle ne disparaît pas : on relocalise la contrainte. Les DIDs donnent des noms opératoires robustes ; les VC apportent des preuves révoquables ; l’interface fournit les noms vécus. Le pouvoir ne s’évanouit pas : il devient procédurel, auditable, révocable. Autrement dit : un cadre où nommer n’expose pas fatalement — à condition de garder la main sur qui résout quoi, avec quelles preuves, jusqu’à quand.

Sources clés

• Triangle de Zooko — présentation & typologie (exemples DNS, .onion, Bitcoin). (Wikipédie)
• W3C — Decentralized Identifiers (DID) v1.0 — Recommandation (19 juillet 2022). (W3C)
• W3C — Verifiable Credentials Data Model v2.0 — Recommandation (15 mai 2025) + historique. (W3C)
• Analyse académique ENS / Namecoin (forces/limites, « solution au triangle » revendiquée). (arXiv)

Sommaire de la série

• 1. Nommer pour habiliter — Le Guin (Earthsea — Terremer)
• 2. Nommer pour prendre — Isis & Rê (Papyrus de Turin)
• 3. Nommer pour délier — Rumpelstiltskin (ATU 500)
• 4. Noms à l’ère réseau — Vernor Vinge
• 5.Argile et algorithmes — à Propos du Golem
• 6. Qui tient le dictionnaire des noms ? — Triangle de Zooko

Voir tous les épisodes (page du mot-clé)