Especificación de Identificadores Descentralizados (DIDs) del W3C (ES)

La especificación de Identificadores Descentralizados (DIDs) del W3C define una sintaxis URI, un modelo de datos común, documentos DID, propiedades centrales, representaciones, requisitos de método e interfaces abstractas para la resolución y desreferenciación de URL DID. DID Core 1.0 se convirtió en una Recomendación del W3C el 19 de julio de 2022. DID Core 1.1 se publicó como un Snapshot de Recomendación Candidata el 5 de marzo de 2026; es un trabajo más reciente en una etapa de estándares diferente.

DID Core no requiere una cadena de bloques, prueba la identidad legal de una persona, almacena credenciales dentro de cada documento DID, ni hace que cada punto final resuelto sea confiable. Estandariza la arquitectura del identificador y del documento. Un método DID separado define cómo se crea, lee, actualiza y desactiva un DID particular en la infraestructura elegida.

Conclusiones clave

• Un DID es una URI, no una credencial. Su forma genérica es did:<method-name>:<method-specific-id>.
• El sujeto y el controlador son roles diferentes. El sujeto es lo que identifica el DID; el controlador está autorizado por el método para cambiar el documento DID.
• Las claves necesitan propósitos explícitos. Un método de verificación se vuelve utilizable para autenticación, aserción, acuerdo de clave, invocación de capacidad o delegación solo a través de la relación de verificación correspondiente.
• El método proporciona las reglas operativas. DID Core es tecnológicamente neutral; el método define la interacción del registro, la autorización, la actualización, la desactivación y la resolución específica del método.
• La resolución no crea confianza por sí misma. Los implementadores deben autenticar los resultados del método, hacer cumplir el propósito de la prueba, gestionar claves e historial, proteger la privacidad y aplicar la política de la aplicación.

¿Qué es un identificador descentralizado?

Un identificador descentralizado es un identificador diseñado para que el control pueda establecerse sin requerir que un proveedor de identidad central o una autoridad de certificación emita y mantenga cada identificador. La palabra “descentralizado” describe la capacidad de la arquitectura para separar el control del identificador de un único emisor central; no significa que cada implementación sea anónima, pública, inmutable o almacenada en un libro mayor distribuido.

Un DID puede identificar:

• una persona;
• una organización o grupo;
• un dispositivo u objeto físico;
• un recurso digital;
• un modelo de datos;
• un concepto abstracto.

La entidad identificada es el sujeto DID. La cadena por sí sola no revela el tipo de sujeto.

Sintaxis DID

La sintaxis genérica es:

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

Por ejemplo:

did:example:123456789abcdefghi

did es el esquema URI. example es el nombre del método DID. La cadena restante es el identificador específico del método. La especificación del método define lo que significa ese valor y cómo lo procesa el software.

Un DID que parece válido no es necesariamente utilizable. El método debe existir y el resolvedor debe admitirlo.

URL DID: rutas, consultas y fragmentos

Una URL DID comienza con un DID y puede añadir una ruta, consulta o fragmento:

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

Estos componentes pueden identificar o ayudar a seleccionar:

• un método de verificación dentro del documento DID;
• una entrada de servicio;
• otro fragmento de documento DID;
• un recurso alcanzado a través de un servicio;
• una versión o una opción definida por el método.

El fragmento #key-1 comúnmente identifica un método de verificación. No significa que la clave privada esté en el documento. Los documentos DID publican material de verificación público o referencias; el material secreto debe permanecer protegido en otro lugar.

La arquitectura DID

Los conceptos principales están relacionados pero no son intercambiables:

Concepto	Rol
DID	Identificador globalmente único que cumple con la sintaxis DID
Sujeto DID	Persona, organización, cosa, recurso o concepto identificado
Controlador DID	Entidad autorizada bajo el método DID para cambiar el documento DID
Documento DID	Datos asociados con el sujeto, incluidos los métodos de verificación y servicios permitidos
Método DID	Especificación separada para la sintaxis y operaciones específicas del método
Registro de datos verificables	Infraestructura que un método utiliza para crear, leer, actualizar o desactivar el estado DID
Resolvedor DID	Software o hardware que realiza la resolución DID para los métodos admitidos
Desreferenciador de URL DID	Software o hardware que obtiene un recurso identificado por una URL DID

