Una credencial SD-JWT puede heredar un tipo, no la autoridad del emisor

Resumen

• El 1 de septiembre, el IESG abrió una Last Call sobre SD-JWT VC -19. El grupo OAuth solicita su publicación como Proposed Standard y el plazo de comentarios termina el 15 de septiembre.
• vct identifica el tipo principal de la credencial; aka_vcts permite que el emisor declare tipos adicionales; extends crea herencia entre documentos de Type Metadata.
• Las tres piezas sirven para procesar y hacer coincidir credenciales. El borrador prohíbe usarlas como sustituto de la comprobación independiente de la autoridad del emisor.
• También exige distinguir al editor de Type Metadata: que un documento sea accesible e íntegro no demuestra que su editor esté facultado para definir ese tipo.
• Un recibo de autoridad gestionado por cada ecosistema puede conservar ambas decisiones sin crear un registro universal del IETF.

El estándar reconoce la forma; el ecosistema reconoce al actor

La noticia no es que una firma digital deje de importar. Es que el IETF está tratando de impedir que una verificación técnica se convierta, por comodidad, en una conclusión institucional. El IESG puso la revisión -19 en Last Call el 1 de septiembre. El proceso público termina el día 15. La ficha del Datatracker seguía sin fecha de telechat, con revisión de IANA pendiente y sin resolución final.

SD-JWT VC parte de RFC 9901. El emisor firma una carga JSON. Algunas propiedades aparecen en claro y otras quedan representadas por resúmenes criptográficos, de modo que el titular pueda revelar solo las que necesite. El verificador comprueba la firma, las revelaciones y, si su política lo exige, la vinculación de la credencial a una clave controlada por el titular.

El nuevo borrador convierte esa mecánica en un formato de credencial. Exige un vct, un identificador sensible a mayúsculas y minúsculas que señala el tipo. Sin embargo, el documento no registra tipos concretos. Son los ecosistemas quienes deben fijar su semántica, los campos admitidos u obligatorios y las políticas adicionales de expedición y validación.

Esa ausencia no es una laguna accidental. Mantiene fuera del formato una decisión que depende de leyes, contratos, programas de acreditación y comunidades distintas. El problema aparecería si una implementación rellenara el hueco con una inferencia automática: «conozco este tipo, por tanto confío en quien lo expide».

Dos mecanismos de parentesco, ninguna habilitación automática

En Type Metadata, extends permite que un tipo derive de otro. El consumidor procesa primero el tipo padre y arrastra sus reglas. La variante hija puede añadir información, pero no convertir en opcional un claim que el padre marcó como obligatorio ni rebajar una regla cerrada sobre divulgación selectiva. La herencia tiene, por tanto, un valor operativo real.

aka_vcts resuelve otra necesidad. Es una lista opcional, afirmada por el emisor, con otros tipos a los que la credencial dice pertenecer. Ayuda cuando un verificador pidió una categoría general y recibe una especialización. No depende de que haya Type Metadata, no tiene un orden significativo y no exige que sus valores estén unidos mediante extends.

Precisamente por esa flexibilidad, el borrador coloca una advertencia fuerte. Un actor hostil puede imitar un tipo legítimo o declarar que lo extiende. Los verificadores y titulares no deben aceptar la credencial solo por esa relación. Deben comprobar por separado la identidad del emisor, su condición de confianza y la acreditación o inscripción registral pertinente. La lista aka_vcts vale tanto como el emisor que la firma; no acredita a ese emisor.

La regla puede expresarse de manera sencilla. La jerarquía contesta qué clase de objeto dice ser la credencial. La autorización contesta quién permitió a este actor producirla. Una relación entre tipos no puede crear una relación entre instituciones.

El editor de metadatos necesita su propio mandato

La arquitectura incluye un tercer papel, Publisher, que publica Type Metadata u otros documentos auxiliares. Puede ser una organización de normalización, una comunidad o una autoridad del esquema y no tiene por qué coincidir con el emisor. Sus metadatos pueden proporcionar nombres, representación visual, reglas de claims y relaciones extends.

