Resumen

  • El Grupo de Trabajo de Credenciales Verificables del W3C publicó el 24 de septiembre el primer borrador de una nota separada sobre amenazas del modelo v2.1; el borrador del modelo fechado el día 20 ya ofrecía el resumen no normativo.
  • La nota desarrolla 25 riesgos repartidos en cinco grupos. La clasificación identifica superficies de responsabilidad, pero no es una medición de incidentes ni una prueba de controles desplegados.
  • Identificación al emitir, tratamiento seguro del contenido y aptitud de una credencial para un fin concreto siguen requiriendo decisiones fuera de la mera comprobación criptográfica.

Un verificador recibe una credencial auténtica. La firma coincide y no figura revocada. Sin embargo, el documento puede haber nacido con una identidad equivocada: alguien engañó al emisor durante la comprobación inicial y consiguió una credencial válida a nombre de otra persona. En la amenaza T25, el nuevo texto del W3C muestra por qué una cadena de verificaciones impecables no corrige un error anterior. La intensidad de la comprobación de identidad la elige el emisor; el verificador debe valorar si ese nivel basta para el riesgo de su propia decisión.

La novedad del 24 de septiembre no es que W3C haya encontrado por primera vez todos estos riesgos. El Verifiable Credentials Data Model v2.1, publicado como Working Draft el 20 de septiembre, ya incluía en su apéndice A una lista resumida y no normativa. La nota independiente, presentada como primer Group Note Draft, añade escenarios, respuestas propuestas y componentes afectados. Convierte un inventario compacto en una herramienta más legible para localizar decisiones y límites, sin transformar ese inventario en una garantía.

El documento enumera dos amenazas que el modelo intenta abordar, siete de implementación, once de despliegue, cuatro externas y una heredada de dependencias. No son grados de severidad. La propia T25 aparece entre las amenazas objetivo y, a la vez, aclara que el modelo de datos no impone la calidad de la identificación que hace el emisor. Esa combinación impide leer «objetivo» como «resuelto». También importa que el diccionario de procesos y flujos aún presenta definiciones iniciales sujetas a revisión.

Otra decisión pertenece al verificador desde el principio. En T1, la manipulación de afirmaciones protegidas puede descubrirse comprobando la prueba. Si la prueba se elimina por completo, no queda una prueba que la criptografía pueda fallar. Una política debe exigir la protección adecuada cuando se necesita una afirmación atribuible al emisor. El modelo permite datos sin prueba para uso intermedio o declaraciones propias; lo incorrecto sería aceptarlos como si hablaran con la autoridad de otro. Esta frontera es de política de aceptación, no de longitud de la firma.

Las amenazas de implementación muestran un problema diferente. T2 advierte que una credencial correctamente firmada puede contener marcado ejecutable peligroso para el programa que la muestra. Un monedero o servicio verificador debe tratar ese contenido como entrada no fiable: integridad y seguridad de representación son propiedades distintas. Al final del recorrido, T24 obliga a preguntar si la fuente y la naturaleza de la afirmación sirven para el propósito concreto. Una credencial auténtica y vigente puede ser la credencial equivocada para una decisión determinada.

Un registro operativo útil asociaría cada amenaza con el actor responsable, el momento de control, la medida escogida y alguna prueba de que funciona. Es una propuesta de análisis de Daniel Kade, no una plantilla exigida por W3C. La nota también cubre privacidad de consultas de estado, pero este texto no atribuye al nuevo documento la decisión sobre el puntero abreviado ni sobre statusPurpose tratada por separado en Bitstring Status List v1.1. Aquí el objeto es más amplio: el riesgo que queda sin dueño entre emisión, presentación y aceptación.

El modelo de datos v2.0 sí alcanzó el rango de Recommendation en mayo de 2025. Ni el Working Draft v2.1 ni esta nota provisional heredaron ese rango. Tampoco documentan un fallo de un proveedor concreto, una adopción medida o un resultado de conformidad. La pregunta para una organización que use credenciales es menos cómoda que «¿verifica?»: ¿qué control decidió implantar cada participante, y qué evidencia queda cuando el resultado técnico parece satisfactorio?

Fuentes