摘要

  • RFC 9782 注册六种 EAT 媒体类型、+cwt 结构化语法后缀和六个 CoAP Content-Format 编号，并允许用可选的 eat_profile 参数在解码正文前选择处理器。
  • 标准明确把媒体类型称为处理线索：接收端仍须核对真实字节、验证加密信封或安全信道、比对内外 profile、检查新鲜度并评估声明。
  • Verifier 的 Attestation Results 还不是 Relying Party 的业务许可。被识别、被解析、被验证和被授权应各有一张可追溯回执。

六个名字解决的是入口秩序

远程证明不是一个单一判断，而是一连串交接。Attester 形成 Evidence，Verifier 按评估策略处理证据并产生 Attestation Results，Relying Party 再结合自己的策略，决定是否授予网络接入、密钥使用、工作负载执行或交易权限。对象在这些角色之间移动时，系统首先需要知道自己收到的是什么外形。

RFC 9782 给出六个稳定名称。application/eat+cwt 与 application/eat+jwt 区分 CWT 和 JWT 形式的 EAT；application/eat-bun+cbor 与 application/eat-bun+json 表示 CBOR 或 JSON 编码的 detached EAT bundle；application/eat-ucs+cbor 与 application/eat-ucs+json 表示没有自身加密保护的 UCCS 或 UJCS。CoAP 又为六种形式分配 263 至 268，方便受限环境用紧凑编号传递同一差异。

这些注册并非行政装饰。网关可以尽早拒绝不支持的形式，可以用 Accept 协商结果格式，也可以把不同 profile 送往更窄、更可审计的处理器。+cwt 后缀则让通用工具知道底层语法是 CWT，从而复用适当的基础处理。

但名称只描述表示形式。+cwt 不说明由谁签名、允许哪套算法、验证密钥如何取得、必须出现哪些声明、怎样防重放，更不说明某个业务动作是否可以执行。六种名称也没有让六种形式拥有相同的安全属性。

UCCS 和 UJCS 最能暴露这条界线。RFC 9781 要求 RATS 场景下的接收端在建立安全信道时认证发送端，信道必须提供完整性；若还需要机密性，接收端也要被认证。一旦未保护的声明集离开信道，信道属性就不再覆盖它。把声明写入数据库、消息队列或另一个进程，是新的信任交接，不能靠原来的 Content-Type 继续背书。

同一条安全信道里传输一个完整 CWT，也不意味着信道替它作保。CWT 自身的 COSE 信封、验证密钥与验证结果仍须独立成立。外层 TLS 可以证明对端是谁，却不自动证明内层令牌所代表的 Attester 是谁。

外部 profile 参数先是路由选择，后才可能成为一致事实

EAT 有意保留大量选择：CBOR、JSON 或两者；COSE 或 JOSE 的具体结构与算法；密钥标识；是否允许 detached bundle；哪些声明必需；采用什么新鲜度机制。RFC 9711 用 profile 把这些选择缩小成具体用例可执行的约束。

EAT 正文可以携带 eat_profile 声明。RFC 9782 又允许媒体类型带一个同名可选参数，镜像正文里的标识。HTTP 中 URI 需要作为 quoted-string，OID 可以用 token 形式。这样，API 路由器无需窥探正文，就能把消息送入某个 profile 专用处理器。

这是很实际的控制面改进。它减少“先全部交给万能解析器，稍后再猜意义”的做法，也让未知 profile 在边缘显现。然而参数仍是随消息而来的外部声明。安全解码后，接收端必须把它和正文内的 eat_profile 比对。缺少参数、完全一致、彼此冲突，是三个不同状态。冲突可能来自错误路由、过期中间件、客户端混淆或替换尝试，不能悄悄归一化。

标识一致也不等于符合 profile。RFC 9711 禁止 eat_profile 指向 partial profile；full profile 必须完整到让双方都符合时，接收端能解码、验证并检查发送端可能产生的每个 EAT 的新鲜度。这里真正产生保证的是“双方执行了全部约束”，不是 URI 本身。发送端可以写对 URI，却选错算法、漏掉必需声明或采用错误 nonce 规则；接收端也可能认得 URI，却未实现 profile 允许的一种嵌套编码。

先证明字节，再证明保护，最后才解释声明

RFC 9782 在安全考虑中直说：媒体类型只能给处理应用提供线索。无论广告的类型是什么，应用都必须证明数据符合预期格式，并在失败时停止。否则可能出现权限提升或跨协议攻击。

这否定了一种常见便利：让任何“愿意吃下正文”的解码器试一遍。宽松 sniffing 可能把错误 Content-Type 变成含糊的成功。RFC 9110 对 HTTP 给出同类警告；RFC 8725 则建议在不同 JWT 种类可能混淆时使用显式类型，并让各类验证规则互斥。

因此，分派回执只记录请求头选中了哪个处理器；格式回执记录精确字节是否属于该语法；保护回执记录 COSE/JOSE 是否在允许算法、接受密钥和正确信任锚下通过，或者 UCCS/UJCS 是否仍处在认证信道的有效范围。对于 detached bundle，还需逐项证明外部声明集与受保护主令牌里的摘要相符。

完成这些步骤之后，系统才有资格解释声明。密码学验证能在特定密钥模型里证明来源与完整性，却不能证明传感器如实测量，也不能证明 Attester 实现具有某个抗攻击等级。RFC 9711 明确说，它定义声明语义，不规定实现的安全水平。接收者对声明可信度的判断来自对 Attester 实现和 Verifier 处理过程的了解。

新鲜度也不能被签名吸收。RFC 9711 要求所有 EAT 用法提供防重放的新鲜度机制，nonce 只是其中一种，profile 应规定可接受方式。一个签名完全正确的令牌仍可能是旧消息重放，所以签名验证与新鲜度必须留下不同输入、时间和失败原因。

评估结果没有替依赖方作决定

RATS 架构把最后两步刻意拆开。Verifier 使用 appraisal policy、参考值与 endorsements 评估 Evidence，形成 Attestation Results；Relying Party 再按自己的策略把结果用于某个具体动作。两种角色可以部署在同一个产品里，但断言不能混成一个。

Verifier 可以准确报告测量值匹配且证据新鲜，Relying Party 仍可因为资源不同、风险窗口关闭、辖区规则或交易需要更多声明而拒绝。反过来，局部策略也可能在结果不确定时只开放低权限、短时动作。RFC 9782 不替组织选择答案，它只帮助消息抵达正确处理器。

因此完整链条是：外部媒体类型与 profile 参数；精确字节哈希；处理器和解析器；信封验证或信道范围；正文 profile 与声明；full-profile 符合性和新鲜度；Verifier 评估；Relying Party 动作。每一步都应把输入、规则版本与结果写进自己的回执，后面的成功不能擦掉前面的不确定。

Heng Lu 关于“符号层与可执行层”的区分在这里很有用。RFC 与 IANA 注册让名称在符号层成立；只有运行中的发送端与接收端执行同一 profile、拒绝同样的错误字节、核验保护、完成新鲜度与策略判断，互操作性才进入可执行现实。注册表不会替系统运行。

来源