Tim Berners-Lee kort geleden kondigde het besluit aan om de specificatie om te zetten die de gedecentraliseerde identifiers voor het web definieert (DEED, gedecentraliseerde identificatie), in de staat van aanbevolen standaard, waardoor de bezwaren van Google en Mozilla teniet worden gedaan.
De specificatie DID introduceert een nieuw type global identifiers alleen degenen die zijn niet gekoppeld aan individuele gecentraliseerde organisaties en diensten, zoals domeinregistreerders en certificeringsinstanties. De identificator kan worden geassocieerd met een willekeurige bron en gegenereerd door systemen die worden vertrouwd door de eigenaar van de bron.
Identificatieverificatie maakt gebruik van eigendomsverificatie op basis van cryptografische mechanismen, zoals digitale handtekeningen. De specificatie maakt verschillende methoden mogelijk voor gedistribueerde controle en het ophalen van identiteitsinformatie, inclusief op blockchain gebaseerde methoden.
Het formaat van de nieuwe URI is gevormd als "did:method:unique_identifier", waar "did" het nieuwe URI-schema specificeert, "method" het mechanisme aangeeft voor het verwerken van de identifier, en "unique_identifier" een methode-specifieke resource-identifier is.
Het veld met de methode specificeert de naam van de service die wordt gebruikt om geverifieerde gegevens op te slaan, die de uniciteit van de identifier garandeert, het formaat bepaalt en zorgt voor de binding van de identifier aan de bron waarvoor deze is gemaakt. De URI met de ID wordt geconverteerd naar een JSON-document met metadata die het gevraagde object beschrijft en openbare sleutels bevat om de eigenaar te verifiëren.
Methode-implementaties vallen buiten het bereik van de DID-standaard, zijn gedefinieerd in de specificaties en worden bewaard in een apart register.
Op dit moment 135 methoden zijn voorgesteld gebaseerd op verschillende blockchains, cryptografische algoritmen, gedistribueerde technologieën, gedecentraliseerde databases, P2P-systemen en identificatiemechanismen. Ook het is mogelijk om DID-koppelingen te maken op gecentraliseerde systemen, bijvoorbeeld, de webmethode maakt het mogelijk om traditionele hostnamen te binden (bijvoorbeeld "did:web:example.com").
De bezwaren van Google hebben betrekking op de scheiding van de specificatie voor het algemene mechanisme van gedecentraliseerde identificatiecodes van de specificaties voor de uiteindelijke implementatie van de methoden, waardoor de juistheid van de hoofdspecificatie niet kan worden geanalyseerd zonder de specificaties van de methoden te bestuderen.
Het publiceren van de hoofdspecificatie wanneer de methodespecificaties niet gereed zijn, maakt revisie moeilijk, en Google heeft gesuggereerd dat de standaardisatie van de algemene DID-specificatie wordt uitgesteld totdat enkele van de beste methoden gereed zijn voor standaardisatie, aangezien in het proces van methodestandaardisatie subtiele punten kunnen ontstaan waarvoor de hoofdspecificatie moet worden afgerond.
Mozilla's bezwaar is dat de specificatie de draagbaarheid niet voldoende bevordert, waardoor het probleem wordt overgelaten aan de kant van de methoderegistratie.
Er zijn al meer dan honderd methoden voorgesteld in het register, gecreëerd zonder rekening te houden met compatibiliteit en unificatie van standaardoplossingen. In de huidige vorm wordt aanbevolen om voor elke taak een nieuwe methode te creëren, in plaats van te proberen bestaande methoden aan uw behoeften aan te passen.
Het standpunt van het W3C is dat standaardisatie van de DID-specificatie, die een nieuwe uitbreidbare identificatieklasse en bijbehorende syntaxis definieert, de ontwikkeling van methoden en consensus over methodestandaardisatie zal bevorderen.
In zijn huidige vorm er voldoende bewijs is van de toepasbaarheid van de hoofdspecificatie om problemen op te lossen waar veel vraag naar is in de gemeenschap die gedecentraliseerde technologieën ontwikkelt. De voorgestelde implementaties van methoden mogen niet worden beoordeeld naar analogie met nieuwe URL-schema's, en het creëren van een groot aantal methoden kan worden gezien als conform de basisspecificatie voor de behoeften van ontwikkelaars.
Standaardisatie van bepaalde methoden wordt als een moeilijkere taak gezien, in termen van het bereiken van consensus onder ontwikkelaars, dan het standaardiseren op een gemeenschappelijke klasse van identifiers. Daarom wordt het aannemen van een gemeenschappelijke specificatie vóór methodestandaardisatie beschouwd als een oplossing die minder potentiële schade kan toebrengen aan de gemeenschap die gedecentraliseerde identifiers implementeert.
Eindelijk als u er meer over wilt weten, kunt u de details in de volgende link.