Couche d'identité souveraine dans la blockchain

L'authentification répond à qui contrôle une clé à ce moment-là. L'identité ajoute de la continuité : comment une partie effectue une rotation des clés, prouve son autorité pour agir, reçoit un identifiant, limite un agent et récupère après une perte d'appareil. Une couche d’identité souveraine coordonne ces fonctions sans faire d’une connexion à la plateforme la seule racine de confiance.

Le mot souverain ne signifie pas anonyme par défaut ou exempté de politique. Cela signifie que le sujet ou un contrôleur explicitement autorisé dispose d’un contrôle cryptographique significatif. Une bonne implémentation peut prendre en charge un particulier, une organisation réglementée, un validateur, un appareil IoT, un contrat intelligent ou un agent IA, tandis que chacun utilise une politique d'identification et de divulgation appropriée.

Quatre couches sont faciles à séparer lors d’une revue d’architecture. L'identifiant nomme le sujet. Le document DID publie les méthodes de vérification et les points de terminaison de service. Les informations d'identification portent des réclamations signées par les émetteurs. Un portefeuille ou un environnement d'exécution d'agent contient des clés privées et demande le consentement avant une présentation. La combinaison de ces tâches crée des systèmes fragiles et une large exposition des données.

Il existe également un test opérationnel. Une couche d'identité a besoin d'une réponse documentée pour les clés compromises, la révocation, la disponibilité du résolveur, la confiance de l'émetteur, le risque de corrélation, le stockage des données personnelles et la migration du portefeuille. Une blockchain peut rendre l’État public inviolable ; il ne peut pas décider seul si un émetteur doit être digne de confiance ou si une réclamation divulguée est proportionnée.

W3C a publié les identifiants décentralisés v1.0 en tant que norme Web officielle le 19 juillet 2022. La norme définit un DID comme un URI sous la forme did:method:method-specific-id, un modèle de données de document DID commun et des interfaces de résolution abstraite et de déréférencement. Il laisse délibérément le registre sous-jacent et les règles opérationnelles à chaque méthode DID.

Un document DID possède une propriété de niveau supérieur obligatoire, id. Les propriétés facultatives courantes incluent controller, verificationMethod, les relations d'authentification et d'assertion, l'accord de clé, les capacités déléguées et les points de terminaison de service. Les clés privées n'appartiennent pas au document DID.

La recommandation de 2022 a enregistré 103 spécifications de méthode expérimentale DID, 32 implémentations de pilotes expérimentaux et 46 implémentations soumises à sa suite de conformité. Ces décomptes de la spécification W3C constituent un signal historique utile : une syntaxe standard améliore l’interopérabilité, mais elle n’efface pas les choix de conception de centaines de méthodes.

« Les identifiants décentralisés (DID) sont essentiels pour garantir un Web plus sûr et le type d'expériences client autonomes que nous proposons chez Avast.

La résolution est le pont entre un identifiant et un matériel de vérification utilisable. Un résolveur applique les règles de lecture de la méthode et renvoie un document DID ainsi que des métadonnées. Cela rend le choix de la méthode conséquent : un identifiant did:web dépend de l'hébergement Web et du contrôle de domaine, une méthode ancrée dans un grand livre dépend de la disponibilité et du modèle de frais de ce réseau, et une méthode dérivée d'une clé présente différents compromis de mise à jour et de récupération.

Pour une introduction plus approfondie orientée Autheo, voir le FAQ sur les identifiants décentralisés et le FAQ sur la conformité W3C DID Core. Les deux doivent être lus comme un contexte de feuille de route pour TheoID, et non comme une affirmation selon laquelle TheoID est disponible aujourd'hui.

Ethereum possède un riche écosystème d'identité car les comptes, les signatures, les contrats et l'état public sont composables. Il ne prescrit pas une seule couche d’identité à l’échelle du réseau. Au lieu de cela, les développeurs combinent le contrôle des adresses, les signatures de portefeuille, les comptes de contrat, la dénomination, les méthodes DID, les bibliothèques d'informations d'identification et la politique d'application en fonction du problème qu'ils résolvent.

ENS est la couche de dénomination la plus connue de cet écosystème. Son documentation décrit la création d'applications avec une identité autonome décentralisée et couvre la recherche d'adresses, les enregistrements de texte, les avatars, les noms principaux, les registres, les résolveurs et les résolveurs inter-chaînes. Un nom ENS peut être un identifiant lisible par l'homme et une surface de découverte, mais un nom à lui seul ne constitue pas un système complet de cycle de vie des informations d'identification.

ERC-1056, également connu sous le nom d'identité légère Ethereum spécifie un registre Ethereum DID commun pour la gestion des clés et des attributs. Sa conception traite les comptes Ethereum comme des identités, prend en charge un nombre illimité de délégués et d'attributs et permet la rotation des clés tandis que l'identifiant principal reste stable. La création d'identité ne nécessite aucune transaction d'enregistrement distincte car le compte lui-même est le point de départ.

Cette flexibilité constitue la force du Ethereum et son coût d'intégration. Un produit peut utiliser ENS pour la découverte, Sign-In with Ethereum pour l'authentification de session, les outils ERC-1056 ou did:ethr pour les documents DID et une pile d'informations d'identification vérifiables distincte pour les réclamations. Chaque composant peut être excellent, mais l'équipe doit définir les limites de l'interopérabilité, des coûts de transaction, de la confidentialité, de la récupération et du support.

