La identidad descentralizada separa la identificación, la emisión de credenciales, su almacenamiento y su verificación para que ningún proveedor de inicio de sesión tenga que ser el guardián permanente de cada interacción. Los decentralized identifiers, o DID, ayudan a una entidad a demostrar el control de un identificador, mientras que las verifiable credentials, o VC, transportan afirmaciones firmadas por un emisor. El modelo mental útil no describe una identidad mágica que pertenece a una cartera, sino un flujo de confianza: el issuer formula una afirmación, el holder la guarda y la presenta, y el verifier comprueba la prueba, el estado, el contexto y la política. Este artículo explica ese flujo, dónde encaja blockchain y por qué la gestión de claves, la revocación, la divulgación selectiva y la protección de datos siguen siendo esenciales.
Qué significa decentralized identity explained
La frase decentralized identity explained se entiende mejor si la identidad se divide en capas. Un DID es un identificador que puede resolverse mediante un DID method hacia un DID document o un recurso relacionado. Ese documento puede describir métodos de verificación, servicios y las relaciones para las que se permite usar una clave. Una VC es distinta: es un conjunto de afirmaciones que un emisor hace sobre un subject, empaquetadas para que un verifier compruebe autoría e integridad. Un DID puede identificar a una persona, organización, dispositivo o servicio, pero por sí solo no demuestra edad, formación, empleo ni situación legal.
Esta separación evita una exageración frecuente. Descentralizado no significa anónimo, imposible de rastrear ni ajeno a la regulación. Una credential puede estar firmemente ligada a un proceso real de verificación de identidad, y al verifier se le puede seguir exigiendo que aplique sus propias reglas de elegibilidad, fraude, sanciones o acceso. Un DID method también puede depender de un servicio centralizado, un sistema federado, una base de datos, un libro distribuido u otro registry. La pregunta de diseño es quién controla el identificador, quién formula la afirmación, quién puede actualizar las claves asociadas y qué parte puede apoyarse en el resultado.
DID, issuer, holder y verifier en un flujo de confianza
Los cuatro términos describen tareas distintas. El issuer es la autoridad u organización que afirma algo y crea una credential. El holder posee la credential, normalmente en una wallet u otro repositorio protegido, y decide cuándo presentarla. El verifier recibe una credential o una verifiable presentation y comprueba el mecanismo de protección, el issuer, el subject, el periodo de validez, el estado y la finalidad comercial de la solicitud. El subject es la entidad sobre la que trata la afirmación. Holder y subject suelen ser la misma persona, pero un progenitor puede guardar una credential sobre un hijo, o una organización credenciales sobre un dispositivo.
Un DID document puede ayudar al verifier a descubrir el material público de verificación asociado a un issuer o a un holder. Las pruebas Data Integrity pueden vincular una prueba con un método de verificación y un propósito declarado, pero que la firma se compruebe correctamente no equivale a aceptar cada afirmación. El verifier necesita además una decisión de confianza: ¿está reconocido este issuer para este tipo de afirmación, es adecuado el esquema de la credential, es reciente la presentación y es proporcional la divulgación solicitada? NIST describe esto como separar la verificación criptográfica de la validación y la evaluación de las afirmaciones.
El ciclo de vida de VC desde la prueba hasta la presentación
El ciclo de vida empieza antes de la criptografía. Durante el alta o la verificación de identidad, el issuer decide qué evidencia es suficiente y qué nivel de garantía exige el caso de uso. Después crea afirmaciones sobre un subject, añade metadatos como el tipo y la validez y protege la credential con un mecanismo compatible. La wallet o el repositorio protege la copia del holder. En el momento de presentar, el holder crea una presentación para un verifier concreto, usando una credential o un conjunto de ellas y revelando quizá solo determinadas afirmaciones.
La verificación es una secuencia, no una única marca verde. El verifier analiza el documento, comprueba el modelo de datos y el mecanismo de protección, resuelve el material de verificación pertinente, valida el propósito de la prueba y cualquier vínculo con el holder, revisa el periodo de validez de la credential y realiza una comprobación de estado cuando existe o cuando la política la exige. Solo después evalúa si el issuer y las afirmaciones cumplen la regla de negocio. Una credential puede ser auténtica criptográficamente y aun así fallar porque ha caducado, está revocada, la emitió una autoridad no confiable, corresponde a otro subject o no sirve para el propósito solicitado. Renovación, actualización, suspensión, revocación y eliminación final son eventos del ciclo de vida, no propiedades que una blockchain gestione de forma automática.
Keys, DID documents y revocation son controles distintos
Las claves privadas o secretas son la autoridad de firma. Una clave pública u otro método de verificación permite al verifier poner a prueba un proof, pero no le permite crear un proof válido nuevo. El issuer debe proteger sus claves de firma, definir qué relación de verificación admite cada clave, vigilar cualquier compromiso y disponer de un plan de rotación y recuperación. El holder también necesita acceso seguro al dispositivo, procedimientos de copia o recuperación y una forma de distinguir una presentación de credential de una petición para entregar el secreto de la wallet. Perder una clave puede afectar al acceso; exponer una clave secreta permite la suplantación hasta que el ecosistema lo detecte y responda.
No deben confundirse tres relojes. Una prueba puede tener horas de creación y de expiración, una credential puede tener validFrom y validUntil, y un verification method puede rotarse, revocarse o dejarse expirar porque su clave está comprometida. El credential status es una señal distinta: puede indicar que el privilegio o la afirmación que representa la credential ya no está vigente. Por eso el verifier debe comprobar el mecanismo de estado y su frescura, y no solo si la firma se verifica matemáticamente. Las listas de estado, los registros o los endpoints del emisor mejoran el control operativo, pero también necesitan garantías de disponibilidad, privacidad, integridad y gobernanza.
Selective disclosure y el límite de la minimización de datos
La divulgación selectiva significa que el holder puede decidir con detalle qué información comparte. Si un servicio necesita saber únicamente si alguien supera un umbral, la fecha de nacimiento completa puede ser innecesaria. Una presentación puede llevar a veces una afirmación abstracta o una prueba de conocimiento cero en lugar del atributo original. Otros perfiles usan tokens de divulgación selectiva o suites de pruebas. La propiedad exacta de privacidad depende del formato de la credential, la suite criptográfica, la wallet, la solicitud del verifier y de si las presentaciones repetidas pueden enlazarse.
El límite importante es que un DID y una VC no aportan privacidad de forma automática. Un identificador estable, una firma repetida, una consulta de estado, un evento de telemetría de la wallet o una entrada en un libro público pueden generar correlación. Por eso la minimización de datos empieza con la pregunta del verifier: ¿cuál es la afirmación más pequeña que necesita esta decisión, durante cuánto tiempo y quién debe verla? Quien diseña debería evitar poner datos personales en un registro público inmutable, preferir identificadores por pares o adecuados al contexto cuando estén soportados, reducir la retención, proteger los logs y lograr que la persona entienda la parte y la finalidad antes de compartir. La privacidad es un resultado de la arquitectura, no una etiqueta pegada a una wallet.
Dónde encaja blockchain en self sovereign identity blockchain
La frase self sovereign identity blockchain suele dar a entender que todo registro de identidad debe estar on-chain. DID Core no lo exige. Un DID method define cómo se crean, resuelven, actualizan o desactivan los identificadores y sus documentos, y un verifiable data registry puede ser un libro distribuido, una base de datos, un sistema de archivos descentralizado u otro sistema de confianza. Blockchain puede resultar útil para un registro público y a prueba de manipulaciones de las operaciones del método, de los metadatos de confianza del issuer, de los eventos de rotación de claves o de información compacta de estado. También facilita el descubrimiento compartido cuando los participantes no quieren que un único operador controle el registro.
Blockchain también introduce costes y riesgos. Los registros públicos se copian y correlacionan y son difíciles de eliminar; la disponibilidad de las transacciones y la gobernanza pueden cambiar; un hash no demuestra que el dato original fuera correcto; y un anclaje inmutable no repara una clave de issuer comprometida. Un diseño sólido mantiene las afirmaciones personales y los documentos grandes en almacenamiento protegido adecuado, publica solo los datos mínimos del registro y documenta cómo funcionan actualizaciones, recuperación, migración y solicitudes legales. El control autosoberano se entiende mejor como un conjunto de capacidades del usuario y de la organización que como la promesa de una cadena de volver a alguien independiente de emisores, verificadores o la ley.
Cumplimiento y lista práctica de verificación
Los sistemas de identidad siguen teniendo obligaciones legales y operativas. Según la jurisdicción y el caso de uso, un operador puede necesitar base jurídica, limitación de la finalidad, minimización de datos, controles de retención, procesos de acceso y rectificación, medidas de seguridad, respuesta a incidentes, controles de transferencia internacional y un marco de confianza auditable. Los materiales de la European Digital Identity Wallet insisten en compartir solo la información acordada, mientras que la guía de NIST sobre verificación de identidad muestra que la validación, las comprobaciones de revocación cuando existen y la garantía de autenticación son pasos separados. Son requisitos de gobernanza alrededor de una credential técnica, no funciones que un DID o blockchain puedan eximir.
Para una integración real, haz siete preguntas. ¿Qué DID method y qué registry se usan y cómo se tratan los fallos de resolución? ¿En qué issuer se confía para esta afirmación y cómo se verificó al subject? ¿Qué mecanismo de protección, cryptosuite, relación de clave y vínculo de presentación se exigen? ¿Cómo se comprueban la validez, el estado, la rotación, el compromiso y la recuperación? ¿Pide la solicitud más datos de los que necesita la decisión y puede la presentación resistir la repetición y la correlación? ¿Dónde se guardan las credenciales, los registros de actividad y los datos de estado, y durante cuánto tiempo? Por último, ¿qué regulador, contrato, lista de confianza o política interna determina si el verifier puede apoyarse en la afirmación? La frase verifiable credentials blockchain describe posibilidades de infraestructura, no una garantía de verdad, privacidad o cumplimiento.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Mezcladores de criptomonedas y privacy pools
- Qué es Billions Network: una plataforma de identidad privada
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.
Fuentes
[1] W3C: Decentralized Identifiers v1.0 w3.org
[2] W3C: Verifiable Credentials Data Model v2.0 w3.org
[3] W3C: Verifiable Credential Data Integrity 1.0 w3.org
[4] NIST: Digital Identity Guidelines nist.gov
[5] European Commission: European Digital Identity europa.eu
