Credenciales verificables y SD-JWT
Las credenciales verificables permiten que un emisor formule claims resistentes a alteraciones, que pueden ser custodiados y posteriormente presentados a un verificador. SD-JWT añade un mecanismo estandarizado para divulgar selectivamente elementos individuales de una estructura JSON firmada.
UbID utiliza estos conceptos para separar la evidencia firmada por el emisor, la decisión del titular sobre qué presentar y la decisión del verificador sobre si la evidencia resulta suficiente.
El modelo de confianza de las credenciales
Una interacción con credenciales normalmente incluye:
- un emisor que formula y firma claims;
- un titular que recibe y controla la credencial;
- una Wallet o servicio del titular que la protege y presenta;
- un verificador que valida la evidencia y aplica política;
- un sujeto, que puede coincidir o no con el titular.
Una firma válida establece integridad y procedencia de la clave del emisor. Por sí sola, no establece que el emisor sea confiable para el claim, que la evidencia esté vigente ni que la transacción deba aprobarse.
Semántica de Verifiable Credentials
El W3C Verifiable Credentials Data Model define un modelo conceptual común para emisores, titulares, sujetos, credenciales, presentaciones, claims, schemas y estado. No exige un único formato universal de prueba criptográfica.
Un perfil de credencial todavía debe definir:
- tipo de credencial y significado de los claims;
- campos obligatorios y opcionales;
- identificadores de emisor y sujeto;
- comportamiento de validez y estado;
- envelope criptográfico y algoritmos permitidos;
- requisitos de holder binding;
- reglas de presentación y verificación.
UbID trata VC Data Model 2.0 como una referencia semántica importante. Las rutas actuales de credenciales UbID también utilizan formatos JWT de divulgación selectiva, y cada perfil de credencial debe declarar su modelo exacto de conformidad.
Divulgación selectiva con SD-JWT
SD-JWT permite que un emisor firme commitments de valores seleccionados de claims, en lugar de colocar todos los valores directamente en el payload firmado visible. El titular conserva las disclosures asociadas y revela solo las necesarias para una presentación.
El verificador reconstruye la vista divulgada y valida que cada disclosure corresponda a un commitment protegido por la firma del emisor.
Esto respalda la minimización, pero no impide automáticamente la correlación. Identificadores estables, combinaciones únicas de claims, timestamps, identificadores de credenciales, comportamiento del verificador y patrones repetidos de presentación todavía pueden producir vinculación.
SD-JWT y SD-JWT VC no son lo mismo
La distinción es importante:
| Término | Alcance |
|---|---|
| SD-JWT | Mecanismo IETF de divulgación selectiva para datos JSON y claims JWT. |
| SD-JWT VC | Perfil de credencial que define formato y reglas de procesamiento para credenciales digitales verificables basadas en SD-JWT. |
| W3C VC Data Model | Modelo semántico para credenciales y presentaciones, independiente de un único formato de prueba. |
| VC protegida con JOSE/COSE | Enfoque W3C para aplicar mecanismos JOSE, SD-JWT o COSE a credenciales conformes con el modelo de datos VC. |
En la baseline editorial de este portal, SD-JWT es un RFC del IETF Standards Track, mientras el perfil IETF SD-JWT VC continúa en desarrollo. La documentación de UbID debe fijar la versión de perfil utilizada por cada despliegue y no describir soporte a un borrador como conformidad universal con un estándar final.
Holder binding
Una credencial puede vincularse criptográficamente con material de claves controlado por el titular. Durante la presentación, este puede demostrar control de la clave pertinente y vincular la presentación con el verificador, audiencia, nonce o transacción.
Holder binding puede reducir el riesgo de robo y replay de credenciales, pero no reemplaza consentimiento, seguridad del dispositivo, controles de estado ni política del verificador. Algunos casos de uso pueden requerir un modelo bearer o delegado; el perfil debe declarar la elección explícitamente.
Estado y ciclo de vida
Una credencial puede seguir correctamente firmada y, aun así, estar expirada, suspendida, revocada, reemplazada o fuera de la política aceptada. La verificación considera:
- confianza del emisor y material de firma;
- firma y política de algoritmos;
- período de validez;
- estado de la credencial;
- versión de schema y perfil;
- holder binding cuando sea necesario;
- vigencia y audiencia de la presentación;
- claims solicitados y finalidad;
- política del verificador.
Minimización de datos y comprobantes
Un verificador debe solicitar únicamente los claims necesarios para la finalidad declarada. También debe minimizar el comprobante retenido después de verificar. Conservar la presentación completa solo porque se utilizó divulgación selectiva puede anular el beneficio de privacidad.
Posición de UbID
Las credenciales JWT de divulgación selectiva forman parte de la baseline implementada y de transición de UbID. La semántica W3C VC, los perfiles SD-JWT VC, mecanismos de estado y contratos de presentación se gobiernan por tipo de credencial y perfil de partner.
Ningún ejemplo público de este portal representa una credencial productiva, schema de cliente, clave real ni política completa de aceptación.
Estándares fuente
- W3C Verifiable Credentials Data Model v2.0
- W3C Verifiable Credentials Overview
- W3C Securing Verifiable Credentials using JOSE and COSE
- IETF RFC 9901 — Selective Disclosure for JSON Web Tokens
- IETF SD-JWT VC work item
Consulta Divulgación selectiva, Ciclo de vida de credenciales y Verificación y política.