要約

  • RFC 9967では、本文のない202応答の Set-Txn と、後のSETにある txn を対応させ、非同期SCIM処理を追跡できる。
  • これは受理された処理と報告された結果の証拠であり、受信側が主体対応を受け入れ、ローカルな権限を変えたという証拠ではない。
  • 要求、イベント検証、照合、ローカル決定、実効、取消しを別々の記録として残す必要がある。

照合値が答えるのは「何を調べるか」だけだ

Prefer: respond-async を使うSCIMクライアントに対し、プロバイダは通常の応答を返すことも、本文なしの202を返すこともできる。後者には Set-Txn が入り、完了を報じるSETの txn と一致する。この値によって、再送された同じ通知と、新しい状態変化を区別しやすくなる。トークン固有の識別子と異なり、txn は基礎となる取引を複数の配送にまたがって指せる。

しかし一致は、受信側の結論ではない。同じ取引として発信側が扱っている、という限定された関係を示す。ローカルの利用者が本当に同じ対象か、遠隔の属性変更を自分のスキーマでどう読むか、サービス権限を実際に変えてよいかまでは決めない。相関は監査を良くするが、決裁を代行しない。

イベントは通知であり、遠隔操作ではない

RFC 9967は、SETをSCIMサービスプロバイダで起きた状態変化の信号として扱い、Event Receiverが自分の文脈で後続行動を決めるとする。これは慎重な実装上の余白ではなく、分散した責任の前提である。二つのドメインは、資源型、保持規則、停止条件、識別子、復旧責任を共有していないかもしれない。

full は最終の資源表現を data で運べる。notice は変更された属性だけを示し、既に合意したSCIM関係を通じた取得を受信側に委ねる。前者は照合材料を増やし、後者は開示を絞る。どちらも「受信側はそのまま適用せよ」という意味にはならない。

sub_id も同じ範囲で理解すべきである。これはSCIMイベントの主体を表す必須の手掛かりであり、送信者が何を指したかを示す。だがローカルアカウントは統合済み、再割当て済み、フィード外、あるいは送信者に見えない例外下かもしれない。形式の正しさは、同一性の最終判断を置き換えない。

202は、影響が終了した印ではない

202は非同期処理の受理を意味する。後続イベントは成功にもエラーにもなり得る。イベント能力は任意で、機能が見えないことは未対応または未設定を意味し得る。確認が不要ならクライアントは Set-Txn を無視できる。従って、一つの成功表示で全体を閉じてはならない。

実務では、要求の権限、プロバイダの応答、受信したSETの検証、主体とスキーマの照合、ローカルな権限決定、下流の実効と取消しをつなげる。前段が正しくても後段を拒否できる。ある受信側がグループ変更を採用し、別の受信側が拒否することは、必ずしも連携障害ではない。結果に責任を負う側が判断を保っているからである。

pushとpollは配送の条件を選ぶもので、誰がローカル権限を決めるかを選ばない。中継者が Set-Txn を変えてはならないという規定も、引渡しの追跡性を守るためであって、受信側のアクセス権を中継者に委ねるためではない。

Heng Luの考え方を編集上のレンズとして用いれば、共通層は「要求が受理され、その結果がこの取引に結び付く」という最小の事実にとどめる。照合、承認、保留、取消しの決定は、結果を運用する主体に残す。