Especificació d'Identificadors Descentralitzats (DIDs) del W3C (CA)

L'especificació d'Identificadors Descentralitzats (DIDs) del W3C defineix una sintaxi URI, un model de dades comú, documents DID, propietats bàsiques, representacions, requisits de mètodes i interfícies abstractes per a la resolució i la desreferenciació d'URL DID. DID Core 1.0 va esdevenir una Recomanació del W3C el 19 de juliol de 2022. DID Core 1.1 es va publicar com a Candidate Recommendation Snapshot el 5 de març de 2026; és un treball més nou en una etapa de normalització diferent.

DID Core no requereix una cadena de blocs, no prova la identitat legal d'una persona, no emmagatzema credencials dins de cada document DID, ni fa que cada punt final resolt sigui fiable. Estandarditza l'arquitectura d'identificadors i documents. Un mètode DID separat defineix com es crea, llegeix, actualitza i desactiva un DID particular en la seva infraestructura escollida.

Punts clau

• Un DID és un URI, no una credencial. La seva forma genèrica és did:<method-name>:<method-specific-id>.
• Subjecte i controlador són rols diferents. El subjecte és el que identifica el DID; el controlador està autoritzat pel mètode per canviar el document DID.
• Les claus necessiten propòsits explícits. Un mètode de verificació esdevé utilitzable per a autenticació, asserció, acord de clau, invocació de capacitat o delegació només a través de la relació de verificació corresponent.
• El mètode proporciona les regles operatives. DID Core és tecnològicament neutre; el mètode defineix la interacció del registre, l'autorització, l'actualització, la desactivació i la resolució específica del mètode.
• La resolució no crea confiança per si mateixa. Els implementadors han d'autenticar els resultats del mètode, fer complir el propòsit de la prova, gestionar les claus i l'historial, protegir la privacitat i aplicar la política de l'aplicació.

Què és un identificador descentralitzat?

Un identificador descentralitzat és un identificador dissenyat perquè el control es pugui establir sense requerir que un proveïdor d'identitat central o una autoritat de certificació emeti i mantingui cada identificador. La paraula “descentralitzat” descriu la capacitat de l'arquitectura per separar el control de l'identificador d'un únic emissor central; no vol dir que cada implementació sigui anònima, pública, immutable o emmagatzemada en un registre distribuït.

Un DID pot identificar:

• una persona;
• una organització o grup;
• un dispositiu o objecte físic;
• un recurs digital;
• un model de dades;
• un concepte abstracte.

L'entitat identificada és el subjecte DID. La cadena sola no revela el tipus de subjecte.

Sintaxi DID

La sintaxi genèrica és:

did:<method-name>:<method-specific-id>

Per exemple:

did:example:123456789abcdefghi

did és l'esquema URI. example és el nom del mètode DID. La cadena restant és l'identificador específic del mètode. L'especificació del mètode defineix què significa aquest valor i com el processa el programari.

Un DID d'aparença vàlida no és necessàriament utilitzable. El mètode ha d'existir i el resolutor ha de ser compatible amb ell.

URL DID: rutes, consultes i fragments

Un URL DID comença amb un DID i pot afegir una ruta, una consulta o un fragment:

did:example:123456789abcdefghi/path?service=messages#key-1

Aquests components poden identificar o ajudar a seleccionar:

• un mètode de verificació dins del document DID;
• una entrada de servei;
• un altre fragment de document DID;
• un recurs al qual s'accedeix a través d'un servei;
• una versió o opció definida pel mètode.

El fragment #key-1 sol identificar un mètode de verificació. No significa que la clau privada estigui al document. Els documents DID publiquen material de verificació pública o referències; el material secret ha de romandre protegit en un altre lloc.

L'arquitectura DID

Els conceptes principals estan relacionats, però no són intercanviables:

Concepte	Rol
DID	Identificador globalment únic que compleix la sintaxi DID
Subjecte DID	Persona, organització, cosa, recurs o concepte identificat
Controlador DID	Entitat autoritzada sota el mètode DID per canviar el document DID
Document DID	Dades associades al subjecte, incloent mètodes de verificació i serveis permesos
Mètode DID	Especificació separada per a la sintaxi i operacions específiques del mètode
Registre de dades verificables	Infraestructura que un mètode utilitza per crear, llegir, actualitzar o desactivar l'estat DID
Resolutor DID	Programari o maquinari que realitza la resolució DID per als mètodes compatibles
Desreferenciador d'URL DID	Programari o maquinari que obté un recurs identificat per un URL DID

