摘要

  • RFC 9967 允许把异步 SCIM 响应与之后的结果关联：无正文的 202 响应可以携带 Set-Txn，后续 SET 使用相同的 txn。
  • 这个对应关系证明的是一项底层事务被受理并被报告结果；它并不证明接收方接受身份映射、修改本地角色或授予服务访问。
  • 请求、事件校验、对象匹配、本地决定、实际效果和撤回应当各有独立记录。

收据只说明该去查哪一项工作

使用 Prefer: respond-async 的 SCIM 客户端可以请求异步处理。服务提供方可以正常完成，也可以返回一个没有正文的 202；后一种情形下，Set-Txn 的值必须与之后 SET 中的 txn 相同。这个设计使运维方能够把“这次完成或错误报告”同“那次底层请求”连在一起。

它尤其有助于区分重复投递和新的状态变化。jti 标识一枚具体 token，txn 可以在重传或向多个接收方发送时保留。可是，一个整洁的事务号不会替任何接收方解决更难的问题：发来的主体是否对应本地记录？远端变化是否可以映射为本地规则？本地服务是否真的应当随之改变？关联减少查询的歧义，不裁决查询的后果。

事件是事实信号，不是远端命令

RFC 9967 明确说，SET 传递的是 SCIM 提供方已经发生的状态变化；Event Receiver 在自己的上下文中决定最合适的后续动作。这不是附注。不同域可能拥有不同的模式、标识体系、保留义务、暂停条件和恢复责任。一个可携带的消息无法预先代替所有这些局部判断。

full 与 notice 的区别把边界做成了可见的协议面。full 在 data 中带出资源的最终表示；notice 仅列出变更的属性，接收方可在既有 SCIM 关系下再取信息。前者增加可供核对的数据，后者限制数据并要求一次受控的拉取。两者都不是“立刻照抄远端状态”的命令。

sub_id 也应如此理解。它是 SCIM 事件主体所要求的标识方式，说明发布者希望指出哪个资源；它并不自动消除本地的歧义。一个本地账户可以被合并、重新分配、排除在某条 feed 之外，或受发布者看不到的例外约束。标识符帮助匹配，不能把匹配变成跨域的最终裁判。

被接受的异步处理并非后果已经结清

202 表示提供方接受异步处理，而不是所有跨域影响已经完成。后续异步事件可以报告成功，也可以报告错误；事件能力又是可选的，缺失时可能是未支持，也可能是当前未配置。客户端在不需确认时还可以忽略 Set-Txn。因此不应使用一盏绿灯概括整条链。

较稳健的链至少包括：请求的本地授权；提供方响应与关联值；收到 SET 后的来源和内容校验；对 sub_id、模式及版本的本地协调；由谁依据何种规则决定本地权限；以及实际下游效果与可撤回路径。前一项成立而后一项被拒绝，并不表示集成坏了。一个有效事件被本地策略拒绝，常常正是责任还留在正确位置的证据。

推送与轮询解决的是不同的交付条件，不分配接收方的授权责任。中间方不应篡改 Set-Txn，保护的是交接的可追溯性，不是把中间方或发布方变成接收系统权限的最终主人。

以卢恒的思想作编辑透镜，最小共同层应当只传递可验证的事实：一项请求被接受，某个结果与它相关。是否匹配、同意、延后、撤回或升级，必须留给承担后果的一方。