# SD-JWT — cómo funciona la divulgación selectiva Este artículo profundiza la mecánica interna de SD-JWT (Selective Disclosure JWT) para entender por qué un verificador puede confirmar atributos sin ver los datos completos. Es la pieza central del modelo de privacy en SD-JWT VC. ## El problema que SD-JWT resuelve Un JWT clásico firma toda la payload junta. Si querés ocultar parte: - No podés. Ocultarla rompe la firma. - Tenés que emitir múltiples JWTs (uno por subset de atributos). - O usar técnicas más complejas como ZKPs. SD-JWT propone una solución diferente: en vez de firmar los datos directamente, **firmar los hashes** de cada atributo. Cuando hay que presentar, se revela solo lo necesario + los hashes correspondientes. ## La estructura interna Un SD-JWT consiste en: ``` ~~~~... ``` Donde: - `` es un JWT firmado normalmente. - `` son strings que pueden o no incluirse cuando se presenta. ## Anatomía del JWT El payload del JWT incluye los hashes: ```json { "iss": "did:web:salta.gob.ar", "sub": "did:key:z6Mk...", "iat": 1714521600, "_sd": [ "K7H_5xV2bL...", "P8N_2bL3kM...", "Q3J_9wM7nP..." ], "_sd_alg": "sha-256", "vct": "ConstanciaDomicilio" } ``` - `_sd` es un array de hashes (uno por cada atributo selectively disclosable). - `_sd_alg` indica qué algoritmo de hash se usó. - Los atributos que NO están bajo `_sd` son visibles always (ej: `iss`, `iat`). ## Anatomía de un Disclosure Cada disclosure es una cadena base64url-encoded que contiene un JSON con tres elementos: ```json [ "8I-vSb04...salt", "domicilio", "Av. Belgrano 1234, Salta" ] ``` - El primer elemento es un **salt** (aleatorio, único por disclosure). - El segundo es el **nombre del atributo**. - El tercero es el **valor del atributo**. Encoded a base64url, esto es un string como `WyI4SS12U2IwNCIsImRvbWljaWxpbyIsIkF2LiBCZWxncmFubyAxMjM0Il0=`. ## La conexión entre JWT y Disclosure Cada hash en `_sd` del JWT corresponde a un Disclosure. La conexión es matemática: ``` hash = sha-256(base64url(JSON.stringify([salt, name, value]))) ``` El emisor: 1. Genera salt aleatorio por cada atributo. 2. Calcula el hash de la concatenación. 3. Incluye el hash en `_sd` y firma todo. 4. Manda al holder el JWT + los Disclosures. ## El holder presenta selectivamente Cuando el holder quiere presentar solo "nombre" y "domicilio": :::steps - Toma el JWT completo (no se modifica). - Toma solo los Disclosures de los atributos que quiere revelar. - Manda al verifier: `~~~` - Los Disclosures de otros atributos (fecha_nacimiento, etc.) NO se incluyen. ::: ## El verifier verifica El verifier recibe `~~~`. Sus pasos: :::steps - **Validar firma del JWT.** Confirma que viene del emisor genuino. - **Para cada Disclosure recibido:** - Decode base64url para obtener `[salt, name, value]`. - Calcular el hash sha-256 de `base64url(JSON.stringify([salt, name, value]))`. - Verificar que ese hash está en el array `_sd` del JWT. - **Si todos los Disclosures matchean hashes:** los atributos revelados son auténticos. - **Para los atributos no revelados:** el verifier ve los hashes pero no puede inferir el valor (los hashes son irreversibles). ::: ## Por qué los salts importan Sin salt, el ataque sería: - Si el verifier sabe que un atributo está bajo `_sd` y conoce el valor probable ("Juan", "María", etc.), puede calcular el hash de cada candidato y comparar. - Salt previene este ataque porque el atacante necesitaría adivinar el salt + el valor. Cada salt debe ser: - **Aleatorio** (no derivable). - **Único por disclosure** (no compartir entre atributos). - **Suficientemente largo** (típicamente 128 bits / 16 bytes). ## Selective disclosure de elementos en arrays SD-JWT también soporta divulgación selectiva de elementos individuales dentro de un array: ```json { "address": { "street": "Av. Belgrano 1234", "city": "Salta", "country": "Argentina" } } ``` Con SD-JWT, cada campo puede ser selectively disclosable independientemente. El holder puede revelar `country` sin revelar `street` o `city`. ## Key binding — la pieza adicional Más allá de selective disclosure, SD-JWT VC incluye **key binding** para evitar que un atacante que intercepta el JWT lo presente como suyo. El JWT incluye en `cnf` la clave pública del holder. Al presentar, el holder firma un JWT adicional (key binding JWT, KB-JWT) sobre el nonce + audience. El verifier verifica esa firma con la `cnf` clave del SD-JWT original. ``` ~~~ ``` Sin KB-JWT, alguien que intercepta el SD-JWT puede presentarlo a otro verifier. Con KB-JWT, cada presentación requiere firma fresca del holder. ## Implementación Librerías que soportan SD-JWT VC: | Lenguaje | Librería | |---|---| | JavaScript/TypeScript | `@sd-jwt/core`, `@sd-jwt/vc` | | Python | `sd-jwt-python` | | Go | `sd-jwt-go` | | Java | `sd-jwt-java` | | Rust | `sd-jwt-rs` | Implementar SD-JWT desde cero es complejo. Usar librerías validadas. ## Referencias - [SD-JWT Specification — IETF Draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/) - [SD-JWT VC Specification — IETF Draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) ## Relacionados - [SD-JWT VC — el formato preferido de Sovra](/academy/explorar/sd-jwt-vc) — formato VC sobre SD-JWT - [Selective disclosure — la revelación selectiva](/academy/explorar/selective-disclosure) — el concepto - [Hashes, salts y nonces — terminología criptográfica](/academy/explorar/hashes-sales-nonces) — terminología criptográfica

