1 pièce(s) jointe(s)
Le W3C rejette les objections de Mozilla et de Google concernant les identifiants décentralisés
Le W3C rejette les objections de Mozilla et de Google concernant les identifiants décentralisés
« nous ne pouvons plus adopter une position attentiste ou neutre sur les technologies »
Le World Wide Web Consortium (W3C) a rejeté les objections de Google et de Mozilla à la proposition de Decentralized Identifiers (DID), ouvrant ainsi la voie à la publication de la spécification DID en tant que recommandation du W3C le mois prochain. L'examen par les membres du W3C de la recommandation proposée DID 1.0 s'est conclu par des objections formelles de certains organisations.
Google :
« DID-core n'est utile qu'avec l'utilisation de "méthodes DID", qui nécessitent leurs propres spécifications. ... Il est impossible d'examiner l'impact de la spécification DID-core sur le Web sans examiner simultanément les méthodes avec lesquelles elle va être utilisée. Nous devrions suivre le précédent établi par le développement des URL, dans lequel le RFC 1738 a normalisé 10 schémas en même temps qu'il a normalisé les URL en général.
« Le processus de promotion de quelques-unes des meilleures méthodes par la voie de la recommandation aidera à concentrer la révision sur elles, et est susceptible de révéler les endroits où la spécification did-core devrait changer pour s'adapter aux façons dont ils s'améliorent. Nous suggérons de ne pas avancer did-core au statut de REC jusqu'à ce qu'au moins 3 méthodes ou plus soient également prêtes à avancer au REC. »
Mozilla :
« La spécification de base de DID n'a pas démontré un quelconque degré d'interopérabilité pratique, déléguant plutôt cela à un registre de plus de 50 méthodes.
L'approche architecturale de DID semble encourager la divergence plutôt que la convergence et l'interopérabilité. La présence de plus de 50 entrées dans le registre, sans aucune interopérabilité réelle, semble impliquer qu'il y a de plus grandes incitations à introduire une nouvelle méthode, plutôt que de tenter d'interopérer avec l'une des nombreuses méthodes existantes en pleine croissance. L'absence de restrictions sur le registre autorise des méthodes diamétralement opposées aux principes du groupe et de la spécification, et des méthodes qui sont activement et globalement nuisibles à la durabilité. Nous pensons que la spécification DID n'est peut-être pas réparable (elle NE DOIT PAS devenir une recommandation). »
Les deux entreprises technologiques craignent que la nature ouverte de la spécification ne favorise le chaos par une ruée vers les espaces de noms qui encourage la prolifération de spécifications de méthodes non-interopérables. Elles s'inquiètent également de l'éthique liée au fait de s'appuyer sur des blockchains "proof-of-work" pour gérer les DID.
La spécification DID décrit un moyen de déployer un identifiant unique au niveau mondial sans autorité centralisée (par exemple, Apple pour Sign in with Apple) comme entité de vérification.
Les identifiants décentralisés (DID) sont un nouveau type d'identifiant qui permet une identité numérique vérifiable et décentralisée. Un DID fait référence à n'importe quel sujet (par exemple, une personne, une organisation, une chose, un modèle de données, une entité abstraite, etc.) tel que déterminé par le contrôleur du DID. Contrairement aux identificateurs fédérés classiques, les DID ont été conçus de manière à pouvoir être découplés des registres centralisés, des fournisseurs d'identité et des autorités de certification.
Plus précisément, alors que d'autres parties peuvent être utilisées pour permettre la découverte d'informations liées à un DID, la conception permet au contrôleur d'un DID de prouver son contrôle sans avoir besoin de la permission d'une autre partie. Les DID sont des URI qui associent un sujet DID à un document DID permettant des interactions fiables associées à ce sujet.
« Ils sont conçus pour permettre aux individus et aux organisations de générer leurs propres identifiants en utilisant des systèmes auxquels ils font confiance », explique la spécification. « Ces nouveaux identifiants permettent aux entités de prouver leur contrôle en s'authentifiant à l'aide de preuves cryptographiques telles que les signatures numériques. »
objectif des DID est de ne pas avoir d'agence centrale d'émission, d'avoir un identifiant qui persiste indépendamment de toute organisation spécifique, de pouvoir prouver cryptographiquement le contrôle d'un identifiant et de pouvoir récupérer des métadonnées sur l'identifiant. Ces identifiants peuvent faire référence à des personnes, des organisations, des documents ou d'autres données.
Les DID sont conformes au schéma URI : did:exemple:123456789abcdefghi. Ici, "did" représente le schéma, "exemple" représente la méthode DID, et "123456789abcdefghi" représente l'identifiant spécifique à la méthode DID. Cela serait exprimé dans un document DID, qui n'est qu'un objet JSON contenant d'autres données clé-valeur décrivant des choses comme la façon de vérifier le contrôleur DID (l'entité capable de modifier le document DID, généralement par le contrôle de clés cryptographiques) afin d'avoir une interaction fiable et pseudonyme.
Ce que Google et Mozilla contestent, c'est que la méthode DID n'est pas définie, de sorte qu'il n'y a aucun moyen d'évaluer le fonctionnement des DID ni de déterminer comment l'interopérabilité sera gérée.
Le W3C précise :
« Il n'est pas question qu'une seule méthode DID puisse échouer à atteindre une ou plusieurs de ces propriétés. Il s'agit ici de savoir si la syntaxe proposée pour les identificateurs DID et les mécanismes associés ont été suffisamment démontrés pour avoir défini une classe extensible d'identificateurs ayant ces propriétés.
Les objecteurs font une analogie avec la spécification initiale de l'URL et les schémas d'URL que cette spécification incluait. D'un point de vue architectural, l'analogie entre les schémas URL/URI et les méthodes DID est raisonnable. Les opposants demandent instamment qu'une recommandation DID URI suive le précédent établi par la spécification URL, qui comprenait plusieurs schémas spécifiques correspondant à des protocoles alors courants.
« Bien que cette analogie réussisse au niveau architectural, elle échoue dans le contexte temporel. La discussion qui a eu lieu au moment de la création de la piste de recommandation DID a montré qu'il existait un consensus sur le fait que des méthodes DID standard étaient souhaitables. La discussion a reconnu que l'obtention d'un consensus sur des méthodes standard spécifiques serait beaucoup plus difficile que l'obtention d'un consensus sur une base commune pour cette classe d'identifiants. De ce point de vue, l'enregistrement d'une grande variété de méthodes DID conformes peut être considéré comme une démonstration que la spécification de base répond aux besoins de consensus de ceux qui développent des implémentations dans cet espace.
En ce sens, qu'il existe une variété d'implémentations de méthodes qui utilisent et sont conformes à la spécification de base, la spécification de base démontre son interopérabilité. Il est toujours souhaitable que certaines méthodes passent également à la recommandation du W3C. La question décidée ici est de savoir, quelle voie faire progresser le noyau de DID vers le statut de recommandation ou le maintenir en attente de travaux supplémentaires sur les méthodes standard, est la moins dommageable pour la communauté qui a besoin d'identificateurs décentralisés et pour la communauté du Web en général.
« Les opposants soutiennent que le précédent de l'existence de certains schémas d'URL standard au moment où la spécification de l'URL elle-même a été normalisée devrait s'appliquer maintenant. »
Google et Mozilla ont également soulevé d'autres objections lors des débats sur la spécification l'année dernière. Comme l'a raconté Manu Sporny, cofondateur et PDG de Digital Bazaar, dans une discussion sur la liste de diffusion, les représentants de Google estimaient que la spécification devait aborder les méthodes DID qui violent les normes éthiques ou de confidentialité, par exemple en autorisant un suivi omniprésent. Les deux entreprises se sont également opposées aux dommages environnementaux des blockchains.
« Nous (W3C) ne pouvons plus adopter une position attentiste ou neutre sur les technologies dont la consommation d'énergie est flagrante », a déclaré Çelik. « Nous devons au contraire nous opposer fermement à ces technologies de preuve de travail, y compris en faisant tout notre possible pour les empêcher d'être intégrées ou activées (même de manière facultative) par toute spécification que nous développons. »
En dépit de ces préoccupations, ainsi que de la résistance d'Apple et de Microsoft, le W3C a rejeté les objections dans une décision publiée, une exigence pour faire progresser le statut de la spécification.
Source : W3C
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: WebAuthn : le W3C et l'Alliance FIDO finalisent la norme pour les connexions sans mot de passe et appellent les sites et entreprises à l'adopter
:fleche: HTML 5.2 est désormais finalisée et devient la nouvelle recommandation W3C et le draft de la spécification HTML 5.3 déjà publiée
:fleche: Google, Apple, Microsoft et Mozilla s'opposent formellement à une décision du W3C, qui veut avancer dans le processus de standardisation de DOM 4.1
