1.6k PUNTOS DE VISTA
Pinterest LinkedIn LÍNEA

1. Nacimiento del RFC 9901

19 de noviembre de 2025, "Divulgación selectiva para tokens web JSON", también conocido como. SD-JWT Las especificaciones que definen (SDJOT) RFC 9901 Fue lanzado como.

Los autores son las siguientes tres personas.

Token web JSON (JWT) [RFC 7519]と Firma web JSON (JWS) [RFC 7515]Esficha de identificaciónやToken de acceso JWT [RFC 9068]Es un estándar de Internet que se ha utilizado ampliamente en
SD-JWT nos brinda la nueva capacidad de extraer y mostrar únicamente las partes que necesitaremos posteriormente.

En el linaje de la familia JOSE (JWS / JWT / JWE),
Esto puede considerarse como la adición de un nuevo pilar llamado "Divulgación Selectiva" como RFC oficial.

2. ¿Para qué sirve la especificación SD-JWT?

2-1. Problemas con los JWT convencionales: "emitidos a demanda" o "todo incluido".

Los JWT tradicionales se basaban en un modelo en el que un "bloque de JSON firmado" se pasaba directamente al servicio.

  • El emisor (IdP o servidor de autenticación) compila la información del usuario en un JWT.
  • El servicio receptor (parte que confía en él) puede leer el contenido completo.