Subjecte vs. controlador

El subjecte i el controlador poden ser la mateixa entitat, però no han de ser-ho. Un pare podria controlar un DID per a un fill, una organització podria controlar un DID per a un dispositiu, o diversos fideïcomissaris podrien controlar un acord de recuperació.

El controller de nivell superior identifica un o més controladors DID. El controller requerit d'un mètode de verificació identifica qui controla aquest mètode; no és automàticament el controlador DID de nivell superior. Confondre'ls pot atorgar una autoritat no desitjada.

Què és un document DID?

Un document DID són les dades associades a un subjecte DID sota el model de dades DID Core. El seu id arrel és el DID. Les propietats bàsiques opcionals poden descriure controladors, identificadors alternatius, mètodes de verificació, relacions de verificació i serveis.

Aquest exemple simplificat utilitza material públic de l'espai d'exemple de l'especificació:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example està reservat per a exemples; els sistemes de producció han d'utilitzar un mètode real i els requisits actuals del seu paquet de mètodes de verificació. El JSON anterior és intencionadament JSON vàlid. Molts exemples impresos dins d'especificacions tècniques contenen comentaris o el·lipsis per a la llegibilitat i no s'han de copiar directament en un analitzador.

Propietats bàsiques

• id: el DID per al subjecte; obligatori a l'arrel del document.
• controller: un o més DIDs autoritzats per fer canvis sota el mètode.
• alsoKnownAs: altres URIs que s'afirmen que identifiquen el mateix subjecte.
• verificationMethod: mecanismes de verificació pública que poden ser referenciats per relacions explícites.
• authentication: mètodes autoritzats per a l'autenticació com a subjecte.
• assertionMethod: mètodes autoritzats per expressar afirmacions, com ara l'emissió de credencials.
• keyAgreement: mètodes destinats a derivar material secret compartit.
• capabilityInvocation: mètodes autoritzats per invocar capacitats.
• capabilityDelegation: mètodes autoritzats per delegar capacitats.
• service: punts finals o mecanismes d'interacció associats al subjecte.

alsoKnownAs és una afirmació, no una prova criptogràfica que dos identificadors siguin equivalents. Les aplicacions haurien de verificar independentment la relació requerida pel seu model de confiança.

Model de dades i representacions

DID Core defineix un model de dades abstracte i regles per produir i consumir representacions. El model de dades no és idèntic a una serialització JSON.

Els requisits de representació són específics de la versió:

• La Recomanació DID Core 1.0 de 2022 defineix application/did+json i application/did+ld+json. La seva representació JSON-LD comença amb el context base https://www.w3.org/ns/did/v1.
• La Candidate Recommendation DID Core 1.1 consolida el tipus de mitjà principal a application/did. La seva representació JSON-LD comença amb https://www.w3.org/ns/did/v1.1.

No barregeu el tipus de mitjà o el context base d'una versió amb afirmacions de conformitat amb l'altra. Fixeu la versió de l'especificació que implementen els productors i consumidors.

Els implementadors haurien de negociar i validar la representació explícitament. Signar bytes JSON serialitzats arbitraris sense una canonicalització definida i un mecanisme de seguretat no és equivalent a processar el model de dades DID correctament.

Mètodes de verificació i relacions de verificació

Un mètode de verificació descriu com es pot comprovar una prova. Requereix:

• un id expressat com a URL DID;
• un type;
• un controller;
• material de verificació adequat a aquest tipus.

El material públic es pot representar mitjançant una propietat definida com publicKeyJwk o una altra forma permesa pel paquet de mètodes de verificació. Un JWK en un document DID no ha d'incloure material de clau privada. El mateix material de verificació no s'ha de duplicar en diverses propietats de material dins d'un mètode.

Definir un mètode de verificació no l'autoritza per a tots els propòsits. L'autorització prové de les cinc relacions de verificació explícites.

