摘要

  • draft-ietf-oauth-transaction-tokens-11 定义一种短时有效的签名 JWT，用于在 aud 界定的 Trust Domain 内沿调用链传递身份与交易语境。它是处于 WG Consensus: Waiting for Write-Up 的活跃标准轨 Internet-Draft，不是 RFC，也不代表 IETF 已最终批准。
  • 接收方必须验证 JWS 签名、受众和有效期。这些检查证明容器完整且适用于本域，却不会自动说明每项 rctx 或 tctx 值究竟是调用方提供、系统观察、推导生成，还是由 TTS 独立断言并核验。
  • Daniel Kade 建议在业务决定旁保存“声明来源封套”：来源、实际执行的验证、观察者与时间、转换和政策版本、时效检查、允许用途、矛盾证据与决定结果。它可只保存哈希或引用，避免完整令牌和不必要的个人信息；这不是 IETF 要求。

一次权限复盘看似已经结束。记录显示交易令牌签名有效，managed_device 为真，于是下游服务放行了敏感操作。审计员继续追问：这项设备状态来自管理平台，还是来自调用方上传的 JSON？发令牌前是否查询过设备吊销状态？查询发生在什么时候？日志回答不了。

令牌没有被篡改，签名也没有失效。丢失的是从“这个值存在”到“这个值足以支持决定”的中间证据。

在分布式系统里，密码学结论很容易被扩写成语义结论。JWS 能证明某把密钥签过一组字节，并证明字节在签名后未被修改。Transaction Token Service 可以决定令牌里提供哪些声明。但这两件事都不会单独揭示每项事实的最初观察者、校验方法、转换过程、当前时效和适用决定。把容器保证与声明保证分开，不是否定签名，而是让签名只承担它真正完成的工作。

第 11 版的位置需要准确表述

Datatracker 页面显示，第 11 版日期为 2026 年 7 月 30 日，是 OAuth 工作组的活跃标准轨 Internet-Draft。在本次研究截止时，工作组状态为 WG Consensus: Waiting for Write-Up，IESG 状态仍是 I-D Exists，没有负责的 Area Director，也没有 telechat 日期。这说明工作已经进入重要阶段，但不能写成 RFC 或 IETF 最终批准。

文档历史和第 10→11 版官方差异进一步限制了“新版”的含义：这次变化只修正文档历史里的一处笔误，本文讨论的保证模型在第 10 版已经存在。I-D 发布通知证明新版本已经发布，不证明标准流程已经完成。

草案解决的场景很实际。外部请求进入组织后，往往要经过多个 workload。后续服务需要知道主体、目的、权限范围和交易细节，却不应都重新解析或持有原始外部凭证。Transaction Token 因而被设计成一种生命周期很短的签名 JWT，让共同语境沿 Call Chain 在同一 Trust Domain 内传递；该域由 aud 标识。

每个使用这种令牌的 Trust Domain 只有一个逻辑上的 Transaction Token Service，部署上可以有多个实例。TTS 验证申请令牌的 workload 及其申请权限，选择上下文并签发统一表示。JWT给出声明格式，JWS给出签名表示，OAuth 工作组负责推进这项工作。

接收令牌之后，授权责任仍在本地

收到交易令牌的 workload 必须完成三项检查：验证 JWS 签名；确认 aud 指向自己的 Trust Domain；确认令牌尚未过期。少做任何一项，都不能算安全接受。三项都通过，说明本域在有效期内收到了 TTS 签过且未被更改的对象。

这不等于授权已经完成。接收方可以用令牌数据判断是否执行请求，但具体授权方法不在草案范围内。机制负责携带上下文，后果仍由做决定的服务承担。下游不能只把“签名通过”当作所有本地政策的答案。

草案还明确区分了两个相近但不同的对象。Transaction Token 不是认证凭证，也不得被当作 OAuth access token 使用。OAuth 2.0中的 access token 表示授予的权力，Transaction Token 表示交易的语境。若因为编码形式熟悉就把后者当成前者，描述信息便会在没有授权来源的情况下变成许可。

重放也是独立问题。Transaction Token 本身不抗重放。唯一的 txn 可以帮助发现重复或执行一次性使用，但要在分布式调用链里严格保证“只消费一次”，可能需要所有节点共享状态，现实中未必可行。签名能发现字节被改，不能阻止同一串字节被再次提交。

同一签名之下，可以有多种来源

scope 是必需声明，由 TTS 决定。TTS 不得扩大原 subject token 所代表的 scope；如果无法理解输入 scope，就必须拒绝，而不能把“未知”解释成“不受限制”。这是明确的权限不扩张规则，也说明草案并非完全放任部署自行解释。

来源差异在推荐使用的 rctx 里更明显。它可包含请求或环境语境。调用方提供语境时，TTS 应当评估。最终放入 rctx 的值可以原样匹配输入，也可以由输入推导，还可以由 TTS 独立断言。TTS 对它所提供的声明集合具有权威性；但“由它选择进入集合”并不等于集合中每个值都经过相同方式的独立验证。

