W3C respinge obiecțiile Mozilla și Google cu privire la identificatorii descentralizați, nu mai putem adopta o poziție de așteptare cu privire la tehnologii, spune organizația


Consorțiul World Wide Web (W3C) a respins obiecțiile Google și Mozilla la propunerea Identificatorilor Descentralizați (DID), deschizând calea publicării specificației DID ca recomandare W3C luna viitoare. Revizuirea de către membrii W3C a recomandării propuse DID 1.0 a dus la obiecții formale din partea unor organizații.

Google :

DID-core este util doar cu utilizarea „metodelor DID”, care necesită specificații proprii. … Este imposibil să examinăm impactul specificației DID-core pe Web fără a examina simultan metodele cu care va fi utilizată. Ar trebui să urmăm precedentul creat de dezvoltarea URL, în care RFC 1738 a standardizat 10 scheme în același timp a standardizat URL-urile în general.

Procesul de promovare a unora dintre cele mai bune metode prin recomandare va ajuta la concentrarea revizuirii asupra lor și este probabil să dezvăluie unde ar trebui să se schimbe specificația did-core pentru a se adapta modalităților în care acestea se îmbunătățesc. . Vă sugerăm să nu avansați did-core la statutul REC până când cel puțin 3 sau mai multe metode nu sunt, de asemenea, pregătite pentru a avansa la REC.

Mozilla:

Specificația de bază a DID nu a demonstrat niciun grad de interoperabilitate practică, delegându-l în schimb unui registru de peste 50 de metode.

Abordarea arhitecturală a DID pare să încurajeze mai degrabă divergența decât convergența și interoperabilitatea. Prezența a peste 50 de intrări în registru, fără interoperabilitate reală, pare să implice că există stimulente mai mari pentru introducerea unei noi metode, mai degrabă decât încercarea de a interopera cu una dintre numeroasele metode de creștere existente. . Absența restricțiilor privind registrul permite metode care sunt diametral opuse principiilor grupului și caietului de sarcini și metode care sunt dăunătoare în mod activ și global durabilității. Credem că specificația DID poate să nu fie reparabilă (NU TREBUIE să devină o recomandare).

Cele două companii tehnologice se tem că natura deschisă a specificației va stimula haosul printr-o stradă cu spațiu de nume care încurajează proliferarea specificațiilor de metode neinteroperabile. Ei sunt, de asemenea, îngrijorați de etica de a se baza pe blockchain-urile „dovadă de lucru” pentru a gestiona DID-urile.

Specificația DID descrie o modalitate de a implementa un identificator unic la nivel global fără o autoritate centralizată (de exemplu, Apple pentru Conectare cu Apple) ca entitate de verificare.

Identificatorii descentralizați (DID) sunt un nou tip de identificator care permite o identitate digitală verificabilă și descentralizată. Un DID se referă la orice subiect (de exemplu, persoană, organizație, lucru, model de date, entitate abstractă etc.) așa cum este determinat de controlorul DID. Spre deosebire de identificatorii tradiționali federați, DID-urile au fost proiectate astfel încât să poată fi decuplate de registrele centralizate, furnizorii de identitate și autoritățile de certificare.

Mai exact, în timp ce alte părți pot fi utilizate pentru a permite descoperirea informațiilor legate de un DID, designul permite controlorului unui DID să dovedească controlul fără a avea nevoie de permisiunea unei alte părți. DID-urile sunt URI-uri care asociază un subiect DID cu un document DID, permițând interacțiuni de încredere asociate cu acel subiect.

Sunt concepute pentru a permite indivizilor și organizațiilor să-și genereze propriile acreditări folosind sisteme în care au încredere”, explică specificația. Aceste noi acreditări permit entităților să își dovedească controlul prin autentificarea folosind dovezi criptografice, cum ar fi semnăturile digitale.

Scopul DID-urilor este de a nu avea o agenție centrală emitentă, de a avea un identificator care persistă independent de orice organizație specifică, de a putea demonstra criptografic controlul asupra unui identificator și de a putea prelua metadatele despre identificator. Acești identificatori se pot referi la persoane, organizații, documente sau alte date.