Explorez le Comparaison Autheo et Ethereum existant pour une vue plus large de l'infrastructure. Ce qu’il faut retenir ici, ce n’est pas que le Ethereum manque d’innovation en matière d’identité. Le fait est que Ethereum prend en charge plusieurs approches d’identité, tandis que les systèmes spécialement conçus font différents compromis en matière de conception de registre et de confidentialité des informations d’identification.

Hyperledger Indy a pris la direction architecturale opposée : un grand livre public et autorisé sans jeton, spécialement conçu pour les informations d'identification vérifiables préservant la confidentialité. Son examen annuel 2024 décrit le projet comme stable et robuste, note les utilisateurs existants et les nouveaux déploiements privés, et indique que l'intérêt de la communauté est centré sur l'identité et les informations d'identification décentralisées plutôt que sur l'architecture du grand livre.

Indy reste pertinent car il a rendu concrets les flux DID, les registres de révocation, AnonCreds et les flux émetteur-titulaire-vérificateur pour de nombreuses équipes. Le projet a également signalé que l'ancien Indy SDK était obsolète à la fin du premier trimestre 2024, l'écosystème évoluant vers les composants partagés Aries Askar, Indy VDR et Hyperledger AnonCreds. Il s’agit d’une leçon du cycle de vie : un système d’identité doit planifier la migration des clients et de la cryptographie, et pas seulement l’émission initiale.

Sovrin a utilisé Hyperledger Indy pour un réseau d'identité public autorisé. En février 2025, le Fondation Sovrin a déclaré qu'il se préparait à l'arrêt probable de son grand livre MainNet au plus tard le 31 mars 2025 après sept ans, citant une évaluation de la durabilité du réseau. Cela n’invalide pas les idées avancées, mais cela montre pourquoi la continuité, le financement, la gestion des opérations, les voies d’exportation et les éventualités de résolution appartiennent à un modèle de menace identitaire.

Les systèmes spécialement conçus peuvent offrir une forte concentration sur le domaine et des primitives de confidentialité soigneusement conçues. Ils peuvent également créer une concentration opérationnelle autour d’un réseau et d’une pile logicielle spécifiques. L'assemblage de style Ethereum offre une large composabilité mais transfère davantage de coordination vers l'application. Aucun des deux modèles ne supprime le besoin de gouvernance des émetteurs, de recherche sur l’utilisabilité et de récupération résiliente des clés.

Autheo maintient un DID et page de comparaison d'identité et un Historique du réseau Sovrin détaillé. Pour une comparaison actuelle et couverte de la feuille de route, voir Autheo, Indy, Sovrin et uPort.

TheoID est la couche d'identité souveraine prévue de Autheo. Il n'est pas en ligne sur Autheo aujourd'hui et n'est pas encore intégré au système en direct. Les frais de jalonnement et de transaction sont en vigueur aujourd’hui ; l'identité, le calcul, le stockage, l'inférence IA et THEO AI restent en développement et sont déployés par phases.

Lors de son déploiement, TheoID est destiné à s'aligner sur W3C DID et sur les concepts d'informations d'identification vérifiables afin que les personnes, les organisations, les appareils, les validateurs et les agents puissent utiliser des identifiants interopérables et des revendications signées. Le modèle prévu se concentre sur l'identité portable, l'autorisation étendue, la gestion du cycle de vie des informations d'identification et une base d'identité partagée pour les applications construites autour de Autheo.

La feuille de route décrit également la prise en charge de la cryptographie post-quantique, mais cette protection n'est pas active et n'est pas encore intégrée au système. Les équipes doivent évaluer leurs contrôles de sécurité actuels en fonction de ce qui est opérationnel aujourd'hui, et non en fonction des futurs plans d'intégration. Le Page de la feuille de route du TheoID est la référence canonique Autheo pour le statut en cours.

Pour la conception d’agents IA, l’idée importante est la délégation limitée. Un agent devrait recevoir un identifiant ou une capacité limitée par son objectif, ses ressources, son montant, sa durée et ses conditions de révocation, plutôt qu'une copie de l'autorité du portefeuille étendu d'un être humain. Cette architecture fait partie de l'orientation prévue du TheoID et non d'une fonctionnalité de production disponible aujourd'hui.

Autheo fonctionne sur Proof of Autheo, un modèle consensuel Hybrid PoA/PoS. Ce mécanisme de consensus et une couche d'identité résolvent différents problèmes : l'un coordonne l'éligibilité des validateurs et la production de blocs pondérés en fonction des enjeux, tandis que l'autre est conçu pour représenter et authentifier les sujets et leur autorité déléguée.

Commencez par la question de la partie de confiance, et non par une préférence de chaîne. Que doit savoir le vérificateur ? Qui peut émettre la réclamation ? Le titulaire peut-il présenter un justificatif minimum ? Comment la clé de l'émetteur est-elle découverte et que se passe-t-il après une compromission ou une révocation ? Les réponses déterminent si un DID, un identifiant, un message signé ou un compte fédéré conventionnel est approprié.

Mesurez ensuite le chemin opérationnel. Testez la rotation des clés, la migration des appareils, la récupération des appareils perdus, la révocation de l'émetteur, les pannes du résolveur, l'expiration des informations d'identification et l'escalade du support. Une conception d’identité qui ne fonctionne que pour un nouveau portefeuille dans une démo n’est pas une couche d’identité souveraine en pratique.

Enfin, conservez les données personnelles hors des registres publics, à moins qu’il n’existe une raison impérieuse et une base légale. Les registres peuvent ancrer des hachages, des clés publiques, des références de révocation ou des transitions d'état. Les informations d'identification elles-mêmes, les attributs sensibles et l'enregistrement du consentement nécessitent souvent des contrôles de stockage et de divulgation préservant la confidentialité.