摘要

  • draft-mcguinness-oauth-client-instance-id-00 允许 attester 在经过验证的密钥变更后保留 client_instance_id，但相同字符串只是注册连续性结论的索引。
  • 实例连续性、grant 的密钥绑定、attester 信任、Receiver Scope、下游映射、当前呈现者归属和资源授权必须分别验证。
  • 可审计收据应连接注册、粒度、生命周期事件、新旧密钥、证据新鲜度、Consumer Scope、sender constraint 与最终业务结果。

一台受管终端完成密钥轮换。新 attestation 有效，client_instance_id 与旧记录相同。授权服务器于是把旧的暂停状态、审计历史和策略决定延续到新密钥。

表面上，这是一次字符串匹配。实际上，新密钥不知道旧密钥是谁，ID 也不会说明设备经历了原地升级、重装、克隆、快照恢复还是替换。真正的判断早已在另一处发生：Client Attester 认定新申请者是旧注册的继承者，并声称它持有足以支持这项判断的证据。

修订版 00 于 2026 年 9 月 28 日发布，是一份拟走 Standards Track 的个人 Internet-Draft。它不是 OAuth 工作组文档，不是 RFC，也不证明实现、互通或部署。它取代了单独携带实例 assertion 的旧设计。基础 attestation 草案虽已进入工作组 Last Call，但那是另一份文件，不能把其成熟度借给本 profile。

当前持钥不等于历史连续

基础机制回答“这个获准客户端实例是否持有这把当前密钥”。新 profile 回答“它是否也是 Receiver 以前见过的那个实例”。每把新密钥都需要新的 attestation，但新的有效 attestation 本身无法区分持续安装和全新安装。

client_instance_id 由 attester 分配。完整的 Source Instance Identity 是 (iss, client_instance_id)，不是脱离 issuer 的字符串。client_id 标识 Logical Client，一个逻辑客户端可以拥有许多终端、容器或 agent runtime。用户或委托主体又是另一层身份。

因此至少有四条独立结论：现时密钥持有、历史实例继承、本地授权和实际执行结果。把它们压成“已验证实例”会让一个成功签名承担它从未观察到的历史与效果。

ID 只是标签，注册记录才是证据

草案要求 ID 唯一、不透明、不可预测，并且退休后也不得重新分配。它不能嵌入用户名、主机名或实例属性。即使长得像 URI，也没有 URI 语义。Receiver 只能按精确字符串比较，不能从中解析权限、粒度或密钥位置。

这些规则保护标签，却不能产生继承事实。若要保留 ID，attester 必须记录一个活跃 enrollment，将实例、Logical Client、Receiver Scope、粒度和已验证过的密钥连接起来。换钥时，它要验证新密钥的鲜活持有、获准的 custody transition、连续性检查及其新鲜度，还要记录观察到的生命周期事件。

正常续期、经验证的换钥、安装粒度下的进程重启和原地更新可以保留 ID。重装、独立克隆、替换、执行粒度下的单元重启或粒度改变必须新建 enrollment。快照恢复只有在新证据证明申请者继承旧持有者时才可保留；复制密钥与数据不够。发现 fork 后应退休或拆分注册，除非证据能确定真正的延续者。

这说明产品不是“永久 ID”，而是一台由策略治理的状态机。连续性记录一旦删除，就必须重新注册。仅靠平台稳定值派生 ID 会在重装后重现已退休标识，因此也被排除。

Receiver Scope 存在，却不在对象里自证

默认情况下，不同 Receiver 应得到不同 ID。然而 Receiver Scope 是 enrollment 或 issuance 的输入，不是 OAuth 参数，也不是 attestation audience。Receiver 无法仅从标识值检查它是否属于自己。

跨 Receiver 共享 ID 需要明确行政协议；共享 Logical Client 或信任域并不自动授权。部署若想隔离范围，还必须使用不同 Client Instance Key，否则相同公钥会在不同 ID 之间重新建立关联。

如果客户端把某个 scope 的 attestation 发给错误 Receiver，后者可能看不出越界。真正的控制落在客户端与 attester 的配置执行上。审计收据必须保留预期 scope、策略版本和执行责任，而不能只保存一份语法正确的 JWT。

谁能担任 attester 仍是 Receiver 的决定

Receiver 要把获准 Attester Issuer、验证密钥与它可代表的 Logical Client 绑定起来。iss、有效签名、持钥证明或客户端发布的 metadata 都不会单独创造发言权。

已有 Client Attester Endorsement 文章讨论 publisher endorsement 与授权服务器信任的双重批准。本篇从批准之后开始：获准 attester 仍须依据配置的 assurance level 做连续性判断。如果它被攻陷，就可以在其获准关联内伪造实例；如果它夸大证据质量，本地策略也会失效。