Relació	Propòsit de prova previst
authentication	Autenticar-se com a subjecte DID mitjançant resposta a un repte o un altre mecanisme acceptat
assertionMethod	Expressar afirmacions, incloent la signatura d'una Credencial Verificable on el mecanisme de seguretat escollit la utilitza
keyAgreement	Establir material criptogràfic compartit, sovint per a l'encriptació
capabilityInvocation	Invocar una capacitat d'objecte
capabilityDelegation	Delegar una capacitat d'objecte

Un verificador ha de comprovar la relació requerida per a la prova. Una clau llistada només sota authentication no està automàticament autoritzada per a assercions de credencials o acord de clau.

Les relacions poden incrustar un mètode de verificació complet o referenciar-ne un per URL DID. Les referències milloren la reutilització, però requereixen una desreferenciació correcta i una comparació exacta d'identificadors.

Serveis i punts finals de servei

La propietat opcional service pot anunciar maneres de comunicar-se o interactuar amb el subjecte DID. Cada entrada de servei té:

• un id únic;
• un type;
• un serviceEndpoint.

El punt final pot ser un URI o una altra estructura permesa. Les definicions de servei són extensibles, per la qual cosa les aplicacions han d'entendre el tipus escollit.

Publicar un punt final no prova que el seu servidor, operador, transport, contingut o destinació siguin fiables.

L'aplicació ha d'autenticar l'estat DID resolt mitjançant el mètode, validar el tipus de servei, aplicar controls de seguretat d'URL i de xarxa, i utilitzar un protocol d'aplicació amb les seves pròpies propietats de seguretat.

Els punts finals de servei públics també poden crear correlació. Reutilitzar un punt final en DIDs per parelles pot anul·lar el benefici de privacitat dels identificadors separats.

Què defineix un mètode DID

DID Core proporciona l'arquitectura comuna. Un mètode DID conforme defineix les regles específiques del mètode necessàries per implementar-lo, incloent:

• nom del mètode i sintaxi d'identificador específic del mètode;
• com es creen un DID i el document DID inicial;
• com es llegeix l'estat actual;
• com es presenten i verifiquen les actualitzacions autoritzades;
• com es desactiva un DID;
• com la resolució es comunica amb el registre;
• com s'estableix l'autenticitat i la integritat dels resultats;
• com funcionen la rotació de claus, la recuperació, el versionat i l'historial;
• consideracions de seguretat i privacitat específiques del mètode.

El registre de dades verificables podria ser un registre distribuït, un sistema de fitxers descentralitzat, una xarxa peer-to-peer, una base de dades o un altre sistema. L'arquitectura s'ha d'avaluar en funció de la governança, la disponibilitat, l'autorització, la privacitat, el cost, l'historial i la resistència als atacs, més que per la paraula “descentralitzat”.

Criteris de selecció del mètode

Abans de seleccionar un mètode, proveu:

• maduresa i governança de l'especificació;
• interoperabilitat de resolutors i biblioteques;
• autorització d'actualització i desactivació;
• rotació i recuperació de claus;
• suport d'estat històric;
• privacitat i fuga de metadades;
• disponibilitat del registre i risc de censura;
• costos de transacció o operació;
• agilitat criptogràfica;
• migració i fallada del mètode.

Canviar de mètode sol implicar introduir un nou identificador i una ruta de migració fiable.

Resolució DID vs. desreferenciació d'URL DID

La resolució DID pren un DID i opcions de resolució i retorna:

1. metadades de resolució DID;
2. un document DID, un flux de documents o cap document;
3. metadades del document DID.

El resolutor utilitza l'operació de “lectura” definida pel mètode. DID Core defineix interfícies abstractes i conceptes de resultats comuns; la comunicació i autenticació específiques del mètode romanen amb el mètode.

La desreferenciació d'URL DID pren un URL DID complet i retorna:

1. metadades de desreferenciació;
2. el recurs identificat, si està disponible;
3. metadades de contingut.

La desreferenciació pot resoldre primer el DID base i després seleccionar un fragment, servei o recurs extern. No és un sinònim de resolució.

