El formulario se ha enviado correctamente.
Encontrarás más información en tu bandeja de entrada.
ContrátanosSeleccionar idioma
Sobre nosotrosServiciosTecnologíasPortafolio
Seguramente lo has visto tú mismo: le das a GPT un selfie, le pides un documento tipo pasaporte y, en cuestión de minutos, obtienes algo que puede pasar los controles visuales básicos. Si añadimos la clonación de la voz y el vídeo sintético, la “viveza” empieza a parecer un teatro. Esa es la verdadera ruptura de la identidad digital en 2026. El propio modelo KYC basado en fotografías se está desgastando. Si la prueba de identidad sigue dependiendo de que las imágenes sean difíciles de falsificar, se está construyendo sobre arena.
¿Dónde nos deja esto? Con un cambio bastante obvio: dejar de almacenar datos de identidad y pasar a verificar las solicitudes criptográficamente. En lugar de recoger un pasaporte escaneado y almacenarlo en otra base de datos, el sistema pide una prueba: ¿tiene usted más de 18 años, ha superado el proceso KYC, está autorizado para realizar esta transacción? ¿puede demostrarlo sin revelar nada más?
Pero, ¿qué cambia exactamente? ¿Por qué de repente hablamos de DID y credenciales verificables?
Porque en un modelo basado en el DID, la confianza no viene de la apariencia de algo. Viene de quién lo firmó y de si puedes demostrar que lo controlas. Un selfie falso no sirve de nada si el verificador espera una credencial firmada por un emisor de confianza y vinculada a tus claves criptográficas. Ya no estás intentando “parecer real”. Estás demostrando la posesión de una declaración válida y firmada. Las imágenes dejan de ser la fuente de confianza. Las firmas toman el relevo.
Y ese es el objetivo de esta guía: Mostraré cómo funciona ese modelo, por qué se está convirtiendo en el camino serio a seguir y dónde encaja blockchain en él.
Un identificador descentralizado, o DID, es un identificador basado en URI diseñado para ser controlado mediante claves criptográficas en lugar de ser emitido y gestionado por un directorio central. Bajo el Consorcio World Wide Web (W3C) DID, un DID se resuelve en un documento DID que informa a otros sistemas sobre cómo verificar firmas, autenticar al controlador o descubrir puntos finales de servicio asociados a ese identificador. En pocas palabras: un DID no es su perfil, su pasaporte o su registro de cuenta. Es el puntero que utilizan otras partes para verificar que controlas un identificador específico y las claves que hay detrás de él.
Aquí es donde la gente suele aplanar todo en “sólo otro DNI”. No lo es.
Una dirección de correo electrónico es en realidad un localizador dentro del sistema de otra persona. Si el proveedor suspende la cuenta, el identificador desaparece. Un SSN es un identificador emitido por el estado, pero no tiene una capa de prueba criptográfica incorporada; cualquiera que obtenga el número puede reproducirlo. Los tokens OAuth también son diferentes: no son identificadores de identidad en absoluto, sino artefactos de acceso delegado emitidos por un servidor de autorización para que un cliente pueda llamar a un recurso protegido. Útiles, sí. Capa de identidad portátil, no.
Un DID funciona de otra manera. Se trata de resolverlo, no de buscarlo en una base de datos de proveedores. El control recae en el sujeto a través del material clave y las reglas del método DID, no en un proveedor de correo, una plataforma SaaS o un agente de identidad. Esta distinción es importante en la práctica. Si está creando credenciales reutilizables, un inicio de sesión basado en un monedero o flujos verificadores que deben funcionar más allá de los límites de la organización, un correo electrónico o un ID de usuario específico de una aplicación no transmitirán suficiente semántica de confianza. Un DID sí.
A nivel sintáctico, el modelo del W3C es sencillo: un DID consta de tres partes: el esquema DID, un nombre de método y un identificador específico de método. Dicho de otro modo: did:método:identificador.
Toma did:web:ejemplo.com como ejemplo concreto.
Con hizo:web, la resolución suele asignarse a un documento DID publicado en una ubicación HTTPS conocida de ese dominio. Con algo como did:ethr, la resolución depende de las reglas del método vinculado a Ethereum. Misma sintaxis DID, diferente modelo de confianza y actualización.
Ese es el punto clave: la propia cadena DID es sólo el asa. El método le indica cómo resolverlo. El documento DID le proporciona el material de verificación. Una vez que lo tengas, podrás verificar firmas, autenticar a un titular o validar la presentación de una credencial sin tratar el identificador como una fila más de la tabla de usuarios de alguien.
Hasta ahora, hemos considerado los DID y las credenciales verificables como estructuras de datos: identificadores, documentos, firmas. Pero eso es sólo una parte de un sistema de identidad operativo. En las implantaciones reales, el problema más difícil es la interacción: cómo se emiten las credenciales, cómo se presentan y cómo deciden los verificadores si confiar en ellas.
En sistemas de producción como el Billetera de identidad digital de la UE o Permiso de conducir móvil estadounidense (mDL) Los pilotos, los monederos y los verificadores no se limitan a “resolver un DID” y detenerse ahí. Se comunican a través de protocolos y formatos de credenciales definidos:
La distinción importante es que los DID y las credenciales verificables definen qué se está verificando. Estos protocolos definen cómo se mueve entre el emisor, el titular y el verificador en los sistemas reales.
Sin esta capa, los DID siguen siendo un mecanismo de resolución. Con ella, pasan a formar parte de una infraestructura de identidad operativa.
Si lo desmenuzamos, la identidad descentralizada es un modelo en el que los identificadores, las credenciales y los flujos de verificación no están controlados por un único proveedor. En su lugar, la identidad está anclada en claves criptográficas (a través de DID), y las afirmaciones sobre esa identidad se emiten y verifican independientemente de dónde se utilicen. Una forma útil de verlo: la identidad deja de ser una cuenta almacenada en una base de datos ajena y se convierte en un conjunto de declaraciones verificables que usted controla y reutiliza.
Vamos a compararlo con los modelos con los que ya trabajas.
La identidad centralizada sigue siendo la norma en todas partes. Una plataforma posee el registro de usuario, almacena sus datos y actúa como autoridad de verificación. Si quieres acceder, te autentificas en ese sistema. Todo, incluido el inicio de sesión, los permisos, la recuperación, fluye a través de él.
El problema no es sólo de seguridad (aunque las infracciones son un problema constante). Es la arquitectura:
La identidad descentralizada invierte esta situación. El sistema no necesita almacenar tus datos. Sólo necesita verificar las afirmaciones que presentas. La confianza pasa de “tenemos sus datos” a “podemos verificar esta prueba criptográfica”.
La identidad federada (OAuth, SAML, OpenID Connect) intentó resolver la fragmentación introduciendo proveedores de identidad, como Google, Microsoft o Apple, que responden por los usuarios en todos los servicios.
Funciona, hasta cierto punto. Pero la identidad federada sigue teniendo una dependencia central:
La identidad descentralizada elimina esa dependencia. No hay un único emisor que deba estar en línea en el momento de la verificación. Las credenciales se verifican mediante firmas, no mediante llamadas a la API. Es decir:
Es más parecido a cómo funcionan las credenciales físicas: no llamas a la oficina de pasaportes cada vez que alguien comprueba tu DNI.
Estos términos se confunden mucho. SSI es más bien una filosofía de diseño: el individuo controla su identidad, elige qué compartir y no está atado a un proveedor. La identidad descentralizada es la pila técnica que lo hace posible:
Se pueden implementar sistemas de identidad descentralizados que no sean totalmente “auto-soberanos” (por ejemplo, monederos controlados por la empresa o redes con permisos). Y se puede hablar de SSI sin especificar la infraestructura. En los sistemas reales, los dos suelen converger, pero es útil mantener clara la distinción cuando se diseñan arquitecturas.
Las carteras son el punto de encuentro entre la identidad descentralizada y las limitaciones del mundo real. En teoría, el control de la identidad procede del control de las claves criptográficas. En la práctica, esto crea un problema que los sistemas tradicionales no tienen: ¿qué ocurre cuando el usuario pierde el acceso?
Si un DID está vinculado a una clave privada y ésta se pierde, no existe ningún mecanismo de recuperación por defecto. No existe un flujo de “restablecimiento de contraseña” a menos que el sistema esté explícitamente diseñado para soportarlo. La pérdida de la clave puede significar la pérdida de control sobre el identificador y las credenciales vinculadas a él.
Por eso, los sistemas de producción introducen modelos de recuperación y custodia sobre la capa DID:
La compensación es inevitable: cuanto más se traslada el control al usuario, más se traslada la responsabilidad a la gestión de claves. Por eso, la mayoría de las implantaciones en el mundo real equilibran la soberanía propia con la facilidad de uso, en lugar de dejar toda la propiedad de las claves en manos del usuario.
Merece la pena detenerse en este punto, porque la identidad basada en DID sólo funciona realmente cuando se separan sus elementos básicos. El identificador no es la credencial, la credencial no es el monedero y el marcador en la cadena no es la propia identidad. Cada capa tiene una función distinta, y esa separación es lo que hace que el modelo funcione.
Estos dos componentes constituyen el núcleo del modelo de identidad descentralizado. En algunos sistemas, especialmente en entornos Web3, se utilizan mecanismos adicionales en la cadena para imponer el acceso o los roles.
Fichas de alma (SBT) son un ejemplo. Son tokens intransferibles vinculados a un monedero y utilizados para cosas como la acreditación o los permisos de protocolo. Los contratos inteligentes pueden comprobarlos directamente.
Sin embargo, las SBT no forman parte de la pila de identidad en sí. Son una capa de aplicación opcional construida sobre las señales de identidad, y conllevan ventajas y desventajas: visibilidad pública en la cadena, portabilidad limitada y retos en torno a la revocación y la recuperación de claves.
Los sistemas de identidad tradicionales fracasan porque tratan la confianza como un problema de almacenamiento. Todas las plataformas recopilan las mismas pruebas en bruto, como escaneos de pasaportes, selfies y comprobantes de domicilio, y luego las almacenan dentro de su propio perímetro de cumplimiento. Esto crea el mismo desorden en todas partes: duplicación de la IIP, escasa portabilidad, amplias superficies de infracción y flujos de incorporación que se hacen más pesados sin mejorar mucho.
En el modelo tradicional, los sistemas de identidad acumulan riesgos con el tiempo. Los proveedores de KYC, las bolsas, las aplicaciones fintech, las plataformas de RRHH y los mercados acaban almacenando aproximadamente el mismo conjunto de pruebas: documento de identidad oficial, escaneado facial, datos de dirección y metadatos de la propia sesión de verificación.
Desde el punto de vista de la implantación, el problema suele agravarse por la proliferación de copias. Los mismos datos de usuario acaban en sistemas de incorporación, herramientas de fraude, capas de CRM, herramientas de asistencia, almacenes de datos y archivos de cumplimiento. Incluso si la pila de verificación principal está bloqueada, los sistemas circundantes no suelen cumplir la misma norma.
La identidad tradicional no ofrece al usuario prácticamente ningún control sobre el estado de verificación. La plataforma controla el registro, la política de retención, el calendario de re-verificación y las reglas de reutilización.
Esto significa que el usuario no puede trasladar la confianza de un contexto a otro. El hecho de pasar la verificación KYC en la plataforma A no sirve de nada en la plataforma B, porque el resultado de la verificación queda atrapado dentro del perímetro de cumplimiento de la plataforma A. La declaración subyacente puede seguir siendo válida, pero no hay ningún artefacto criptográfico portátil en el que pueda confiar el siguiente verificador.
Aquí es donde el modelo empieza a quebrarse económicamente. Cada plataforma paga para reconstruir la confianza desde cero, porque la identidad se almacena como datos internos, no se emite como prueba reutilizable.
El modelo heredado también revela demasiado por defecto. Para demostrar un hecho concreto, se suele pedir a los usuarios que revelen el documento fuente completo que lo sustenta.
Es un mal patrón de privacidad, pero también es un mal patrón de sistemas. Una vez que la identidad se vincula a registros basados en cuentas y a la presentación repetida de documentos, la correlación resulta fácil entre servicios, sesiones y contrapartes. El verificador obtiene más datos de los que necesita, almacena más de los que debería y aumenta la responsabilidad sin mejorar proporcionalmente la calidad de la confianza.
Este es el impuesto operativo que todo el mundo ya conoce. La misma persona completa el proceso KYC una y otra vez porque cada plataforma ejecuta su propia pila de confianza y no puede consumir la verificación como una credencial portátil.
Si has trabajado en la tokenización, la incorporación a la bolsa o los flujos regulados de monederos, habrás visto lo derrochador que resulta esto. El cuello de botella es el hecho de que la confianza no puede moverse limpiamente entre los sistemas, por lo que cada institución reconstruye la misma tubería de verificación alrededor de su propio límite de base de datos.
Y ni siquiera las credenciales verificables lo arreglan por sí solas. Una firma válida sólo demuestra que una reclamación ha sido emitida por una parte concreta. No prueba que esta parte tuviera autoridad para emitir esa reclamación. Esa es la parte que muchos pilotos de DID subestiman. Los verificadores tienen que saber qué emisores son legítimos, qué esquemas de credenciales se aceptan y bajo qué normas se puede confiar en una declaración.
En producción, esto se gestiona a través de marcos de confianza: eIDAS 2.0 listas de confianza en la UE, Estilo VICAL coordinación de confianza para permisos de conducir móviles según la norma ISO 18013-5, Federación OpenID cadenas fiduciarias y registros nacionales de proveedores de servicios fiduciarios.
Sin esa capa, no se obtiene una identidad reutilizable. Obtienes credenciales que se verifican matemáticamente pero no significan nada operativamente. La firma es válida. Falta la confianza.
Basta de definiciones. Lo que importa aquí es la ruta de verificación: cómo un DID se convierte en resoluble, cómo un emisor vincula una reclamación a él, y cómo esa reclamación se comprueba más tarde sin recurrir a un registro central. Recorramos el flujo de principio a fin.
01
Se crea y resuelve el DID | Un DID sólo resulta útil cuando puede resolverse. Se genera con material clave y se publica según un método DID. La resolución devuelve el documento DID, que expone las claves públicas y los métodos de verificación que otros utilizan para validar las firmas. |
02
El emisor vincula un crédito a ese DID | Una vez que el sujeto tiene un DID, un emisor puede adjuntarle una reivindicación firmada como credencial verificable. El emisor realiza primero sus comprobaciones y luego firma una credencial que vincula la declaración al identificador del sujeto. Lo que avanza no son pruebas en bruto, sino un resultado atestiguado. |
03
El titular presenta la reclamación | El titular almacena la credencial, normalmente en una cartera, y la presenta cuando necesita una prueba. Dependiendo de la pila, puede ser la credencial completa o una prueba derivada. La cuestión es la reutilización: el titular presenta una credencial ya verificada en lugar de reiniciar el onboarding. |
04 El verificador lo valida localmente | El verificador comprueba la firma del emisor, confirma la vinculación del sujeto y evalúa el estado de la credencial, como su caducidad o revocación. Para ello, resuelve el DID del emisor y recupera la clave pública del documento DID. No se requiere ninguna llamada de retorno del emisor. |
Una vez que el flujo está claro, aparecen las verdaderas cuestiones de diseño: cómo se utilizan los identificadores y cómo se gestionan las claves a lo largo del tiempo.
Un DID público es estable y descubrible. Los emisores suelen utilizarlo porque los verificadores necesitan una forma coherente de resolver claves y validar firmas. En cambio, un DID por pares se genera por relación. El mismo usuario presenta diferentes identificadores a diferentes verificadores, lo que impide la correlación entre servicios.
Esta elección no es cosmética. La reutilización de un único DID en todos los servicios hace que la vinculación sea trivial. Los DID por pares rompen esa vinculación a nivel de identificador.
Luego está la gestión de claves, que es donde la mayoría de los sistemas tienen problemas en producción. Un DID es tan fiable como las claves que lo respaldan, así que hay que planificarlo:
En la práctica, aquí es donde radica la complejidad. La verificación de firmas es sencilla. Mantener los identificadores utilizables, recuperables y no correlacionables a lo largo del tiempo es el problema de ingeniería más difícil.
Una vez superado el flujo, la siguiente cuestión es cómo se resuelven y mantienen realmente los identificadores. Esto se reduce a dos cosas: el Estructura del documento DID como el Método DID que define cómo se crea, actualiza y resuelve.
Un documento DID es el resultado de la resolución de un DID. Indica a los verificadores qué claves, controladores y puntos finales de servicio están autorizados para ese identificador. En la práctica, no es un perfil de usuario. Es un descriptor de verificación.
Campos básicos que suelen interesarle:
Y el punto de implementación de la clave sigue siendo el mismo: un verificador resuelve el DID, selecciona el método de verificación adecuado y comprueba si esa clave está autorizada para la operación que se está realizando.
Hasta ahora, hemos hablado sobre todo de la identidad como algo que controla una persona. En los sistemas B2B, el sujeto clave suele ser una organización. Los bancos, los proveedores de logística y las plataformas RWA necesitan verificar no sólo que firmó algo, sino si esa persona estaba autorizada para actuar en nombre de una empresa.
Ahí es donde los DID organizativos se vuelven más complejos. El control se distribuye entre funciones, sistemas de custodia, políticas de firma y reglas de delegación. Una configuración de producción tiene que definir quién puede firmar, qué puede firmar y cómo se revoca esa autoridad.
En la práctica, esto puede implicar vLEI de la GLEIF para la identidad de personas jurídicas, carteras corporativas con Firma respaldada por HSM, y cadenas de capacidades de autorización como ZCAP-LD.
Los documentos DID no son estáticos. Las claves caducan, los dispositivos se pierden, la infraestructura de firma cambia y las claves del emisor necesitan rotación. Un diseño serio de DID tiene que gestionar todo esto sin romper las credenciales existentes.
La rotación de claves suele significar añadir un nuevo método de verificación, cambiar qué clave está autorizada para una relación determinada y retirar la clave antigua. Pero el detalle que importa es propósito. Girar un autenticación afecta a los flujos de inicio de sesión o de desafío-respuesta. La rotación de una assertionMethod clave afecta a la expedición y verificación de credenciales.
La ruta de actualización depende del método DID. Con hizo:web, se actualiza el documento DID alojado. Con did:ethr, se publica una transacción en el registro. La parte difícil es la continuidad: los verificadores deben saber qué clave era válida cuando se emitió una credencial y si esa credencial ha sido revocada, caducada o sustituida desde entonces.
Y eso nos lleva a los métodos DID, porque el método define exactamente cómo funcionan la creación, la resolución, las actualizaciones y la desactivación en el sistema real.
Un método DID es la capa de implementación detrás de la sintaxis DID estándar.
Define las normas para:
En otras palabras, la sintaxis DID es estándar (did:método:identificador), sino que el método da forma a todo el modelo de infraestructura que hay detrás del DID.
Estos tres métodos cubren la mayoría de los casos de uso en el mundo real:
| Criterios | hizo:llave | hizo:web | did:ethr |
|---|---|---|---|
| Modelo de resolución | Determinista (derivado de la clave pública) | HTTPS (ruta conocida del documento DID) | Registro Ethereum DID (en la cadena) |
| Actualizar modelo | No actualizable | Fuera de la cadena (alojado en un dominio) | Transacciones en cadena |
| Modelo de confianza | Control de teclas directo | DNS + TLS + control de dominio | Consenso en la cadena de bloques (Ethereum) |
| Caso típico | ID efímeros, DID pares, pruebas | Empresas, SaaS, emisores DID | Web3, tokenización, identidad en cadena |
Ahora la tabla te da la mecánica. La parte más difícil es decidir con qué modo de fallo puedes vivir: Dependencia del DNS, coste de la cadena, no rotación, auditabilidad pública o portabilidad más débil. Así que aquí está mi opinión sobre cómo elegir.
Antes de elegir, hazte las preguntas feas de la producción:
En las implantaciones reales, se suelen mezclar métodos. Los emisores suelen utilizar hizo:web o did:ethr; los titulares utilizan identificadores por pares o efímeros. Esta división mantiene estable la confianza del emisor y reduce el riesgo de correlación para los usuarios.
Aclaremos esto desde el principio: no se necesita una cadena de bloques para implantar la identidad descentralizada. La especificación DID Core del World Wide Web Consortium no lo requiere, y muchos sistemas de producción funcionan completamente fuera de la cadena.
¿Por qué se habla de blockchain? Porque resuelve muy bien un problema concreto: confianza compartida sin un propietario central. No el almacenamiento, ni la identidad en sí, sino la coordinación en torno a las claves, los identificadores y el estado.
En los sistemas basados en DID, blockchain actúa como un registro público a prueba de manipulaciones. Según el método, puede utilizarse para:
El punto clave: la cadena de bloques no verifica la identidad. Está proporcionando un punto de referencia común en la que los verificadores puedan confiar sin fiarse de una sola parte.
Por ejemplo, con did:ethr, El DID se resuelve con los datos de la cadena. El verificador confía en el estado de la cadena, no en la infraestructura del emisor.
Aquí es donde muchas implementaciones de DID se equivocan. Blockchain es útil para el estado compartido, pero es un lugar terrible para los datos de identidad en bruto. No se ponen pasaportes, datos biométricos, credenciales completas o registros personales en la cadena. Se utiliza la cadena para el material de prueba y los datos de coordinación, y se mantienen las cargas sensibles de identidad fuera de la cadena.
Una división limpia suele tener este aspecto:
En cadena:
Fuera de la cadena:
La razón es sencilla: privacidad y coste. Las cadenas de bloques son públicas, permanentes y costosas de actualizar. Los datos de identidad necesitan privacidad, eliminación, corrección y control de acceso. Esas dos cosas no combinan.
Blockchain se utiliza normalmente para anclar, no para almacenar. Se introduce una pequeña prueba de estado en la cadena, como el hash de un documento DID, una actualización del registro de emisores, una referencia al estado de la credencial o un evento de rotación de claves, mientras que los datos de identidad reales permanecen fuera de la cadena.
Esto proporciona a los verificadores tres propiedades útiles:
La contrapartida es la permanencia. Si se introducen en la cadena datos erróneos, no se pueden eliminar limpiamente. Por eso los sistemas DID maduros anclan hashes, referencias y transiciones de estado, no credenciales completas, documentos o datos personales.
Blockchain es la herramienta equivocada cuando no elimina una dependencia de confianza. Si la misma organización controla el emisor, el verificador y la aplicación, poner el estado DID en la cadena normalmente sólo añade costes, latencia y ruido operativo.
Omitir blockchain cuando:
Por eso hizo:web funciona tan bien para muchos flujos de identidad empresarial. Mantiene el modelo DID, pero utiliza la infraestructura web existente en lugar de forzar cada actualización a través de una transacción de blockchain.
Utiliza blockchain cuando partes independientes necesiten un estado compartido que puedan verificar sin confiar en tu servidor. De lo contrario, manténgalo fuera de la cadena. Más descentralización sobre el papel no significa automáticamente una mejor arquitectura de identidad.
En sistemas como el monedero de identidad digital de la UE o los permisos de conducir móviles (ISO 18013-5), se optó por la PKI en gran medida porque las redes L1/L2 públicas no cumplen los requisitos básicos de identidad: privacidad, soberanía de los datos y control normativo. Los datos de identidad no pueden reproducirse públicamente, y las jurisdicciones necesitan un control estricto sobre dónde se procesan y almacenan los datos.
Pero las nuevas arquitecturas introducen una tercera opción: sistemas zk-L2 autorizados. Estos combinan:
La idea clave es la separación de intereses a nivel de infraestructura:
Esto evita una limitación fundamental de las cadenas públicas: la exposición de los datos. Al mismo tiempo, evita una limitación de la PKI pura: la dependencia de jerarquías de confianza cerradas sin auditabilidad compartida.
Otra propiedad importante es arquitectura multidominio. Diferentes actores - ministerios, reguladores, bancos o regiones - pueden operar en zonas de ejecución separadas con sus propios límites de cumplimiento, sin dejar de contribuir a un estado verificable compartido a través de pruebas.
Esto amplía el espacio de diseño de los sistemas de identidad. En lugar de elegir entre PKI centralizada y blockchain pública, las nuevas implantaciones pueden combinar privacidad, conformidad y confianza compartida en un único modelo.
Bien, a estas alturas debería estar claro qué hacen los DID de forma diferente a los CSC estándar. Pero la cuestión más práctica es: ¿qué cambia eso para mí? Buena pregunta. Por lo que he visto en implementaciones reales, el impacto depende mucho del lado en el que te encuentres, así que merece la pena desglosarlo.
Para los usuarios, el mayor cambio es el control sobre cuándo y cómo se comparte la identidad.
En la práctica, esto hace que la identidad deje de ser algo que se reenvía constantemente y se convierta en algo que hay que tener en cuenta. presente cuando sea necesario.
Para las organizaciones, el cambio tiene menos que ver con la UX y más con riesgo y estructura de costes.
Lo que cambia operativamente es lo siguiente: dejas de ser un custodio de datos y empiezas a ser un verificador de siniestros.
Para los desarrolladores, el valor está en cómo se estructura la lógica de la identidad.
Desde el punto de vista de la ingeniería, se pasa de “gestionar usuarios y sesiones” a verificación de pruebas y aplicación de condiciones.
Dejemos a un lado la teoría por un momento y hagámoslo como lo haríamos en un sistema real. ¿Qué hace DID en realidad sentir como ¿en la práctica? ¿Dónde deja de ser un diagrama y empieza a ser algo que se envía?
Se dará cuenta de algo a medida que avanzamos: los objetos cambian -diploma, historial laboral, estado KYC- pero el flujo apenas lo hace.
Supongamos que te acabas de graduar y necesitas demostrar tu título a un futuro empleador. El camino habitual es torpe: subir un PDF, adjuntar un escáner, tal vez esperar mientras alguien envía un correo electrónico al registrador. Funciona, pero a duras penas. Todo el proceso depende de la confianza manual.
Con una credencial basada en el DID, la universidad expide una credencial verificable cuando te gradúas. Se guarda en tu cartera, firmada por una clave publicada en el documento DID de la universidad.
Meses después, solicitas un trabajo. El empleador no necesita ponerse en contacto con la universidad. Presentas las credenciales y su sistema las comprueba:
Esa es la belleza del modelo: la universidad firma una vez, usted reutiliza la prueba y cada verificador puede comprobarla independientemente.
¿En qué medida te fías realmente de un currículum? Los títulos se inflan. Las fechas se difuminan. “Dirigir un equipo” puede significar cualquier cosa, desde dirigir a diez personas hasta organizar reuniones.
Ahora dale la vuelta al modelo. Cuando dejas una empresa, te dan una credencial:
La próxima vez que alguien te pregunte: “¿Puedes demostrar que has hecho X?”, no des explicaciones. Presenta. Y no, eso no significa exponer todo el historial laboral cada vez. Con el formato de credencial adecuado, el titular puede demostrar una afirmación más limitada, como:
...sin entregar el historial laboral completo. Es una postura muy distinta a “envíenos su CV completo y sus referencias.”
Aquí, la identidad reutilizable se hace evidente. Se verifica una vez con un proveedor de confianza: se comprueba el pasaporte, se pasa el control de sanciones y se confirma la jurisdicción. El proveedor expide una credencial KYC a su monedero.
¿Próxima plataforma? Presenta las credenciales en lugar de volver a subir los mismos documentos. La plataforma lo comprueba:
Algunos equipos de tokenización también utilizan fichas con alma como marcadores KYC en la cadena: esta dirección ha pasado la comprobación requerida. Los datos de identidad permanecen fuera de la cadena; la cadena solo lleva la señal de elegibilidad.
Útil, pero sólo si el marcador es amplio, revocable y no supone una fuga permanente de privacidad.
La sanidad es donde la arquitectura DID necesita una correa corta. Digamos que una clínica le da una credencial de vacunación, un laboratorio firma el resultado de su análisis de sangre y su médico expide una credencial de prescripción. Los guardas en tu cartera en lugar de dejar que cada registro desaparezca en otro portal.
Entonces cambias de médico. ¿Esperas a que un sistema hable con otro? ¿Persigue los PDF? No. Usted comparte la credencial específica que necesita el nuevo proveedor. Ellos verifican el emisor, la firma y el estado.
Y para que quede claro: nada de esto requiere poner los datos médicos en cadena. La cadena es para identificadores, claves, quizá registros de estado. Las cosas sensibles se quedan fuera de la cadena. Si no se respeta ese límite, el diseño está roto.
Ahora alejémonos de la gente. Coge un producto, por ejemplo, una botella de aceite de oliva. Etiqueta premium, bonito envase. ¿Es real? En lugar de confiar en la marca, toca con su teléfono una etiqueta NFC. Detrás de esa etiqueta hay un DID vinculado al lote del producto.
Lo que obtienes son datos firmados:
Se puede seguir literalmente el producto desde el origen hasta la estantería. ¿Resuelve todo? No. Si la primera entrada de datos es errónea, todo lo que viene después no hace más que mantener el error. Pero al menos ahora sabe que firmado cada paso. Es una gran mejora respecto a “confía en nosotros.”
El gobierno es donde la identidad de estilo DID abandona la burbuja criptográfica. Un punto de referencia importante es el monedero de identidad digital de la UE en el marco de eIDAS 2.0, una iniciativa a gran escala cuyo objetivo es proporcionar monederos a ciudadanos, residentes y empresas de todos los Estados miembros.
Pero el panorama es más diverso. Algunos de los sistemas de identidad digital más grandes y maduros del mundo no se basan estrictamente en DID, pero siguen patrones similares en torno a credenciales reutilizables y datos controlados por el titular:
El cambio común a todos estos sistemas es el mismo: pasar de registros de identidad centralizados a pruebas reutilizables y presentadas por el usuario. Al mismo tiempo, es importante separar los modelos de confianza. Sistemas como eIDAS se basan en PKI federadas y listas de servicios de confianza, mientras que los sistemas basados en DID se basan en identificadores criptográficos y credenciales verificables. En la práctica, estos modelos suelen coexistir en lugar de sustituirse.
Hasta ahora, todo funciona bien dentro de un único sistema. Pero, ¿qué ocurre cuando las credenciales cruzan los límites del sistema? Ahí es donde las cosas se ponen estrictas. Se necesitan normas compartidas para que los datos tengan sentido en todas partes, y gobernanza, para que los verificadores sepan en qué emisores confiar. Estas son las normas y los niveles de gobernanza más importantes.
| Capa | Qué define | En la práctica | Por qué es importante |
|---|---|---|---|
| Especificación DID Core del W3C | Sintaxis DID (did:método:id), documentos DID, relaciones de verificación, modelo de resolución | Documento DID con verificationMethod, autenticación, assertionMethod, puntos finales de servicio | Garantiza que cualquier verificador pueda resolver un DID y comprender qué claves son válidas para qué operaciones. |
| Modelo de datos de credenciales verificables | Estructura de las credenciales, funciones del emisor/titular/ verificador, formatos de las pruebas, modelo de presentación | credenciales JSON-LD o JWT, divulgación selectiva, flujos de intercambio de presentaciones | Permite la portabilidad de las credenciales entre sistemas y su verificación sin la intervención del emisor. |
| DIF (Fundación para la Identidad Descentralizada) | Protocolos, especificaciones de interoperabilidad, comunicación cartera/agente, intercambio de presentaciones | Mensajería DIDComm, intercambio de presentaciones, flujos de monedero a monedero o de monedero a servicio. | Evita la fragmentación haciendo que diferentes monederos y verificadores trabajen realmente juntos. |
| Marcos de confianza | Acreditación de emisores, esquemas de credenciales, niveles de garantía, normas de gobernanza | Proveedores KYC aprobados para una plataforma, definiciones de esquema para “inversor verificado” o “entidad autorizada” | Define qué credenciales son aceptables y en qué condiciones se puede confiar en ellas. |
Las normas hacen que las credenciales sean interoperables. La gobernanza las hace aceptables. Sin normas, nada es compatible. Sin gobernanza, nada es fiable. Los sistemas reales sólo funcionan cuando ambas capas se definen conjuntamente.
Las normas indican cómo debe comportarse un sistema DID. La producción te dice dónde se complica. Hoy en día, la mayoría de los riesgos no provienen de la sintaxis DID o de los algoritmos de firma en sí. Aparecen en torno a los monederos, la recuperación de claves, la revocación, la interoperabilidad y si suficientes emisores y verificadores están de acuerdo en utilizar el mismo modelo de confianza.
En los sistemas DID, la identidad depende del control de las claves. Eso es potente, pero implacable. Si un usuario pierde la clave, la recuperación no es automática. Si un atacante consigue la clave, puede hacerse pasar por el titular. Por eso las implementaciones serias rara vez se basan únicamente en una frase semilla sin procesar. Suelen necesitar MPC, recuperación social, claves respaldadas por hardware o algún modelo de custodia híbrido.
Las credenciales envejecen. Los datos personales caducan, los empleados se van, las licencias se suspenden. Así que la verificación no puede detenerse en “¿es válida la firma?”. El verificador comprueba el estado de la credencial en el momento de su uso. Esto suele implicar listas de estado, registros de revocación o credenciales de corta duración. Si se omite esta parte, las credenciales antiguas seguirán pareciendo válidas.
Los estándares ayudan, pero no hacen que todos los monederos, emisores y verificadores sean compatibles por arte de magia. Una pila puede usar credenciales JSON-LD, otra puede preferir métodos JWT. Métodos DID. Los protocolos de presentación difieren. Así que sí, el ecosistema avanza hacia la interoperabilidad, pero los proyectos reales siguen necesitando trabajo de integración y estrictas elecciones de perfiles.
Lo más difícil es la coordinación. Un sistema DID necesita emisores en los que la gente confíe, verificadores dispuestos a aceptar credenciales, usuarios capaces de gestionar carteras y reglas de gobierno que todos entiendan. Hasta que esas piezas no se alineen, la adopción se producirá en compartimentos estancos: finanzas reguladas, tokenización, credenciales laborales, identificación gubernamental y ecosistemas cerrados en primer lugar.
La mayoría de los sistemas DID actuales se basan en la criptografía de curva elíptica: Ed25519, secp256k1 o P-256. Estos sistemas están muy extendidos, pero no son seguros desde el punto de vista poscuántico. Un ordenador cuántico suficientemente potente podría descifrarlos con el algoritmo de Shor, lo que convertiría la falsificación de firmas en un riesgo real a largo plazo.
Esto es importante porque las credenciales de identidad suelen durar años. Los diplomas, licencias y certificados legales emitidos hoy pueden seguir necesitando ser verificados mucho después de que la criptografía que los sustenta haya caducado.
Las normas ya avanzan en esa dirección. El NIST ha finalizado esquemas de firma post-cuántica como ML-DSA (Dilithium) y SLH-DSA (SPHINCS+), mientras que el ecosistema DID/VC explora las firmas híbridas y la criptoagilidad.
Los sistemas DID deben admitir múltiples métodos de verificación, nuevos conjuntos de firmas y rutas claras de rotación de claves desde el primer día. Las firmas poscuánticas son mucho mayores que las firmas Ed25519 o ECDSA, lo que afecta a las presentaciones QR, los registros y los mecanismos de estado en cadena. Pero para la identidad gubernamental y empresarial de larga duración, la criptoagilidad es imprescindible.
El error más frecuente es tratar la DID como algo que se “añade” a una pila de identidades ya existente. En la práctica, se trata de un cambio en la forma de modelar la confianza, el flujo de datos y la responsabilidad. Los aspectos técnicos no suelen ser lo más difícil. La mayoría de los proyectos triunfan o fracasan en función de la coordinación, la gobernanza y la integración.
Empiece por identificar dónde almacena los datos de identidad para verificarlos después: estado KYC, edad, empleo, licencias, acreditaciones y derechos de acceso. El objetivo es almacenar menos datos en bruto y verificar más declaraciones firmadas. Esto reduce la responsabilidad, simplifica el cumplimiento y hace que la identidad sea transferible entre sistemas.
Antes de elegir las herramientas, defina el modelo de confianza en términos concretos. En proyectos reales, eso suele dar lugar a:
Sin esto, se obtienen credenciales que se verifican correctamente pero que no son aceptadas por los verificadores.
Ahora elija la pila técnica. Elige el método DID, el formato de las credenciales, el flujo del monedero y el modelo de revocación. hizo:web suele adaptarse a los flujos empresariales y de SaaS. did:ethr se ajusta a la aplicación de contratos inteligentes y a la identidad en la cadena. hizo:llave se ajusta a los identificadores efímeros o locales.
No elijas la opción más “descentralizada”. Elige la que se ajuste a tu límite de confianza.
No empieces con “identidad para todo”. Empieza con un flujo en el que el dolor esté claro. Los buenos pilotos incluyen:
Ábrelo bien: un tipo de credencial, uno o dos emisores, un flujo de verificadores, reglas de revocación claras. Evite empezar por:
Demostrar el flujo de extremo a extremo, y luego ampliar.
Una vez que se pasa de la fase piloto a la de producción, la emisión de credenciales es sólo la mitad del problema. La cuestión más difícil es qué ocurre cuando ya no se puede confiar en una credencial: caduca una comprobación KYC, un empleado se marcha, se suspende una licencia o un monedero se ve comprometido.
No existe un único planteamiento estándar, y cada modelo tiene sus contrapartidas:
Los distintos ecosistemas adoptan enfoques diferentes. Por ejemplo, los permisos de conducir móviles ISO 18013-5 se basan en la validación del emisor y en listas de confianza en lugar de en la revocación al estilo del W3C. Sin una estrategia de revocación clara, el modelo de “credencial reutilizable” se rompe. Una credencial comprometida puede seguir presentándose a menos que se compruebe activamente su estado.
Un proyecto típico de DID/VC se desarrolla por fases. Un proyecto piloto suele durar 3-4 meses y valida un caso de uso de extremo a extremo, normalmente en el rango de $150K–$300K, en función del alcance. Un despliegue de producción requiere 9-12 meses y se amplía a múltiples emisores, verificadores y tipos de credenciales, normalmente desde $800K a $2M+, en función de la complejidad de la integración y de los requisitos de conformidad.
Un equipo típico incluye:
En la práctica, la complejidad rara vez está en la criptografía. Está en la integración, la gobernanza y la experiencia del usuario.
Para terminar, alejémonos un poco. La identidad basada en DID no es una pila acabada. Aún está evolucionando, sobre todo en lo que respecta a los sistemas de prueba, la infraestructura de monederos, las capas de interoperabilidad y la integración normativa. Por lo que veo en las implantaciones reales, algunas direcciones están quedando claras.
La identidad reutilizable es el objetivo final obvio, pero el cuello de botella no es la verificación de firmas. Esa parte ya funciona. Lo más difícil es la confianza del emisor, los esquemas de credenciales y las normas de aceptación.
En el futuro, una credencial KYC emitida en un entorno regulado debería ser reutilizable en intercambios, plataformas de tokenización, productos de préstamo e interfaces DeFi conformes, siempre que el emisor DID pueda resolverse, el esquema se comprenda y el verificador acepte al emisor en su marco de confianza. Ahí es donde está el verdadero trabajo: no en demostrar que una firma es válida, sino en llegar a un acuerdo sobre el significado real de la declaración firmada.
Hoy en día, muchos sistemas siguen revelando atributos. El futuro es demostrar condiciones. En lugar de mostrar tu fecha de nacimiento, demuestras que tienes más de 18 años. En lugar de exponer todos los datos KYC, se demuestra que se ha superado una política de cumplimiento definida. En lugar de compartir un campo de jurisdicción, se demuestra la elegibilidad para una transacción.
Técnicamente, esto apunta hacia las firmas BBS+ para la divulgación selectiva y zk-SNARKs o zk-STARKs para las pruebas de predicado. El verificador comprueba la prueba con claves públicas controladas por el emisor, mientras que los datos personales subyacentes permanecen ocultos. Eso cambia el modelo de privacidad de “compartir menos datos” a “no compartir los datos en absoluto cuando una prueba es suficiente.”
La interoperabilidad decidirá si la identidad descentralizada permanece fragmentada o se convierte en una infraestructura utilizable.
Los puntos débiles siguen siendo familiares: credenciales JSON-LD frente a JWT, diferentes métodos DID, diferentes protocolos de monedero, diferentes flujos de presentación. Por eso, los sistemas de producción definen cada vez más perfiles estrictos: formatos de credenciales aprobados, métodos DID compatibles, emisores de confianza y protocolos de presentación aceptados.
Con el tiempo, espero una mayor convergencia en torno a los flujos entre monedero y verificador, el intercambio de presentaciones y los registros de confianza. Sin ello, cada proyecto DID se convierte en otra isla de identidad. Con ello, las credenciales pueden moverse entre plataformas sin necesidad de una integración personalizada cada vez.
La regulación está haciendo que la identidad descentralizada deje de ser una opción técnica para convertirse en una infraestructura pública.
En la UE, eIDAS 2.0 y el monedero de identidad digital de la UE son la gran señal. Los Estados miembros están obligados a proporcionar una infraestructura de monedero, con credenciales para atributos de identidad, licencias, cualificaciones y casos de uso en los sectores público y privado. Esto crea una capa de credenciales regulada en toda Europa.
En Estados Unidos, el Instituto Nacional de Normas y Tecnología está actualizando las directrices sobre identidad digital (por ejemplo, NIST 800-63) para tener en cuenta las credenciales criptográficas, los niveles de garantía y la verificación para preservar la privacidad. EE.UU. mantendrá probablemente un modelo más orientado al mercado, mientras que la UE impulsa un marco de monedero coordinado.
¿Hacia dónde va todo esto? Hacia menos cargas de documentos, más credenciales reutilizables, más comprobaciones criptográficas locales y una divulgación más selectiva. Los ganadores no serán los sistemas que almacenen más datos de identidad. Serán los que puedan verificar la declaración correcta con la menor exposición.
Un identificador descentralizado es un identificador único y resoluble que apunta a un documento DID que contiene claves públicas y métodos de verificación. Permite a las entidades demostrar su identidad o control sin depender de una autoridad central. En la práctica, sustituye la consulta de bases de datos por la verificación criptográfica.
Un DID resuelve un documento DID con claves públicas. Un emisor firma una credencial, un titular la almacena y un verificador comprueba la firma y el estado utilizando el DID del emisor. No es necesario llamar directamente al emisor. Esto hace que la verificación sea portátil e independiente de cualquier sistema.
La identidad descentralizada es el modelo general de emisión y verificación de declaraciones sin almacenamiento central. Un DID es sólo un componente de ese modelo. Actúa como capa identificadora utilizada para resolver claves y verificar firmas. Sin DID, el sistema carecería de una forma coherente de localizar y confiar en el material de verificación.
No necesariamente. Algunos métodos DID utilizan blockchains para la resolución o el anclaje, pero muchos, como hizo:web, se basan en la infraestructura web estándar. El propio DID es una referencia, no un registro de datos. Lo que puede almacenarse en la cadena son claves, hashes o referencias de estado, no datos de identidad.
Se utilizan para vincular identidades a claves criptográficas, permitir credenciales verificables, respaldar la reutilización de la información personal, la verificación de la mano de obra, las identificaciones digitales y el control de acceso tanto en sistemas web como basados en cadenas de bloques. Su función es hacer que la verificación de la identidad sea portátil entre sistemas.
Se genera un par de claves y se crea un DID según el método elegido. A continuación, se publica o registra para que pueda resolverse en un documento DID. El proceso exacto depende del método de DID (por ejemplo, web, blockchain o basado en claves). El método determina cómo se ancla, actualiza y resuelve el DID.
