Resumen
- RFC 9901 permite que el titular entregue ninguna, algunas o todas las Disclosures emitidas; cada valor entregado puede enlazarse criptográficamente con el JWT firmado por el emisor.
- La integridad de lo entregado no prueba que falten datos irrelevantes, que una afirmación siga siendo cierta hoy ni que una política local deba autorizar una acción.
La frase «no se presentó ningún dato en contra» parece inocente. En un sistema de divulgación selectiva es una conclusión que el formato no permite. La ausencia puede ser una elección legítima del titular, una afirmación que no era divulgable, un digest señuelo o simplemente una condición que el verificador nunca pidió.
El SD-JWT de RFC 9901 está diseñado para preservar esa elección. El emisor firma un JWT. Para una afirmación revelable no pone necesariamente el valor legible en la carga: coloca un digest. La Disclosure contiene sal aleatoria, nombre cuando corresponde y valor. El titular recibe el conjunto completo al emitirse y, al presentarlo, remite sólo las Disclosures que decide. El verificador vuelve a calcular el digest y confirma que aparece en el objeto firmado.
Esa comprobación responde una pregunta concreta: ¿esta afirmación presentada pertenece al compromiso firmado por este emisor? No responde otra: ¿el conjunto presentado describe todas las condiciones relevantes? El RFC permite expresamente al titular mandar cualquier subconjunto. También permite afirmaciones permanentemente visibles y digests de señuelo. La forma fue pensada para que lo no revelado no se convierta en información accidental.
Conviene escribir la cadena sin atajos. El emisor produjo una estructura y definió qué podía revelarse selectivamente. El titular eligió una presentación. El verificador validó firmas y digests de esa presentación. Una aplicación interpretó los nombres, aplicó su regla y quizá ejecutó algo. Una firma válida en la tercera etapa no puede firmar retrospectivamente la semántica de la cuarta ni la consecuencia de la quinta.
Tampoco el registro de nombres resuelve la semántica. RFC 7519 define cómo se representan claims y el registro IANA coordina identificadores. Ni uno ni otro dice qué observación llevó al emisor a afirmar un valor, cuánto tiempo sigue siendo apropiado o qué institución debe aceptar el valor para una operación. RFC 8725 recuerda que los usos de JWT necesitan tipos explícitos y reglas de validación propias del caso de uso. Un objeto correcto de una clase equivocada sigue siendo una mala entrada para la decisión.
Key Binding ofrece una prueba distinta, no una autorización escondida. Si la política del verificador lo exige, el titular presenta un KB-JWT firmado con su clave privada. El documento enlaza el hash del SD-JWT, un nonce fresco y una audiencia. Así se puede probar posesión de la clave para esa presentación. No se prueba que el titular mostró todo, que el emisor investigó cada valor en el presente, ni que la solicitud merece el resultado pretendido.
El caso sin Key Binding es igual de instructivo. RFC 9901 indica que quien posee un SD-JWT puede reenviarlo a un tercero que no exija Key Binding y puede eliminar Disclosures. Por eso un artefacto recibido no es automáticamente evidencia de la persona presente, del destinatario original o de una transacción viva.
El estándar protege los controles que no se deben esconder: el emisor no debe hacer divulgable selectivamente contenido crítico para autenticidad o validez; qué contenido es crítico depende del perfil. El verificador debe comprobar la firma del emisor y que los digests correspondan a las Disclosures. La organización debe completar lo que el estándar deja local: qué conjunto de claims exige, qué ausencia tolera, quién decide y cómo registra un resultado.
Para una auditoría útil, guarde el tipo y perfil del token, emisor y política de clave, claims exigidos, claims presentados, resultado de cada digest, requisito de Key Binding, nonce, audiencia, versión de la política y transición final. «Credencial validada» mezcla pruebas que pueden haber sucedido en lugares distintos o no haber sucedido nunca.
La distinción de Heng Lu entre representación, decisión localizada y resultado ejecutado ayuda a conservar las proporciones. RFC 9901 hace portable una afirmación limitada y preserva privacidad. No concede a la interfaz el poder de convertir una selección en una biografía completa ni al verificador el derecho de imaginar los datos faltantes.
Sources
- RFC 9901 — Selective Disclosure for JSON Web Tokens
- RFC 7515 — JSON Web Signature
- RFC 7519 — JSON Web Token
- RFC 7800 — Proof-of-Possession Key Semantics for JWTs
- RFC 8725 — JSON Web Token Best Current Practices
- Registro IANA de claims JWT
- RFC 8174 — Ambigüedad de palabras clave RFC 2119
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision
- Lu Heng — Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