L'especificació separada W3C DID Resolution desenvolupa algorismes detallats de resolució i desreferenciació. La seva última publicació és un W3C Working Draft del 24 de juliol de 2026, i la desreferenciació d'URL DID està marcada com una característica en risc. Continua sent un treball en curs de normalització en lloc de formar part de la Recomanació DID Core 1.0 de 2022, així que fixeu l'esborrany abans d'afirmar la conformitat.

Confiança i memòria cau del resolutor

Un resolutor és un límit de seguretat i privacitat. Veu els identificadors sol·licitats i pot retornar un estat antic o manipulat. Avalueu:

• verificació del resultat del mètode;
• transport i autenticació del resolutor;
• frescor i invalidació de la memòria cau;
• opcions de versió i temps;
• gestió d'errors i comportament de degradació;
• fuga de privacitat mitjançant consultes;
• comportament durant la fallada del registre o de la xarxa.

DIDs i Credencials Verificables

Els DIDs i les Credencials Verificables són especificacions complementàries, no el mateix objecte.

Un DID base pot identificar:

• un emissor de credencials;
• un subjecte de credencials;
• un titular.

Un mètode de verificació utilitzat per un mecanisme de seguretat s'identifica en canvi mitjançant un URL DID, normalment un DID seguit d'un fragment com #key-1.

El W3C Verifiable Credentials Data Model 2.0 defineix credencials, presentacions, emissor, titular, subjecte, validesa, estat, esquemes i mecanismes de seguretat. No requereix que cada identificador sigui un DID.

Quan s'utilitza un DID per a un emissor, un verificador podria resoldre el DID de l'emissor, localitzar el mètode de verificació de la prova i confirmar que el mètode està autoritzat sota assertionMethod. Aquesta verificació criptogràfica encara no estableix:

• que cada afirmació de credencial sigui certa;
• que l'emissor sigui de confiança per a aquesta afirmació;
• que la credencial sigui actual o acceptable;
• que el seu estat, esquema o evidència compleixi la política;
• que el subjecte de la credencial sigui la persona que la presenta.

Aquestes comprovacions pertanyen al mecanisme de seguretat, al sistema d'estat, al marc de confiança, a l'enllaç de presentació i a la política del verificador.

Consideracions de privacitat i seguretat

Eviteu les dades personals en documents públics

Els documents DID es poden replicar àmpliament. No publiqueu noms, identificadors governamentals, dades biomètriques, credencials o altres dades personals simplement perquè el model és extensible. L'encriptació no és una resposta duradora per a text xifrat permanentment públic.

Eviteu la correlació

Els DIDs per parelles o específics del context només poden reduir la correlació si altres dades també estan separades. Les claus reutilitzades, els punts finals de servei, els identificadors de xarxa, els atributs de credencials, la temporització i l'activitat del registre poden vincular DIDs suposadament separats.

Gireu i recupereu les claus

Planifiqueu el compromís abans del llançament. Definiu l'autorització d'actualització, els controladors de recuperació, les regles de llindar, la rotació, la gestió de claus antigues i la desactivació. L'autoritat de recuperació necessita separació i auditoria.

Valideu el propòsit de la prova

Comproveu no només que una signatura es verifica, sinó que el mètode de verificació estava autoritzat per a la relació requerida en el moment pertinent. Eviteu la substitució entre usos d'autenticació, asserció, acord i capacitat.

Gestioneu l'historial amb cura

Un document DID actual pot ja no contenir una clau antiga. Verificar una prova històrica pot requerir una versió històrica compatible amb el mètode i evidència fiable del temps de la prova. “Clau no present ara” i “la prova mai va ser vàlida” no són conclusions equivalents.

Errors comuns en la implementació de DID

Anomenar DID Core una especificació de cadena de blocs

DID Core és tecnològicament neutre. Les cadenes de blocs són una possible arquitectura de registre.

Tractar el DID com a prova d'identitat legal

Un DID admet el control d'identificadors i la verificació criptogràfica. La vinculació d'identitat del món real necessita evidència separada, afirmacions de l'emissor o un marc de confiança.

Utilitzar qualsevol clau llistada per a qualsevol propòsit

Feu complir la relació de verificació explícita i el propòsit de la prova.

Confiar automàticament en els punts finals del servei

Valideu l'estat del mètode i apliqueu la seguretat de l'aplicació, el transport, l'URL i el contingut.