Un cliente puede recuperar el documento por HTTPS y comprobar su integridad. Eso protege el trayecto y la versión; no otorga competencia al editor. La sección 7.8 dice que el consumidor no debe suponer que los metadatos son correctos o significativos salvo que reconozca al editor como autoridad para el tipo. Recomienda que los ecosistemas definan mecanismos de gobernanza o acreditación que nombren a los editores autorizados y las condiciones de confianza.

Así aparecen dos comprobantes independientes. El primero explica por qué el emisor puede expedir esa credencial. El segundo explica por qué el editor puede definir o describir ese tipo. Un diseño sólido puede obtener ambos de la misma entidad, pero aun así debería registrar las dos funciones, porque su vigencia o alcance pueden divergir.

Una firma no nombra al regulador

La revisión -19 exige validar que la clave usada para firmar pertenece al emisor a través de un método admitido por la política aplicable. Si no se puede establecer, la credencial se rechaza. Esa comprobación responde con rigor a «¿quién controló la clave que protegió estos datos?».

La pregunta de autoridad es distinta. Una empresa puede controlar perfectamente su clave y no estar autorizada a expedir permisos públicos. Un editor no acreditado puede servir un árbol de metadatos coherente. Un hash correcto puede demostrar que el contenido no cambió, aunque nadie hubiese facultado a su autor.

La noción de blanqueo de mandato de Heng Lu describe el salto. Un envoltorio técnico empieza a circular como si fuera la fuente de la facultad que solo debía transportar. En una cartera, el salto puede ocultarse tras la palabra «verificada». Si ese estado agrupa firma, tipo y autorización, el usuario no sabe qué se comprobó y qué se asumió.

Un recibo que muestre la política exterior

Cada ecosistema podría acompañar sus decisiones con un recibo de autoridad pequeño y versionado. No sería una nueva pieza obligatoria del token. Sería el registro de la política aplicada alrededor de él.

El recibo conservaría el vct exacto, los aka_vcts aceptados y la cadena extends procesada. Identificaría al emisor, el método de validación de su clave y el instrumento que autoriza la expedición: una entrada registral, una acreditación, una ley, un contrato o una lista de confianza. En otra sección identificaría al editor de Type Metadata, la versión e integridad del documento y la fuente que legitima su función.

También debería indicar territorio o ecosistema, periodo de vigencia, versión de la política del verificador y momento de la decisión. Un campo de no conclusión diría expresamente que la firma, el alias, la herencia y la descarga correcta no prueban por separado la autoridad institucional.

Los estados negativos necesitan precisión. «No consultado», «no localizado», «caducado», «fuera de ámbito» y «desautorizado» producen consecuencias distintas. No hallar una prueba pública no basta para acusar a un emisor.

La solución no debe convertirse en otro centro de poder

No existe una única arquitectura de autorización válida para documentos gubernamentales, títulos académicos, credenciales laborales y asociaciones privadas. Si el IETF intentara codificar todas, sustituiría decisiones locales por un punto de control global y dejaría obsoleto el formato cada vez que cambiara una norma.

Por eso el recibo corresponde a perfiles del ecosistema, políticas de verificación, registros del programa o configuraciones de confianza del monedero. El estándar común mantiene la separación y ofrece las piezas técnicas; no elige a los emisores legítimos del mundo.

La misma cautela vale para la privacidad. Los valores vct y aka_vcts no son selectivamente ocultables y pueden revelar la naturaleza del documento. El borrador advierte además que un identificador de emisor específico para cada titular puede permitir seguimiento si el verificador consulta al emisor para obtener claves o metadatos. Un recibo de autoridad debería vincularse a combinaciones estables de emisor y tipo, admitir caché o fijación local y evitar llamadas individuales en cada presentación.

Fuentes

1. IETF — Last Call de SD-JWT VC -19
2. IETF Datatracker — estado de SD-JWT VC
3. IETF — SD-JWT VC, revisión -19
4. RFC 9901 — Selective Disclosure for JSON Web Tokens
5. IESG — orientación sobre Last Call
6. IETF — carta del grupo OAuth
7. Heng Lu — Mandate Laundering