Saltar al contenido
Financial Context Wiki

Identidad descentralizada (DID)

Guía práctica sobre identificadores descentralizados y credenciales verificables: qué demuestran, cómo funcionan la emisión y la presentación, y qué riesgos de confianza, privacidad y recuperación persisten.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

La identidad descentralizada es una arquitectura en la que un sujeto puede usar identificadores y credenciales protegidas criptográficamente entre servicios sin convertir una cuenta de plataforma en la fuente universal de identidad. Sus elementos habituales son los identificadores descentralizados (DID), las credenciales verificables (VC), el software del titular como una cartera y las reglas que indican a los verificadores qué emisores, evidencias y niveles de garantía aceptar.

Un DID es un URI como did:example:123. Su método DID define cómo se crea, resuelve, actualiza y desactiva el identificador. La resolución puede devolver un documento DID con métodos de verificación, relaciones como authentication o assertionMethod y puntos de servicio opcionales. Controlar la clave correspondiente puede demostrar el control del DID según ese método; por sí solo no demuestra nombre legal, edad, unicidad, empleo ni propiedad de una cuenta externa.

Una credencial verificable contiene afirmaciones de un emisor sobre uno o varios sujetos. El titular la guarda y puede crear una presentación verificable para un verificador. Una comprobación criptográfica correcta establece la integridad y autoría de los datos protegidos según el mecanismo elegido. El verificador aún debe decidir por separado si confía en el emisor, si las afirmaciones cumplen su política, si la credencial está vigente y si el presentador tiene derecho a usarla.

Por tanto, «descentralizada» no significa sin confianza, anónima, basada en blockchain ni libre de intermediarios. Significa que identificadores, credenciales, registros, carteras y políticas de verificación pueden separarse para que un único proveedor de inicio de sesión no observe y controle todas las relaciones. El grado real de descentralización depende de emisores, operadores del método DID, servicios de estado, proveedores de cartera, administradores de recuperación, claves de gobernanza y políticas de los verificadores.

Cómo funciona

  1. Definir la afirmación y el marco de confianza. Hay que precisar el sujeto, los atributos solicitados, los emisores aceptables, el proceso de prueba, el nivel de garantía, la retención, la jurisdicción y la vía de reclamación. Un formato criptográfico no decide si una universidad, gobierno, empresa o comunidad es una autoridad adecuada.
  2. Crear u obtener identificadores y claves. Emisor y titular pueden usar DID, URL HTTPS u otros identificadores admitidos. Si usan un DID, su método determina el registro y las reglas del ciclo de vida. El controlador protege la clave privada; el documento resuelto solo expone el material de verificación y los puntos necesarios.
  3. Comprobar y vincular al sujeto. El emisor revisa la evidencia según la política y vincula las afirmaciones resultantes a un sujeto de la credencial. El vínculo puede referirse a una clave controlada por el titular, una cuenta u otro identificador. Debe distinguirse la evidencia sobre una persona de la prueba de que el presentador controla una clave.
  4. Emitir la credencial. El emisor crea afirmaciones, fechas de validez, información de esquema o tipo y una referencia de estado, y protege la credencial con una prueba compatible. En credenciales Data Integrity, campos como cryptosuite, verificationMethod, proofPurpose y proofValue indican cómo se verifica la prueba.
  5. Guardar y seleccionar. El titular conserva la credencial en una cartera local o alojada. La cartera debe explicar qué solicita el verificador, revelar solo los datos necesarios cuando el formato lo permita y evitar reutilizar silenciosamente un identificador estable en contextos no relacionados.
  6. Presentar con vigencia y vinculación al destinatario. El verificador envía una solicitud con su identidad, propósito, nonce o desafío y vencimiento. El titular devuelve la credencial o una presentación derivada vinculada a la solicitud. Comprobar dominio y desafío ayuda a impedir que una presentación capturada se reproduzca ante otro verificador o sesión.
  7. Verificar criptografía y política. Se obtiene el material de verificación del emisor desde una fuente autenticada; se validan suite, propósito, desafío, dominio, fechas, esquema y estado; después se aplican las reglas de negocio. Un resultado como verified: true es una entrada para la autorización, no una orden de conceder acceso.
  8. Operar el ciclo de vida. Hay que rotar claves comprometidas, suspender o revocar credenciales, actualizar estados, ofrecer recuperación y recursos, conservar las pruebas de auditoría necesarias y publicar planes de migración o cierre. La verificación histórica exige reglas claras para claves antiguas, documentos antiguos y el momento de presentación.