Assumir que tots els DIDs són privats o anònims

L'activitat del registre, la resolució, el material reutilitzat i els serveis poden exposar una correlació duradora.

Una llista de comprovació per a la implementació

Abans de la producció, confirmeu que:

• la versió DID Core seleccionada i les especificacions del mètode DID estan fixades;
• l'anàlisi d'identificadors i URL DID utilitza un maneig d'URI compatible amb els estàndards;
• les representacions i els tipus de mitjans acceptats són explícits;
• cada prova fa complir la relació de verificació prevista;
• els resultats del mètode s'autentiquen en lloc de confiar en qualsevol resolutor;
• la memòria cau, el versionat, la verificació històrica i la desactivació estan provats;
• l'actualització, la rotació, el compromís, la recuperació i la migració tenen procediments assajats;
• els documents públics no contenen dades personals o correlacionades innecessàries;
• els punts finals del servei reben una revisió de seguretat de la capa d'aplicació separada;
• la confiança, l'estat, l'esquema i les comprovacions de presentació de les Credencials Verificables romanen separades.

On els DIDs es troben amb la verificació d'identitat

Els DIDs poden identificar subjectes i material de verificació, però no realitzen la prova d'identitat. Un sistema d'identitat reutilitzable encara necessita evidència fiable i una decisió governada abans d'emetre o acceptar afirmacions. La Verificació d'Identitat de Didit pot proporcionar evidència d'identitat per a aquesta decisió, mentre que Reusable KYC admet la reutilització d'una verificació prèvia en serveis participants i es llista gratuïtament.

Aquesta proximitat de productes no implica que cada verificació de Didit sigui un DID o que la resolució DID substitueixi el KYC. Les tarifes actuals dels mòduls estan disponibles a la pàgina de preus. L'arquitectura ha de mantenir el control de l'identificador, l'evidència d'identitat, l'emissió de credencials, la presentació i la política de la part dependent com a límits de confiança separats.

Preguntes freqüents

Què defineix l'especificació W3C DID?

Defineix la sintaxi DID i URL DID, un model de dades comú, propietats bàsiques del document DID, representacions, requisits de mètodes i interfícies abstractes de resolució i desreferenciació.

Cada DID utilitza una cadena de blocs?

No. Un mètode DID pot utilitzar un registre, una base de dades, un sistema peer-to-peer, un sistema de fitxers descentralitzat o una altra arquitectura de registre.

Quina diferència hi ha entre un DID i un document DID?

El DID és l'identificador. El document DID són dades associades que poden descriure controladors, mètodes de verificació i els seus propòsits, serveis i altres propietats definides.

Quina diferència hi ha entre resolució i desreferenciació?

La resolució obté un document DID i metadades per a un DID. La desreferenciació obté el recurs identificat per un URL DID complet, potencialment després de resoldre el seu DID base.

És un DID el mateix que una Credencial Verificable?

No. Un DID és un identificador. Una Credencial Verificable és un conjunt d'afirmacions a prova de manipulacions i verificables per màquina segons el model de dades VC i un mecanisme de seguretat. Els VCs poden utilitzar DIDs però no els requereixen universalment.

Controlar un DID prova qui és una persona?

No. Pot provar el control d'autoritat criptogràfica o específica del mètode associada al DID. Vincular aquest control a una identitat legal o del món real requereix evidència addicional o afirmacions de confiança.

Un document DID pot contenir claus privades?

No. Els documents DID contenen material de verificació pública o referències. El material de clau privada no ha d'aparèixer i ha de romandre protegit pel sistema de gestió de claus del controlador.

Referències principals

• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Decentralized Identifiers (DIDs) v1.1
• W3C Decentralized Identifier Resolution
• W3C DID Specification Registries
• W3C Verifiable Credentials Data Model v2.0

DID Core és més útil quan la seva afirmació és precisa. Estandarditza identificadors, documents, propòsits de verificació, serveis i interfícies de mètodes. La confiança encara prové de la governança del mètode, la resolució autenticada, les claus protegides, el propòsit explícit de la prova, el disseny conscient de la privacitat i la decisió de l'aplicació sobre quina evidència acceptar.