SD-JWT VC — el formato preferido de Sovra

SD-JWT VC —Selective Disclosure JWT Verifiable Credentials— es el formato concreto de credenciales verificables que combina el modelo W3C VC con el formato JWT (JSON Web Tokens) + capacidades nativas de divulgación selectiva (selective disclosure).

Es el formato canonical en Sovra y el formato obligatorio en eIDAS 2.0 para la EUDI Wallet europea. Es probablemente el formato que más vas a encontrar en proyectos gov modernos.

La estructura básica

Una credencial SD-JWT VC tiene esta estructura:

<JWT-header>.<JWT-payload>.<JWT-signature>~<disclosure-1>~<disclosure-2>~<disclosure-3>~

Tres partes separadas por puntos (el JWT clásico) + N partes separadas por tildes (~) que son las "disclosures" — fragmentos individuales que se pueden mostrar u ocultar selectivamente.

El JWT base

Es un JWT estándar (RFC 7519) con estructura:

Header:

{
  "alg": "ES256",
  "typ": "vc+sd-jwt",
  "kid": "did:web:salta.gob.ar#key-1"
}

Payload:

{
  "iss": "did:web:salta.gob.ar",
  "sub": "did:key:z6Mk...",
  "iat": 1714521600,
  "exp": 1746057600,
  "vct": "ConstanciaDomicilio",
  "_sd": [
    "K7H_5xV...",
    "P8N_2bL...",
    "Q3J_9wM..."
  ],
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": { "kty": "OKP", "crv": "Ed25519", "x": "..." }
  }
}

Los _sd son hashes de los disclosures. Cada disclosure se publica como una cadena base64url-encoded que contiene [salt, claim_name, claim_value].

El flujo de selective disclosure

1. 1
   Emisor crea la credencial: elige qué atributos hace selectively disclosable. Para cada atributo, genera un salt aleatorio + el hash, incluye el hash en _sd, y genera la cadena disclosure.
2. 2
   Emisor firma todo el JWT con su clave privada. El JWT incluye solo los hashes, no los disclosures.
3. 3
   Holder recibe el JWT + las disclosures. Las guarda en su wallet.
4. 4
   Holder presenta a un verificador: elige qué disclosures revelar. Envía JWT + solo los disclosures de los atributos que decide mostrar.
5. 5
   Verifier recibe JWT + N disclosures. Verifica firma del emisor en JWT. Para cada disclosure recibido, computa su hash y verifica que está en _sd. Si todos los hashes recibidos coinciden con _sd, los disclosures son auténticos.

El verificador puede confirmar que los atributos revelados son auténticos sin ver los no revelados, porque los hashes están firmados y no se pueden falsificar.

Ejemplo concreto

Credencial original con 3 atributos:

{
  "nombre": "Juan Pérez",
  "fecha_nacimiento": "1985-03-15",
  "domicilio": "Av. Belgrano 1234"
}

SD-JWT generado (estructura simplificada):

• Header + payload con _sd: [hash_nombre, hash_fecha, hash_domicilio]
• 3 disclosures: [salt_1, "nombre", "Juan Pérez"], etc.

Presentación seleccionando solo "nombre" y "domicilio":

• JWT completo (sin cambios — la firma sigue válida).
• Solo 2 disclosures: nombre + domicilio. El de fecha_nacimiento queda oculto.

Verifier:

• Verifica firma del JWT.
• Computa hashes de los 2 disclosures recibidos.
• Confirma que hash_nombre y hash_domicilio están en _sd del JWT.
• Acepta los atributos como auténticos sin saber qué hay en hash_fecha.

El key binding

SD-JWT VC también soporta key binding: el JWT incluye en cnf la clave pública del holder. Esto permite que el verificador exija una firma del holder (sobre un nonce + el JWT) para confirmar que la presentación viene del legítimo holder, no de alguien que copió el JWT.

Adopción

SD-JWT VC es respaldado por:

Más implementaciones en Apple Wallet, Google Wallet, walt.id, Trinsic, varios proyectos gov en LATAM.

Las ventajas vs JWT clásico

Referencias

• SD-JWT VC IETF Draft
• SD-JWT Specification

Relacionados

• W3C Verifiable Credentials Data Model 2.0 — el modelo conceptual
• Selective disclosure — la revelación selectiva — el patrón habilitado
• SD-JWT — cómo funciona la divulgación selectiva — cómo funciona internamente