Sujeto versus controlador

El sujeto y el controlador pueden ser la misma entidad, pero no tienen por qué serlo. Un padre podría controlar un DID para un hijo, una organización podría controlar un DID para un dispositivo, o varios fideicomisarios podrían controlar un acuerdo de recuperación.

El controller de nivel superior identifica uno o más controladores DID. El controller requerido de un método de verificación identifica quién controla ese método; no es automáticamente el controlador DID de nivel superior. Confundirlos puede otorgar una autoridad no deseada.

¿Qué es un documento DID?

Un documento DID son los datos asociados con un sujeto DID bajo el modelo de datos DID Core. Su id raíz es el DID. Las propiedades centrales opcionales pueden describir controladores, identificadores alternativos, métodos de verificación, relaciones de verificación y servicios.

Este ejemplo simplificado utiliza material público del espacio de ejemplo de la especificación:

{
  "@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á reservado para ejemplos; los sistemas de producción deben usar un método real y sus requisitos actuales de suite de métodos de verificación. El JSON anterior es intencionalmente JSON válido. Muchos ejemplos impresos dentro de especificaciones técnicas contienen comentarios o elipses para facilitar la lectura y no deben copiarse directamente en un analizador.

Propiedades centrales

• id: el DID para el sujeto; requerido en la raíz del documento.
• controller: uno o más DIDs autorizados para realizar cambios bajo el método.
• alsoKnownAs: otras URIs que se afirma que identifican al mismo sujeto.
• verificationMethod: mecanismos de verificación públicos que pueden ser referenciados por relaciones explícitas.
• authentication: métodos autorizados para la autenticación como sujeto.
• assertionMethod: métodos autorizados para expresar afirmaciones, como la emisión de credenciales.
• keyAgreement: métodos destinados a derivar material secreto compartido.
• capabilityInvocation: métodos autorizados para invocar capacidades.
• capabilityDelegation: métodos autorizados para delegar capacidades.
• service: puntos finales o mecanismos de interacción asociados con el sujeto.

alsoKnownAs es una afirmación, no una prueba criptográfica de que dos identificadores son equivalentes. Las aplicaciones deben verificar independientemente la relación requerida por su modelo de confianza.

Modelo de datos y representaciones

DID Core define un modelo de datos abstracto y reglas para producir y consumir representaciones. El modelo de datos no es idéntico a una serialización JSON.

Los requisitos de representación son específicos de la versión:

• La Recomendación DID Core 1.0 de 2022 define application/did+json y application/did+ld+json. Su representación JSON-LD comienza con el contexto base https://www.w3.org/ns/did/v1.
• La Recomendación Candidata DID Core 1.1 consolida el tipo de medio principal en application/did. Su representación JSON-LD comienza con https://www.w3.org/ns/did/v1.1.

No mezcle el tipo de medio o el contexto base de una versión con las afirmaciones de conformidad con la otra. Fije la versión de la especificación que implementan los productores y consumidores.

Los implementadores deben negociar y validar la representación explícitamente. Firmar bytes JSON serializados arbitrarios sin una canonicalización definida y un mecanismo de seguridad no es equivalente a procesar el modelo de datos DID correctamente.

Métodos de verificación y relaciones de verificación

Un método de verificación describe cómo se puede verificar una prueba. Requiere:

• un id expresado como una URL DID;
• un type;
• un controller;
• material de verificación apropiado para ese tipo.

El material público puede representarse a través de una propiedad definida como publicKeyJwk u otra forma permitida por la suite de métodos de verificación. Un JWK en un documento DID no debe incluir material de clave privada. El mismo material de verificación no debe duplicarse en múltiples propiedades de material dentro de un método.

Definir un método de verificación no lo autoriza para todos los propósitos. La autorización proviene de las cinco relaciones de verificación explícitas.

Relación	Propósito de prueba previsto
authentication	Autenticarse como sujeto DID a través de un desafío-respuesta u otro mecanismo aceptado
assertionMethod	Expresar afirmaciones, incluyendo la firma de una Credencial Verificable donde el mecanismo de seguridad elegido la utiliza
keyAgreement	Establecer material criptográfico compartido, a menudo para cifrado
capabilityInvocation	Invocar una capacidad de objeto
capabilityDelegation	Delegar una capacidad de objeto

Un verificador debe comprobar la relación requerida para la prueba. Una clave listada solo bajo authentication no está automáticamente autorizada para aserciones de credenciales o acuerdo de clave.

Las relaciones pueden incrustar un método de verificación completo o hacer referencia a uno por URL DID. Las referencias mejoran la reutilización, pero requieren una desreferenciación correcta y una comparación de identificadores exacta.

Servicios y puntos finales de servicio

La propiedad opcional service puede anunciar formas de comunicarse o interactuar con el sujeto DID. Cada entrada de servicio tiene:

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

El punto final puede ser una URI u otra estructura permitida. Las definiciones de servicio son extensibles, por lo que las aplicaciones deben comprender el tipo elegido.

Publicar un punto final no prueba que su servidor, operador, transporte, contenido o destino sea confiable.

La aplicación debe autenticar el estado DID resuelto a través del método, validar el tipo de servicio, aplicar controles de seguridad de URL y red, y usar un protocolo de aplicación con sus propias propiedades de seguridad.

Los puntos finales de servicio públicos también pueden crear correlación. Reutilizar un punto final en DIDs pareados puede anular el beneficio de privacidad de los identificadores separados.

Lo que define un método DID

DID Core proporciona la arquitectura común. Un método DID conforme define las reglas específicas del método necesarias para implementarlo, incluyendo:

• nombre del método y sintaxis del identificador específico del método;
• cómo se crean un DID y un documento DID inicial;
• cómo se lee el estado actual;
• cómo se envían y verifican las actualizaciones autorizadas;
• cómo se desactiva un DID;
• cómo la resolución se comunica con el registro;
• cómo se establece la autenticidad e integridad de los resultados;
• cómo funcionan la rotación de claves, la recuperación, el versionado y el historial;
• consideraciones de seguridad y privacidad específicas del método.

El registro de datos verificables podría ser un libro mayor distribuido, un sistema de archivos descentralizado, una red peer-to-peer, una base de datos u otro sistema. La arquitectura debe evaluarse en función de la gobernanza, la disponibilidad, la autorización, la privacidad, el costo, el historial y la resistencia a los ataques, en lugar de la palabra “descentralizado”.

Criterios de selección de métodos

Antes de seleccionar un método, pruebe:

• madurez y gobernanza de la especificación;
• interoperabilidad del resolvedor y la biblioteca;
• autorización de actualización y desactivación;
• rotación y recuperación de claves;
• soporte de estado histórico;
• privacidad y fuga de metadatos;
• disponibilidad del registro y riesgo de censura;
• costos de transacción u operativos;
• agilidad criptográfica;
• migración y falla del método.

Cambiar de método generalmente significa introducir un nuevo identificador y una ruta de migración confiable.

Resolución DID versus desreferenciación de URL DID

La resolución DID toma un DID y opciones de resolución y devuelve:

1. metadatos de resolución DID;
2. un documento DID, un flujo de documentos o ningún documento;
3. metadatos del documento DID.

El resolvedor utiliza la operación de “lectura” definida por el método. DID Core define interfaces abstractas y conceptos de resultados comunes; la comunicación y autenticación específicas del método permanecen con el método.

La desreferenciación de URL DID toma una URL DID completa y devuelve:

1. metadatos de desreferenciación;
2. el recurso identificado, si está disponible;
3. metadatos de contenido.

La desreferenciación puede primero resolver el DID base y luego seleccionar un fragmento, servicio o recurso externo. No es un sinónimo de resolución.

La especificación W3C DID Resolution separada desarrolla algoritmos detallados de resolución y desreferenciación. Su última publicación es un Borrador de Trabajo del W3C con fecha del 24 de julio de 2026, y la desreferenciación de URL DID está marcada como una característica en riesgo. Sigue siendo un trabajo en curso en la vía de estandarización en lugar de parte de la Recomendación DID Core 1.0 de 2022, así que fije el borrador antes de reclamar conformidad.

Confianza y almacenamiento en caché del resolvedor

Un resolvedor es un límite de seguridad y privacidad. Ve los identificadores solicitados y puede devolver un estado obsoleto o manipulado. Evalúe:

• verificación de resultados del método;
• autenticación de transporte y resolvedor;
• frescura e invalidación de la caché;
• opciones de versión y tiempo;
• manejo de errores y comportamiento de degradación;
• fuga de privacidad a través de búsquedas;
• comportamiento durante fallas de registro o red.

DIDs y Credenciales Verificables

Los DIDs y las Credenciales Verificables son especificaciones complementarias, no el mismo objeto.

Un DID base puede identificar:

• un emisor de credenciales;
• un sujeto de credenciales;
• un titular.

Un método de verificación utilizado por un mecanismo de seguridad se identifica en su lugar por una URL DID, comúnmente un DID seguido de un fragmento como #key-1.

El Modelo de Datos de Credenciales Verificables 2.0 del W3C define credenciales, presentaciones, emisor, titular, sujeto, validez, estado, esquemas y mecanismos de seguridad. No requiere que cada identificador sea un DID.

Cuando se utiliza un DID para un emisor, un verificador podría resolver el DID del emisor, localizar el método de verificación de la prueba y confirmar que el método está autorizado bajo assertionMethod. Esa verificación criptográfica todavía no establece:

• que cada afirmación de la credencial sea verdadera;
• que el emisor sea confiable para esa afirmación;
• que la credencial sea actual o aceptable;
• que su estado, esquema o evidencia cumpla con la política;
• que el sujeto de la credencial sea la persona que la presenta.

Esas comprobaciones pertenecen al mecanismo de seguridad, sistema de estado, marco de confianza, vinculación de presentación y política del verificador.

Consideraciones de privacidad y seguridad

Evite los datos personales en documentos públicos

Los documentos DID pueden replicarse ampliamente. No publique nombres, identificadores gubernamentales, datos biométricos, credenciales u otros datos personales simplemente porque el modelo es extensible. El cifrado no es una respuesta duradera para un texto cifrado permanentemente público.

Prevenir la correlación

Los DIDs emparejados o específicos del contexto pueden reducir la correlación solo si también se separan otros datos. Las claves reutilizadas, los puntos finales de servicio, los identificadores de red, los atributos de credenciales, la temporización y la actividad del registro pueden vincular DIDs supuestamente separados.

Rotar y recuperar claves

Planifique el compromiso antes del lanzamiento. Defina la autorización de actualización, los controladores de recuperación, las reglas de umbral, la rotación, el manejo de claves antiguas y la desactivación. La autoridad de recuperación necesita separación y auditoría.

Validar el propósito de la prueba

Verifique no solo que una firma se verifica, sino que el método de verificación estaba autorizado para la relación requerida en el momento relevante. Evite la sustitución entre usos de autenticación, aserción, acuerdo y capacidad.

Manejar el historial con cuidado

Un documento DID actual puede ya no contener una clave antigua. Verificar una prueba histórica puede requerir una versión histórica compatible con el método y evidencia confiable del momento de la prueba. “Clave no presente ahora” y “la prueba nunca fue válida” no son conclusiones equivalentes.

Errores comunes de implementación de DID

Llamar a DID Core una especificación de blockchain

DID Core es tecnológicamente neutral. Las cadenas de bloques son una posible arquitectura de registro.

Tratar el DID como prueba de identidad legal

Un DID admite el control de identificadores y la verificación criptográfica. La vinculación de la identidad del mundo real necesita evidencia separada, aserciones del emisor o un marco de confianza.

Usar cualquier clave listada para cualquier propósito

Haga cumplir la relación de verificación explícita y el propósito de la prueba.

Confiar en los puntos finales de servicio automáticamente

Valide el estado del método y aplique la seguridad de la aplicación, el transporte, la URL y el contenido.

Asumir que todos los DIDs son privados o anónimos

La actividad del registro, la resolución, el material reutilizado y los servicios pueden exponer una correlación duradera.

Una lista de verificación de implementación

Antes de la producción, confirme que:

• las versiones seleccionadas de DID Core y las especificaciones del método DID están fijadas;
• el análisis de identificadores y URL DID utiliza un manejo de URI conforme a los estándares;
• las representaciones y tipos de medios aceptados son explícitos;
• cada prueba hace cumplir la relación de verificación prevista;
• los resultados del método se autentican en lugar de confiar en cualquier resolvedor;
• el almacenamiento en caché, el versionado, la verificación histórica y la desactivación están probados;
• la actualización, rotación, compromiso, recuperación y migración tienen procedimientos ensayados;
• los documentos públicos no contienen datos personales o correlacionados innecesarios;
• los puntos finales de servicio reciben una revisión de seguridad de la capa de aplicación separada;
• las comprobaciones de confianza, estado, esquema y presentación de las Credenciales Verificables permanecen separadas.

Donde los DIDs se encuentran con la verificación de identidad

Los DIDs pueden identificar sujetos y material de verificación, pero no realizan la comprobación de identidad. Un sistema de identidad reutilizable aún necesita evidencia confiable y una decisión gobernada antes de emitir o aceptar afirmaciones. La Verificación de ID de Didit puede proporcionar evidencia de identidad para tal decisión, mientras que Reusable KYC admite la reutilización de una verificación previa en servicios participantes y se ofrece de forma gratuita.

Esa adyacencia de productos no implica que cada verificación de Didit sea un DID o que la resolución de DID reemplace el KYC. Las tarifas actuales de los módulos están disponibles en la página de precios. La arquitectura debe mantener el control del identificador, la evidencia de identidad, la emisión de credenciales, la presentación y la política de la parte confiable como límites de confianza separados.

Preguntas frecuentes

¿Qué define la especificación DID del W3C?

Define la sintaxis de DID y URL DID, un modelo de datos común, propiedades principales del documento DID, representaciones, requisitos de método e interfaces abstractas de resolución y desreferenciación.

¿Cada DID utiliza una cadena de bloques?

No. Un método DID puede usar un libro mayor, una base de datos, un sistema peer-to-peer, un sistema de archivos descentralizado u otra arquitectura de registro.

¿Cuál es la diferencia entre un DID y un documento DID?

El DID es el identificador. El documento DID son los datos asociados que pueden describir controladores, métodos de verificación y sus propósitos, servicios y otras propiedades definidas.

¿Cuál es la diferencia entre resolución y desreferenciación?

La resolución obtiene un documento DID y metadatos para un DID. La desreferenciación obtiene el recurso identificado por una URL DID completa, potencialmente después de resolver su DID base.

¿Es un DID lo mismo que una Credencial Verificable?

No. Un DID es un identificador. Una Credencial Verificable es un conjunto de afirmaciones a prueba de manipulaciones y verificable por máquina bajo el modelo de datos de VC y un mecanismo de seguridad. Las VC pueden usar DIDs, pero no los requieren universalmente.

¿Controlar un DID prueba quién es una persona?

No. Puede probar el control de la autoridad criptográfica o específica del método asociada con el DID. La vinculación de ese control a una identidad legal o del mundo real requiere evidencia adicional o afirmaciones confiables.

¿Puede un documento DID contener claves privadas?

No. Los documentos DID contienen material de verificación público o referencias. El material de clave privada no debe aparecer y debe permanecer protegido por el sistema de gestión de claves del controlador.

Referencias principales

• Identificadores Descentralizados (DIDs) v1.0 del W3C
• Identificadores Descentralizados (DIDs) v1.1 del W3C
• Resolución de Identificadores Descentralizados del W3C
• Registros de Especificaciones DID del W3C
• Modelo de Datos de Credenciales Verificables v2.0 del W3C

DID Core es más útil cuando su afirmación se mantiene precisa. Estandariza identificadores, documentos, propósitos de verificación, servicios e interfaces de método. La confianza aún proviene de la gobernanza del método, la resolución autenticada, las claves protegidas, el propósito explícito de la prueba, el diseño consciente de la privacidad y la decisión de la aplicación sobre qué evidencia aceptar.