Resumen

  • El emisor sustituye el texto claro de los elementos divulgables por resúmenes en la carga útil firmada y entrega Disclosures separadas al titular. El titular elige cuáles presentar; el verificador recalcula sus resúmenes y reconstruye la carga útil procesada.
  • Una Disclosure de una propiedad de objeto contiene sal, nombre de la afirmación y valor. Una Disclosure de un elemento de matriz contiene sal y valor. Las sales deben ser aleatorias, independientes y únicas por afirmación, y permanecer ocultas hasta la divulgación; la RFC recomienda al menos 128 bits aleatorios.
  • _sd_alg, en el nivel superior, selecciona el resumen. No se permite anidarlo, su ausencia implica sha-256 y las implementaciones deben admitir sha-256. El JWT firmado por el emisor debe estar firmado, nunca usar none, y verificarse antes de cada Disclosure presentada.

La RFC 9901 es una especificación Standards Track, no un mecanismo de cifrado. No permite recuperar afirmaciones no divulgadas, no sustituye el transporte confidencial y no convierte una presentación en una prueba de conocimiento cero ni en una credencial anónima. El control se reparte en una cadena: diseño de divulgación del emisor, elección del titular, política del verificador y, cuando corresponde, prueba de posesión de una clave.

La estructura puede ser recursiva. Un hijo oculto puede depender de que se divulgue su padre; por ello, una presentación sin esa dependencia es inválida aunque la Disclosure del hijo esté bien formada por separado. Los resúmenes señuelo pueden ocultar el número o la existencia original de afirmaciones ocultas, pero aumentan el tamaño del token. Mitigan un canal lateral; no impiden la correlación ni garantizan la desvinculación.

La vinculación de clave es opcional salvo que la exija un perfil o caso de uso. Cuando se utiliza, el SD-JWT lleva la clave pública del titular o una referencia, y el titular firma un KB-JWT con typ kb+jwt, iat, aud, nonce y sd_hash. sd_hash vincula el KB-JWT con el JWT exacto del emisor y las Disclosures seleccionadas. El verificador que la exige valida la clave, firma, algoritmo, tipo, ventana temporal, audiencia, nonce y esa vinculación.

El verificador debe rechazar una firma del emisor inválida, none, una declaración de resumen incorrecta o mal ubicada, un resumen de Disclosure que no coincida, una reconstrucción mal formada, una dependencia recursiva ausente o una afirmación requerida que falte. Los perfiles deben decidir qué afirmaciones son necesarias: hacer exp divulgable, por ejemplo, puede impedir que el verificador disponga del dato necesario para rechazar la presentación. El transporte debe ser confidencial cuando importen la privacidad o la correlación pasiva; la RFC 9901 no define cifrado y depende del protocolo de transporte. El almacenamiento debe limitarse, porque sales, Disclosures y material estable de la credencial pueden aumentar la correlación.

Análisis de Theo March — no es un mandato de la RFC. Los emisores deberían definir un esquema de divulgación mínima; los verificadores pedir solo la evidencia exigida por su política; las interfaces de consentimiento explicar cada Disclosure; los registros evitar el texto claro innecesario; la aplicación definir callbacks de revocación; y el ciclo de vida de las claves cubrir rotación, pérdida y recuperación. La emisión por lotes con sales y claves de titular nuevas puede mejorar la desvinculación entre algunos verificadores y presentaciones. Nada de ello es automático, y aquí se desconocen la adopción, el rendimiento, la situación jurídica y el comportamiento de los monederos.

El límite es explícito: una credencial estable firmada por el emisor puede permitir que emisores y verificadores coludidos reconozcan la misma credencial. La emisión por lotes puede mejorar ciertas formas de desvinculación entre verificadores, pero no ofrece desvinculación entre emisor y verificador frente a la colusión. La divulgación selectiva redistribuye la confianza; no la elimina.

Comprobaciones de conformidad

  1. Confirmar que la RFC 9901 gobierna el SD-JWT y que RFC 7515/7519 solo aportan la base JWS/JWT.
  2. Para cada propiedad y elemento de matriz, verificar una sal aleatoria, independiente y única de al menos 128 bits.
  3. Comprobar _sd_alg en el nivel superior, el valor predeterminado sha-256, la ausencia de anidamiento y el soporte del algoritmo.
  4. Verificar la firma, rechazar none, recalcular cada resumen y exigir todas las dependencias recursivas.
  5. Si se exige vinculación de clave, validar kb+jwt, iat, aud, nonce, sd_hash, clave, firma y ventana temporal.
  6. Probar afirmaciones requeridas ausentes, presentaciones mal formadas, replay, transporte confidencial y retención limitada.

Ruta de decisión del operador

Comenzar por la evidencia mínima que necesita el verificador. Si un dato no debe verse, hacerlo divulgable y entregar su Disclosure por separado. Para un elemento sensible de matriz, construir independientemente la Disclosure de sal y valor; para una propiedad, la de sal, nombre y valor. Añadir señuelos solo cuando el beneficio contra el canal lateral justifique el tamaño. Exigir vinculación de clave únicamente si el perfil necesita demostrar posesión por el presentador, y entonces aplicar toda la lista del KB-JWT.

En otro caso, validar firma y cadena de Disclosures, rechazar afirmaciones de política ausentes, usar transporte confidencial, limitar el almacenamiento y documentar las limitaciones de correlación.

Fuentes