自报证据、平台验证和硬件根证据不能互换。若缺少独立平台观察，复制了密钥与 enrollment 数据的克隆可能与原件无法区分。草案规范“发现 fork 后怎么办”，并未承诺发现平台看不见的 fork。

身份延续不会自动搬动 refresh token

profile 让 Source Instance Identity 能跨越换钥，却没有自动把现有 refresh token 的绑定转到新密钥。refresh 时，授权服务器要检查两个不变量：当前 identity 与登记值一致；当前 proof 与 grant 所要求的密钥绑定一致，除非另一个获准 profile 明确实施 rebinding。

第一项是“历史上仍是同一注册单元”，第二项是“这次请求持有该 grant 接受的凭据”。稳定数据库行并不等于权力已经随新密钥迁移。任何转移都应有明确决策、证据和责任人。

授权阶段若把 code 或其他 artifact 绑定到实例，redemption 时也必须要求所需 attestation；不能在真正兑现权力的端点开放一条不带证据的旁路。

暂停状态有多个时钟

attester 对暂停或退休 enrollment 停止签发。授权服务器可撤销 grant，并在 introspection 中报告 token inactive。但旧 attestation 仍可能活到过期与时钟偏差结束，access token 也有自己的寿命，本地撤销不会通知离线验证 token 的资源服务器。

状态分发不在本草案范围内。更麻烦的是，重注册或另一个 Receiver Scope 会生成 Receiver 无法与被暂停 ID 关联的新身份。若暂停要承担 containment，就需要 prior-enrollment 策略、替换注册的准入控制、撤销传播和明确的最长残留窗口。

“已暂停”若没有权威来源、生效时刻、覆盖的 enrollment、token 集合与通知范围，只是一条局部记录。

下游 context 引入第二个身份权威

可选 client_instance 允许 token issuer 把已验证实例传给资源服务器。它不是简单复制 attester ID，而是把 Source Instance Identity 映射为 issuer 自己命名空间中的 (iss, id)，并限制在由 token audience 选择的 Consumer Scope。

映射在相关 grant 与 token 有效期间必须稳定。若 issuer 无法再重现映射，应省略 context，不能悄悄分配新 ID。没有 audience，或 audience 横跨多个 Consumer Scope 时，不存在唯一正确映射。scope 外的 introspection caller 也不应看到它。

系统因此拥有两部账：attester 保存 enrollment 到源身份的连续性；token issuer 保存源身份到消费者视图的投影。两者的权威、密钥和保存期限不同。丢失任何一部都应显示为证据中断，而不是用新字符串掩盖。

参与签发不等于正在呈现

Instance Context 不授予任何权限。单独看，它只表示某实例参与了 token 获取，不证明当前 HTTP 请求来自该实例。

当前 presenter attribution 需要 DPoP、mutual TLS 或 consuming profile 定义的其他 sender constraint，并使用签发时与实例关联的 key。多实例共享 key 无法个体归属。没有约束的 bearer token 不能支持这项结论。

token exchange 又增加了一层。验证输入 token 只认证其 issuer 的 assertion，不会自动认证内部提到的所有上游 authority。consuming profile 要规定 context 表示当前 presenter 还是上游实例，怎样验证关联，何时 remap、preserve 或 omit。context 是一个实例引用，不是 actor chain，也不是独立委托 token。

即使 DPoP 通过，也只关闭“谁呈现了这次请求”这条边。它不证明资源服务器批准、只执行一次或产生预期业务效果。

隐私其实是在观察者之间分配可见性

Receiver 之间使用不同 ID 可以减少相互关联，但 attester 会知道 Receiver Scope。把多个 Receiver 放进共享 scope，会少暴露单个接收方给 attester，却让这些 Receiver 能联合识别实例。

如果 DPoP key 或证书复用，pairwise ID 也会被相同 thumbprint 重新连接。其他 claim 与应用数据同样可能泄露关联。隐私不能由某一列“pairwise”宣布，而要计算每个观察者、每把 key、每段保留期共同形成的可连接图。

连续性收据应包含什么

收据首先记录 attester issuer、验证 key、Logical Client、enrollment、粒度、Receiver Scope 与本地信任策略。每次 transition 连接旧新 key 指纹、生命周期事件、custody evidence、新鲜度与结论：保留、新注册、暂停、退休或 fork 分离。

grant 层把 Source Instance Identity 和 key binding 分字段记录。下游层记录 token issuer、mapping input、Instance Context、Consumer Scope、audience 及 provenance。请求层记录 sender constraint 与资源服务器的授权决定。最后才链接执行与独立结果。

这样，ID 才是一条可复核历史的入口，而不是对整条链的代称。