Los tres roles principales son emisor, titular y verificador; el sujeto de la credencial puede ser distinto del titular. Un progenitor puede conservar una credencial sobre un menor y un agente de empresa puede presentar una credencial sobre una organización. La implementación no debe inferir que el presentador es el sujeto salvo que la credencial y el protocolo establezcan ese vínculo.

Los DID y las VC son independientes. Una VC puede usar un identificador de emisor que no sea DID y un DID puede existir sin VC. Asimismo, un método DID puede utilizar una blockchain, una base distribuida, un dominio web o un intercambio entre pares. Sus propiedades de seguridad y gobernanza deben evaluarse directamente, no deducirse del prefijo did:.

Ejemplo práctico

Supongamos que un servicio debe confirmar que un cliente tiene al menos 18 años sin recopilar su fecha de nacimiento. Una autoridad aceptada comprueba al cliente y emite una credencial de edad a una cartera. La credencial puede incluir la fecha de nacimiento o solo una afirmación ageOver18; cada opción tiene propiedades distintas de divulgación y reutilización.

Al registrarse, el servicio solicita para merchant.example una presentación de mayoría de 18 años, con desafío n-7f3a y una ventana de validez de 5 minutos. La cartera muestra la solicitud y, si la credencial y la suite lo permiten, deriva una presentación que revela solo el predicado necesario. El servicio comprueba método, prueba, desafío, dominio, ventana temporal y estado antes de registrar el resultado mínimo exigido por su auditoría.

El flujo reduce la necesidad de conservar imágenes de documentos o fechas completas, pero no elimina confianza ni riesgo. La autoridad puede registrar a la persona equivocada; la cartera o el dispositivo pueden estar comprometidos; un identificador estable o una consulta de estado pueden correlacionar usos; el servicio puede pedir datos excesivos; una suspensión errónea puede denegar acceso. La divulgación selectiva limita los datos de la presentación, no todos los metadatos visibles para emisores, carteras, redes y verificadores.

La rotación de claves muestra otro límite. Si el emisor sustituye una clave comprometida, las credenciales nuevas deben usar el nuevo método. Que una credencial antigua siga siendo verificable depende del historial del método DID, la fecha de la prueba, la política del verificador y el estado de la credencial. Eliminar la clave antigua del documento DID actual puede romper comprobaciones históricas legítimas u ocultar qué clave estaba autorizada al crear la prueba.