tctx 也被推荐使用，用来保存应当在整个 Call Chain 中保持不变的交易细节。其值同样可以是原始请求细节、推导结果或 TTS 新增声明。签名能保证签发后的这个版本不被改写，却不能反向证明签发前是谁首次观察到它。

例如，一枚有效令牌包含三项值：request_ip 来自已认证的入口网关；payment_amount 原样复制自调用方提交的无签名对象；risk_band 由 TTS 按第 43 版政策，结合已验证凭证和实时风险信号算出。三项值都被同一签名覆盖，但证据链显然不同。把它们都显示成“TTS 已证明”，会把选择、传递、计算和独立核验混成一个动作。

这并不表示 rctx 或 tctx 天生不可信。相反，其中某些值可以具有很高保证。正确说法是：保证随具体来源、检查、时间和用途变化。同一个对象里允许存在可靠的观察值、可接受的调用方陈述和严格推导值，只要后续知道自己依赖的是哪一种。

输入类型不同，“验证过”的内容也不同

TTS 接受的 subject token 可以是 OAuth 或 SAML token、自签名 JWT、无签名 JSON 对象，或其他能够理解的格式。它必须验证 subject token；若输入有签名，也必须验证签名。于是，“验证”不是一个固定动作。不同类型涉及不同的发行方、密钥、算法、受众、时间、模式与传输信任规则。

JWT 最佳当前实践解释了为何不能仅凭 token 自述就接受算法和密钥。OAuth Token Exchange提供安全令牌交换的相邻框架，Transaction Token 草案则处理域内交易语境。部署可以在受保护的契约下合理接受无签名 JSON，但它显然不会因此拥有与验证过的签名凭证相同的密码学来源保证。

TTS 还要验证请求 workload 的身份，以及它是否有权取得所申请的令牌。至于签发政策和业务逻辑，草案留给部署决定。这个边界给组织必要的自由，也意味着两套合规实现可能对同名字段执行不同检查。如果不保存本地政策版本，语法一致会掩盖保证差异。

exp 不能代表所有上游事实仍然新鲜

交易令牌预期只存活几分钟或更短，并以调用所需时间为限。但草案允许它在 TTS 政策许可下晚于签发时提交的 subject token 到期，TTS 应评估相应风险。这样做可能有助于完成已经开始的短调用链，却也说明新令牌的 exp 只描述新令牌自己的窗口，不能证明每项上游事实仍是最新状态。

OAuth access token 还可能在自然到期前被作废。TTS 可以根据风险通过令牌内省或类似机制查询当前失效情况；草案没有把实时查询设为所有场景的统一强制要求。因此，“时间尚未到期”与“10:43 已检查未被撤销”必须在证据记录里分开。

替换令牌不允许扩大许可动作，也不得改变 txn、sub 或 aud。它可以缩小 scope、增加断言，并在政策允许时延长生命周期；还必须保留申请它的 workload Call Chain，但草案不规定保留机制。如果新增声明没有标明出现在哪次替换，最终令牌会把分阶段形成的事实压成一个看似同时发生的截面。

aud 的边界同样不能忽略。Transaction Token 只在自身 Trust Domain 内有效。跨域延续应采用另外的 OAuth 身份与授权链工作。另一个域即使能验证签名，也不会自动继承第一个域对本地字段的定义和信任政策。

一位审阅者的警告，不应被写成行业结论

在 2026 年 8 月 8 日的一封 WGLC 邮件中，一位审阅者支持草案继续推进，并明确没有阻断性意见；同时，他要求让替换链更容易审计，并提醒实现者可能把“信息装在签名 token 中”误解成“发行方独立证明了该信息”。

这封邮件是有价值的审阅证据，但必须保持原有尺度。它代表一位审阅者及其自述的实现经验，不是工作组共识，不是部署普遍性统计，不是已确认事故，也不能证明第 11 版有缺陷。它只是说明，这种语义跃迁足够现实，值得运营控制预先处理。

声明来源封套应贴近决定，而不是复制令牌

Daniel Kade 的编辑性建议，是为真正影响决定的每项值保存来源封套。封套记录来源类别和非秘密标识、实际执行的验证、观察者与观察时间、转换过程及代码或政策版本、必要时的发行方与签名密钥引用、Trust Domain 边界、时效或失效检查、允许用途、敏感性与日志规则、矛盾或缺少的旁证、下游决定、到期与闭环状态。

这不是要求所有实现向 token 填入一套新通用声明。封套可以存在签发回执或决策回执中，只保存 token 哈希，或引用已经最小化的证据。草案明确禁止逐字记录完整 Transaction Token，因为它可能被重放，也可能含敏感信息。系统可以记录哈希以关联 TTS 签发记录，也可以在合适条件下记录去掉签名的 JWS payload；但 payload 仍可能包含个人信息。请求 IP 等环境数据在不同司法辖区可能构成个人数据，本文不作法律合规结论。

记录的目标是重建判断依据，而不是建立一个可重放令牌和原始个人信息的副本库。证据需要留下，秘密不应跟着复制。

来源