Esto significa que, si se utiliza un modelo como OpenID Connect, donde los certificados se emiten dinámicamente según sea necesario, es posible lograr la divulgación selectiva, la minimización de datos y la imposibilidad de vinculación entre las partes de referencia (RP+RP'-U), generalmente mediante PPID (Identificador Pseudónimo por Pares). Sin embargo, si se desea emitir un certificado por adelantado sin conocer su propósito y luego usarlo, surge el problema de que ninguna de estas opciones es posible.

Por ejemplo, si un único JWT contiene "edad", "dirección", "nombre" y "dirección de correo electrónico", el servidor solo necesitará saber si el usuario tiene más de 20 años, pero si utiliza un JWT que se ha emitido y guardado con antelación, podrá ver todo, incluyendo la dirección y el nombre.

Esta estructura "todo en uno" es sencilla de implementar, pero si quieres guardar y usar,

  • La divulgación selectiva no es posible; por lo tanto, no se puede cumplir el principio de minimización de la recopilación de datos.
  • La desvinculación de RP+RP'-U tampoco se cumple.

Estas eran las limitaciones (aunque esto suponía un precio a pagar por la simplicidad de la implementación).

2-2. Compatibilidad con modelos de billetera

Por otro lado, sin duda existen casos en los que se desea utilizar los datos guardados posteriormente. Algunos ejemplos típicos incluyen su uso en lugares sin cobertura o la presentación de un certificado de graduación tras el cierre de un centro educativo. Uno podría preguntarse: "¿Es realmente tan común no tener cobertura?", pero esto se debe a que Japón se encuentra en una zona con una cobertura favorable. En Europa, la calidad de la señal es deficiente, sobre todo en el interior de edificios de piedra, e incluso a poca distancia de la estación, se puede perder la señal incluso al aire libre, incluso en grandes ciudades como Mannheim. Esto también ocurre, por supuesto, en los Estados Unidos. Quizás por esta razón, en Europa, Monedero EUDI Entre las carteras de identidad recientes se incluyen:

  • Una sola billetera (aplicación para teléfono inteligente) puede gestionar múltiples transacciones. Credenciales Verificables (VC) Ahorra el
  • El usuario selecciona "Mostrar solo este elemento para este servicio" y lo presenta.

Este modelo es la premisa. En este caso, la billetera y el emisor solo necesitan estar conectados en línea al momento de la emisión.

Lo que se necesita aquí es

"Un formato que permite seleccionar y mostrar de forma segura una parte de un archivo de datos firmado almacenado posteriormente."

Esto se define por RFC 9901 Esto es SD-JWT.

3. SD-JWT en pocas palabras

En términos generales, SD-JWT funciona de la siguiente manera:

  1. La base es la misma que antes. JWT firmado (JWS)
  2. Sin embargo, algunas afirmaciones sonSolo el valor hash" en el JWT
  3. Valor original y sal combinados Divulgación Manténgalo separado y entrégueselo al verificador solo cuando sea necesario.
  4. El verificador es
    • Recalcular el hash a partir de la divulgación
    • Al verificar que coincide con el hash del JWT firmado
    • Puedes confirmar que "efectivamente forma parte de los datos firmados por el emisor".

Además, para evitar la transferencia no autorizada de tokens, Un mecanismo para vincularse al par de claves de un usuario (enlace de claves). también están disponibles.
La estructura combinada SD-JWT+KB Llámalo

4. Tres caracteres y el flujo de SD-JWT

El elenco básico de personajes en SD-JWT es el mismo que en el mundo de VC.

  • Editor
    Oficinas gubernamentales, bancos, universidades, etc. Organizaciones responsables de los hechos.
  • Titular
    El propio usuario almacena las credenciales en la aplicación de monedero de su teléfono inteligente.
  • Verificador
    Proveedores de servicios, como apertura de cuentas bancarias, verificación de edad y control de acceso.

El flujo típico es el siguiente:

  1. Emisión
    • El emisor recopila la información de los atributos del usuario (dirección, fecha de nacimiento, etc.) en formato JSON.
    • En cuanto a "los elementos que le gustaría revelar selectivamente más adelante",
      Calcula un hash a partir del valor más un valor aleatorio de salt e inserta solo ese hash en el JWT.
    • El valor original + sal se prepara por separado como una divulgación.
    • El JWT firmado y las múltiples divulgaciones se agrupan y se entregan al titular como un "SD-JWT".
  2. Presentación
    • Un usuario intenta utilizar un servicio
    • La cartera selecciona únicamente las divulgaciones que desea mostrar al verificador del SD-JWT.
    • Enviar el JWT firmado + la divulgación seleccionada + (y el JWT de enlace de clave, si es necesario) al verificador.
  3. Verificación
    • El verificador es
      • Verifique la firma JWT con la clave pública del emisor.
      • Utilice Disclosure para recalcular el hash de cada elemento y verificar que coincida con el hash del JWT.
    • Esto garantiza que los datos formen parte de los datos firmados por el emisor, al tiempo que protege los elementos no divulgados.

5. Un poco de charla técnica: Sal y divulgación

5-1. Divulgación selectiva mediante hash con sal

Cada reclamación (dirección, fecha de nacimiento, etc.)

  • Sal + Valor + (posiblemente nombre de la reclamación)

Calcula el hash del JWT e inserta el valor del hash en el JWT.

Al divulgar información, debe indicarse como "Divulgación".

  • "Sal, Nombre de la reclamación, Valor"

al verificador.

El verificador recalcula el hash utilizando el mismo procedimiento y comprueba si coincide con el hash del JWT para ver si ha sido manipulado.
La sal dificulta adivinar el valor de las reclamaciones no reveladas.

5-2. Divulgación

La RFC define una Divulgación como una matriz JSON codificada en Base64url, por ejemplo:

  • Elemento 0: Sal
  • Elemento 1: Nombre de la reclamación (puede omitirse para elementos de matriz)
  • Elemento 2: Valor de la reclamación

Dentro de la cartera,

"Conserva una credencial grande como una colección de pequeñas divulgaciones y envía solo lo que necesites."

Creo que es más fácil de entender si lo piensas de esta manera.

5-3. Asignación de teclas y SD-JWT+KB

Solo con SD-JWT, persiste el riesgo de un ataque (ataque de repetición) en el que un token es copiado y presentado por otra persona.
Por lo tanto, el RFC 9901 especifica un mecanismo para vincular un SD-JWT al par de claves de un Holder. Clave de enlace define:

  • Incluya la clave pública del titular (o una referencia a ella) en el SD-JWT.
  • El titular firma con esa llave al ser presentada. JWT con enlace de teclas (KB-JWT) Enviar juntos
  • El verificador es
    • SD-JWT y KB-JWT están vinculados a la misma clave.
    • Verifique que el titular realmente posee la clave privada.

Ahora se requiere la configuración de teclas. SD-JWT+KB Esto aumentará la resistencia a la copia de VC.

注La vinculación del titular puede ser mediante clave, reclamación o datos biométricos. +KB implementa la vinculación mediante clave. Sin embargo, con este método, si se transfiere el dispositivo u otro medio que almacena la clave, alguien podría suplantar su identidad (lo que se conoce como ataque de suplantación de identidad). La compraventa de una cuenta bancaria es un ejemplo perfecto. Para evitarlo, generalmente se requiere la vinculación biométrica.

5-4. Compatibilidad con estructuras y matrices JSON

El RFC 9901 va más allá del simple JSON plano.

  • Objetos anidados
  • Divulgación elemento por elemento de matrices
  • Ocultar patrones con "hashes ficticios (resúmenes señuelo)"

También define cómo manejar estos casos.

Este

  • Evitar que la gente adivine que "todos tienen las mismas credenciales".
  • Reduzca el riesgo de ser rastreado únicamente por la cantidad de artículos divulgados.

Esto permite concebir ideas como las siguientes:

6. Carteras de identidad SD-JWT y VC

6-1. SD-JWT VC: Posicionamiento como formato VC

La IETF utiliza SD-JWT en el RFC 9901. Una especificación para expresar credenciales verificables Como
"Credenciales verificables basadas en SD-JWT (SD-JWT VC)" Se está preparando un borrador.

Esto es

  • VC en formato JSON
  • SD-JWT permite la divulgación selectiva
  • Determinar el método de verificación

Esta especificación tiene la siguiente función. Actualmente, el grupo de trabajo está en revisión antes de su última convocatoria, y yo también participo en su revisión.Aproximadamente 28 mejoras editoriales(Algunas de las sugerencias pueden considerarse técnicas). (Estas sugerencias incluyen dividir oraciones largas y difíciles de leer cuando las escriben estadounidenses o alemanes, abordar el problema de la ambigüedad en la identificación del ejecutor de las obligaciones debido al uso excesivo de la voz pasiva, y consideraciones de seguridad, privacidad y equidad). Además, para verificar los ejemplos incluidos en el borrador de la especificación, hemos creado una página estática HTML/JavaScript.decodificador sd-jwt" también fue creado.También está disponible en GitHub.(Es solo una página HTML, por lo que se puede ejecutar fácilmente de forma local; la necesitaba para verificar el borrador en un avión), así que si encuentra algún error, envíe una solicitud de extracción.

6-2. Usar con monedero EUDI

Comisión Europea Marco de referencia de arquitectura EUDI (ARF) Por lo tanto, el estándar que se utilizará en las carteras de identificación digital europeas es:

  • OpenID para credenciales verificables (OpenID4VCI / OpenID4VP)
  • SD-JWT / SD-JWT VC
  • ISO/IEC 18013-5 Permiso de conducir móvil (mDL)

Se ha demostrado que se puede utilizar una combinación de lo siguiente.

En este contexto, el RFC 9901 establece:

"VC almacenado en monederos de identidad como los monederos EUDI
Formato principal para la implementación basada en JWT/JOSE

Se ubica de la siguiente manera.

6-3. Beneficios desde la perspectiva de los usuarios de billeteras digitales

La experiencia general del usuario será más o menos así:

  • Confirmación de edad
    En las tiendas de conveniencia, solo necesitas demostrar que tienes más de 20 años, no tu fecha de nacimiento.
  • Verificación de domicilio
    Proporcione únicamente la dirección requerida para la entrega en el sitio de compras en línea y oculte otros atributos.
  • Conozca a su cliente (KYC)
    Presente únicamente los atributos necesarios a los bancos y compañías de valores, y reutilice la misma VC para otros servicios.

Todo esto es posible gracias a la naturaleza de SD-JWT, que permite dividir un único conjunto de datos firmado en partes más pequeñas y extraer solo las partes necesarias.

7. Expansión del ecosistema (descripción general)

Varias soluciones de código abierto y comerciales ya están incorporando SD-JWT/SD-JWT VC en sus implementaciones.

  • Compatibilidad con SD-JWT en diversos frameworks de monederos:Fundación Siros Una de ellas es wwWallet, desarrollada por .
  • Suministro de endpoints de emisión de SD-JWT VC por parte de Authlete y otras organizaciones
  • Adopción en el proyecto EUDI Wallet y la iniciativa SPRIND
  • La Fundación OpenID ha desarrollado un Perfil de Alta Seguridad (HAIP) que combina OpenID4VC y SD-JWT VC.

El RFC 9901 se posiciona como una "pieza fundamental" en la cima de este movimiento.

8. Resumen

  • RFC 9901 Es un estándar de Internet que otorga a JWT/JWS la capacidad de "divulgar selectivamente".
  • SD-JWT es
    • El JWT firmado contiene únicamente el hash.
    • El valor original y la sal se presentan como información adicional solo cuando sea necesario.
    • Sin embargo, la firma del emisor sigue garantizando la autenticidad.
      Define el formato.
  • Se agregó la función de enlace de teclas SD-JWT+KB Esto permite una presentación segura vinculada al propietario de la cartera.
  • En combinación con el borrador SD-JWT VC, EUDI ARF y el perfil OpenID4VC,
    Uno de los formatos principales para el capital riesgo almacenado en carteras de identidad Se utilizará como.

Esta nueva pieza se ha añadido a la familia de tecnologías JOSE/JWT, y se puede decir que se ha esclarecido un patrón de implementación realista para la infraestructura de identidad digital basada en monederos.