Riesgos y controles

  • Afirmaciones falsas o excesivas: Una firma válida conserva lo dicho por el emisor; no lo vuelve exacto. Hay que definir evidencia, responsabilidad, garantía, auditoría, caducidad y corrección.
  • Vínculo débil con el titular: Una credencial copiada puede servir a otra persona si la presentación no demuestra control de la clave o autenticador previsto. Cuando proceda, se vincula la prueba de posesión al verificador, desafío, propósito y sesión.
  • Compromiso de claves y cartera: Malware, phishing, secuestro de cartera en la nube o copias inseguras pueden exponer credenciales y claves. Se necesitan autenticación resistente al phishing, protección de hardware cuando corresponda, notificación y recuperación limitada.
  • Centralización de la recuperación: Un único administrador puede convertirse en el verdadero controlador de identidad. Debe documentarse quién reemplaza claves, qué evidencia necesita, cómo se detecta el abuso y cómo reclama o migra el usuario.
  • Correlación: Reutilizar un DID, método, patrón de firma, punto de servicio o ruta de estado puede enlazar actividad entre servicios. Convienen identificadores por pares, claves o pruebas separadas por dominio, estado privado y pruebas de metadatos.
  • Datos personales públicos: Los documentos DID y el historial del registro pueden indexarse públicamente y ser difíciles de borrar. Nombres, números, biometría y otras afirmaciones personales deben quedar fuera de documentos DID públicos y registros inmutables.
  • Privacidad y disponibilidad del estado: Consultar al emisor en cada comprobación revela dónde se usa la credencial; una caída puede bloquear a usuarios válidos. Se prefieren estados privados y almacenables en caché, con límites de vigencia, actualizaciones autenticadas y comportamiento de fallo definido.
  • Abuso de revocación: Emisor o administrador puede censurar titulares suspendiendo credenciales o cambiando estados. Hay que limitar autoridad, registrar cambios, mostrar motivos y recursos, y admitir reemplazo o emisores alternativos cuando sea posible.
  • Riesgo de resolución y método: Un resolvedor puede devolver documentos obsoletos o maliciosos, y un método depender de infraestructura central o gobernanza mutable. Se autentican resultados y se evalúan finalidad, autorización de cambios, disponibilidad, gobernanza y versiones.
  • Desajuste semántico: Dos sistemas pueden analizar los mismos campos e interpretar de forma distinta una afirmación, unidad, jurisdicción o garantía. Deben usarse esquemas y vocabularios estables, validar contexto y tipo, y versionar la semántica de políticas.
  • Reproducción y confusión del verificador: Una presentación sin nonce, destinatario, dominio, acción y vencimiento puede reutilizarse o redirigirse. Hay que validar cada vínculo exigido por el protocolo.
  • Divulgación excesiva: Aunque una cartera admita divulgación selectiva, el verificador puede exigir la credencial completa. La minimización debe imponerse en política e interfaz, registrar el propósito y evitar que campos opcionales se vuelvan obligatorios por costumbre.
  • Dependencia del ecosistema: Carteras, pruebas, registros o recuperaciones propietarias pueden impedir la portabilidad. Antes de desplegar se prueban conformidad, exportación, varias carteras, agilidad criptográfica y migración.
  • Captura de gobernanza: Una multifirma o un registro no garantizan control amplio si un proveedor elige emisores, actualizaciones, esquemas y estados. Hay que mapear la autoridad por componente y publicar controles de cambio.

Errores comunes

  • «Un DID demuestra quién es una persona». Un DID identifica a un sujeto y puede exponer métodos de verificación; los atributos requieren afirmaciones, evidencia y decisiones de confianza adicionales.
  • «Una credencial válida significa que la afirmación es cierta». La verificación muestra la prueba esperada y que los datos no cambiaron; no valida la investigación o juicio originales del emisor.
  • «El titular siempre es el sujeto de la credencial». Los roles pueden diferir, por lo que el verificador necesita un vínculo explícito entre sujeto y presentador cuando el caso lo requiera.
  • «Todo debe estar en la cadena». El almacenamiento público e inmutable amplifica riesgos de privacidad, correlación, borrado y gobernanza. Muchos sistemas guardan credenciales fuera de la cadena y publican solo material de verificación o estado.
  • «La divulgación selectiva garantiza anonimato». Atributos revelados, identificadores estables, huellas de prueba, consultas, tiempo, direcciones IP y registros del emisor aún pueden correlacionar presentaciones.
  • «Descentralizado significa sin emisor ni administrador de confianza». La confianza se distribuye y explicita, no desaparece. Emisión, prueba, distribución de carteras, recuperación, estado y aceptación siguen gobernados.
  • «Un DID equivale a un ser humano». Una persona puede controlar muchos DID y un DID puede identificar organización, dispositivo, datos, rol u otro sujeto. Unicidad y condición humana requieren mecanismos aparte.
  • «Una firma de cartera basta para autenticar». Demuestra control de una clave bajo condiciones concretas. La aplicación aún necesita resistencia al phishing, vigencia, destinatario, autorización y recuperación de cuenta.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...