摘要

  • RFC 9967 由 Nancy Cam-Winget 等人合著，规定以 SET 传递 SCIM 安全事件。SET 表明某个状态变化已在 SCIM 服务提供方发生；事件接收方应按自身情境决定后续行动，而非把 SET 当作命令。
  • Set-Txn 将异步 202 Accepted 响应与后续 SET 中的 txn 声明关联。关联成功、事件已持久化，或其中带有资源数据，都不等于接收方已经匹配资源、完成对账、执行本地规则或达到相同状态。

异步身份流程最容易被夸大的词，往往是“完成”。一项请求收到了 202 Accepted，随后出现带有相同 txn 的 SET，于是界面便可能显示“已同步”。RFC 9967 所证明的事实要窄得多，也更有价值：提供方接受了异步处理，并在之后发出可关联的事件。它没有证明每一接收域都以同一种方式理解事件，更没有证明它们已经造成了某种业务或访问结果。

RFC 9967《System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs)》将 SET 定义为关于 SCIM 服务提供方已发生状态变化的信息。这使依赖方不必持续盲目轮询，是实际的进步。但规范明确不要求把 SET 解释为指令；每个 Event Receiver 在自己的上下文中确定最合适的后续动作，并以跨域模式和资源类型的对账为例。

这一限定反映了真实的运行环境。两个域可能使用不同的标识符、非同构的属性或不同的生命周期语义。接收方可能识别事件中的 URI，也可能找不到对应资源。当它无法匹配 URI 时，RFC 允许它使用预先约定的提供方基础 URI 加相对 URI 发起 SCIM GET 回查。它也可能先为恢复目的保存事件，再把判断交给本地流程。提供方的变化是真实的；接收方尚未对账并不否定该事实。

关联字段同样不应被扩大解释。SCIM 客户端请求异步响应时，RFC 要求返回无消息体的 202 Accepted 及 Set-Txn。该值必须与后续 SET 的 txn 一致，供客户端查找对应的完成事件。这是一条很好的审计连接：它把被接受的请求与提供方日后的声明接起来。但它不是全球收据。RFC 特意区分 txn 与 jti：jti 唯一标识单个令牌，而同一 txn 可以用于重传或向多个接收方发布的多个 SET。值相同只说明关联了什么交易，并不说明哪个接收方已收敛到何种状态。

事件载荷也要求克制。data 与 attributes 中必须且只能出现一个：前者给出交易后的资源表示，后者列出新建或修改的属性。完整表示仍可能需要模式映射和本地判断；属性清单仍可能需要回查。二者都不证明接收方已接受数据、已实施某项授权决定，或本地资源已经与提供方当前表示一致。

持久化是另一种证据，而非同一种证据。RFC 要求接收方在确认接收前，为满足本地恢复需要而直接或间接持久化事件。这保障长寿命事件流在短暂故障和重试后可恢复。一只可靠的收件箱可以证明事件被保留，不能证明资源被匹配、规则被执行或本地状态已经改变。

这正是 Running-Code Primacy 的细小实践：技术产物应只证明它确实暴露的状态变化。请求接受、Set-Txn、txn、jti、SET 到达、持久化、本地匹配、回查结果、规则决定、行动和观察到的状态，都是不同的证据连接。把它们统称为“同步”，会抹去日后排查最需要知道的断点。

稳妥做法不是贬低 RFC 9967，也不是强行把决定集中起来。提供方对其变化声明负责；接收方对本地解释负责；承担后果的组织决定在何种证据下才可宣称已对账。规范扩展了可验证事实，却没有把事件伪装为另一域的决定。

来源