DID-urile sunt conforme cu schema URI: did:example:123456789abcdefghi. Aici, „did” reprezintă schema, „example” reprezintă metoda DID, iar „123456789abcdefghi” reprezintă identificatorul specific metodei DID. Acest lucru ar fi exprimat într-un document DID, care este doar un obiect JSON care conține alte date cheie-valoare care descriu lucruri precum modul de verificare a controlorului DID (entitatea capabilă să modifice documentul DID, de obicei prin controlul cheilor criptografice) pentru pentru a avea o interacțiune de încredere și pseudonimă.

Ceea ce contestă Google și Mozilla este că metoda DID este nedefinită, așa că nu există nicio modalitate de a evalua modul în care vor funcționa DID-urile sau cum va fi gestionată interoperabilitatea.

W3C specifică:

Nu există nicio îndoială că o singură metodă DID nu poate atinge una sau mai multe dintre aceste proprietăți. Întrebarea aici este dacă sintaxa propusă pentru identificatorii DID și mecanismele asociate au fost suficient demonstrate pentru a fi definit o clasă extensibilă de identificatori având aceste proprietăți.

Obiectorii fac o analogie cu specificația URL originală și cu schemele URL incluse în această specificație. Din punct de vedere arhitectural, analogia dintre schemele URL/URI și metodele DID este rezonabilă. Oponenții îndeamnă ca o recomandare URI DID să urmeze precedentul stabilit de specificația URL, care includea mai multe scheme specifice corespunzătoare protocoalelor comune de atunci.

Deși această analogie reușește la nivel arhitectural, eșuează în context temporal. Discuția care a avut loc la crearea pistei de recomandare DID a arătat că există un consens că metodele standard DID sunt de dorit. Discuția a recunoscut că ajungerea la un consens asupra unor metode standard specifice ar fi mult mai dificilă decât atingerea unui consens pe o bază comună pentru această clasă de identificatori. Din această perspectivă, înregistrarea unei largi varietati de metode DID conforme poate fi văzută ca o demonstrație a faptului că specificația de bază răspunde nevoilor de consens ale celor care dezvoltă implementări în acest spațiu.

În sensul că există o varietate de implementări de metode care utilizează și se conformează specificației de bază, specificația de bază demonstrează interoperabilitatea acesteia. Este întotdeauna de dorit ca anumite metode să treacă și de recomandarea W3C. Întrebarea care se decide aici este care cale de a avansa nucleul DID la statutul de recomandare sau de a-l menține în așteptarea lucrărilor ulterioare asupra metodelor standard, este cea mai puțin dăunătoare comunității care are nevoie de identificatori descentralizați și comunității web în general.

Oponenții susțin că precedentul unor scheme URL standard existente la momentul în care specificația URL în sine a fost standardizată ar trebui să se aplice acum.

Google și Mozilla au ridicat și alte obiecții atunci când au discutat despre specificație anul trecut. După cum Manu Sporny, co-fondatorul și CEO al Digital Bazaar, a povestit într-o discuție pe lista de corespondență, reprezentanții Google au simțit specificația necesară pentru a aborda metodele DID care încalcă standardele etice sau de confidențialitate, cum ar fi permiterea urmăririi omniprezente. Ambele companii au argumentat, de asemenea, împotriva daunelor ecologice cauzate de blockchain-urile.

Noi (W3C) nu mai putem adopta o poziție de așteptare sau de neutră față de tehnologiile care consumă în mod evident consumatoare de energie”, a spus elik. În schimb, trebuie să ne opunem ferm acestor tehnologii de dovadă a lucrului, inclusiv să facem tot ce putem pentru a preveni integrarea sau activarea lor (chiar și opțional) de orice specificație pe care o dezvoltăm.

În ciuda acestor preocupări, precum și a rezistenței din partea Apple și Microsoft, W3C a respins obiecțiile într-o decizie publicată, o cerință pentru a avansa statutul specificației.

Sursa: W3C

Si tu?

Ce parere aveti despre subiect?

Vezi si:

WebAuthn: W3C și FIDO Alliance finalizează standardul pentru autentificare fără parolă și solicită site-urilor și companiilor să-l adopte

HTML 5.2 este acum finalizat și devine noua recomandare W3C și proiectul de specificație HTML 5.3 deja publicat

Google, Apple, Microsoft și Mozilla se opun în mod oficial unei decizii a W3C, care vrea să avanseze cu procesul de standardizare DOM 4.1

Add Comment