Resumen

  • Los seis tipos registrados separan EAT CWT, EAT JWT, bundles separados en CBOR/JSON y conjuntos no protegidos en CBOR/JSON; +cwt y los números CoAP facilitan el tratamiento genérico.
  • eat_profile sirve para elegir temprano un procesador, pero el receptor debe comprobar los bytes, contrastar el claim interno y ejecutar el perfil completo.
  • La validez de una envoltura no establece la fiabilidad de las claims, y el resultado del Verifier no sustituye la política de la parte que toma la acción.

Un sistema de clasificación para la puerta de entrada

La arquitectura RATS hace circular dos objetos conceptuales distintos: Evidence hacia un Verifier y Attestation Results hacia un Relying Party. Ambos pueden representarse como EAT. RFC 9782 evita que el transporte dependa de una etiqueta genérica y registra seis tipos reutilizables para HTTP, CoAP y otros protocolos.

Dos tipos identifican CWT y JWT; otros dos identifican bundles EAT separados codificados en CBOR o JSON; los últimos dos identifican UCCS y UJCS, conjuntos de claims sin protección propia. Los Content-Format 263–268 llevan la misma clasificación a CoAP. El sufijo +cwt comunica la sintaxis subyacente a software genérico.

La ganancia está en el despacho: rechazar pronto una forma no admitida, negociar una respuesta con Accept y limitar cada mensaje a un procesador preparado para ella. Pero ninguna de esas etiquetas autentica al Attester. Tampoco define algoritmos, claves, claims obligatorias, referencias o política final.

La diferencia entre formas protegidas y no protegidas es decisiva. Para UCCS y UJCS, RFC 9781 exige que el canal aporte autenticación del emisor e integridad, y autenticación mutua cuando se necesita confidencialidad. Al salir el objeto de ese canal, termina ese amparo. Si se guarda o reenvía, hace falta una nueva atribución. Un CWT completo dentro del canal no recibe el aval del canal: sigue dependiendo de su envoltura COSE.

El perfil visible no es la conformidad ejecutada

Un perfil EAT restringe opciones que la base deja abiertas: serialización, formas anidadas, estructuras COSE/JOSE, algoritmos, identificación de claves, bundles, claims y frescura. El token puede nombrarlo internamente con eat_profile. RFC 9782 permite repetir ese identificador en el tipo de medio para que un router elija el procesador sin inspeccionar el cuerpo.

La elección temprana reduce el análisis universal y hace visibles los perfiles desconocidos. Sin embargo, el parámetro externo sigue siendo una afirmación del remitente. Tras una decodificación segura, el receptor debe distinguir si falta, coincide o contradice la claim interna. Una contradicción puede ser un fallo de cliente, un intermediario desactualizado o una sustitución. Corregirla de forma silenciosa borraría evidencia.

RFC 9711 añade un límite importante: eat_profile no debe identificar un perfil parcial. Un perfil completo permite que un receptor conforme decodifique, verifique y compruebe la frescura de todo EAT de un emisor conforme. El identificador no prueba que se usó un algoritmo permitido, que llegaron las claims obligatorias ni que el receptor implementó todas las variantes. Nombra las reglas; no demuestra su cumplimiento.

De los octetos a la valoración

RFC 9782 dice que los tipos de medio solo ofrecen pistas a la aplicación. Esta debe verificar que los datos reales corresponden al formato esperado y detenerse si no. El tratamiento tolerante puede convertir una declaración falsa en un parseo ambiguo y abrir ataques entre protocolos o elevación de privilegios. RFC 9110 plantea un riesgo semejante con la detección de contenido; RFC 8725 recomienda tipos explícitos y reglas de validación mutuamente excluyentes para JWT con usos diferentes.

Por eso una implementación necesita resultados separados. Primero, encabezado y hash del cuerpo. Segundo, ruta, procesador y gramática que aceptaron esos octetos. Tercero, algoritmo, clave, ancla y verificación de la envoltura, o identidad y alcance del canal para un conjunto no protegido. En un bundle, cada claims set separado debe coincidir con el digest del token protegido.

Después se evalúa el contenido. RFC 9711 define lo que significa una claim, no la resistencia del componente que la produjo. Una firma válida no convierte automáticamente una medición en verdad física. El Verifier necesita conocer la implementación, endorsements, valores de referencia y su política.

La frescura tampoco cabe dentro de “firma válida”. Todo uso de EAT debe evitar replay. El perfil determina si utiliza nonce, tiempo u otro mecanismo. Un token puede ser auténtico y viejo, de modo que ambos resultados deben conservar entradas y causas distintas.

La última separación pertenece a RFC 9334: el Verifier produce Attestation Results; el Relying Party usa esos resultados bajo su propia política para una acción concreta. Puede negar una acción aunque la evidencia sea válida, porque cambia el recurso, el tiempo o el riesgo. Puede conceder una capacidad limitada con caducidad. RFC 9782 entrega el mensaje; no toma esa decisión.

El recorrido auditable queda así: tipo y perfil externo → bytes exactos → ruta y parser → protección o canal → perfil y claims internos → conformidad y frescura → appraisal → acción. La publicación de una asignación IANA crea una convención compartida; la interoperabilidad solo aparece en código que aplica los mismos límites. Es la distancia entre la capa simbólica y la realidad ejecutable que subraya Heng Lu.

Fuentes