Ecosistemas Digitales: la revolución silenciosa del Estado abierto

Proyecto Federal de Integrabilidad de Datos y Servicios en la República Argentina

Los ecosistemas digitales de integrabilidad y su normalización como medio para favorecer la innovación tecnológica

Iniciativa federal para la normalización del Ecosistema Digital de Integrabilidad: Norma IRAM 17610

El proyecto de normalización del EDI. Parte A: el marco teórico

El proyecto de normalización del EDI. Parte B: el desarrollo de la norma IRAM 17610

Integrabilidad y ecosistemas digitales: problemática, fundamentos y normalización

2026 · Sovra Podcast #08 — Cómo el federalismo impulsa la interoperabilidad

2025 · Qué puede aprender Argentina de Estonia para transformar sus ciudades

2025 · Congreso Nacional de Interoperabilidad — Interopera 2025 (Colombia)

2025 · From Federalism to Digital Unification (X-Road Community Event)

2024 · Interoperabilidad: gobernanza en el despliegue de Ecosistemas Digitales de Integrabilidad

2023 · Urbanismo digital: reglas mínimas de convivencia sin bloquear la innovación

2022 · Jornada de sensibilización sobre Ecosistemas Digitales de Integrabilidad (EDI)

2022 · Del gobierno digital al gobierno inteligente

2019 · Principios y acciones de una transformación digital exitosa

2018 · De Estonia a Argentina: el fin de la burocracia en los gobiernos (TEDx)

Integrabilidad vs. interoperabilidad — la distinción que cambia el diseño

La norma IRAM 17610-1: qué exige, en cuatro dimensiones

Gobernanza dinámica de un EDI — círculos, consentimiento y las dos caras de la autoridad

Urbanismo digital — reglas mínimas para un espacio público compartido

Los EDI provinciales argentinos — qué hizo cada jurisdicción y en qué orden

Federar ecosistemas — de siete EDI provinciales a una Red Federal