要約

  • draft-deshpande-secevent-http-multi-set-push-03は、2026年9月23日までIESG Last Call中の、セキュリティ分野の個人提出Internet-Draftである。目標はProposed Standardだが、承認済みRFCではない。
  • 一つのHTTPS POSTに複数のSecurity Event Token（SET）を入れ、各トークンのjtiをackまたはsetErrsで返す。確認できるのは受領と解析・検証であり、受信先の停止・失効処理ではない。
  • 運用側は、送信、保存、本人との照合、現地の判断、実行、結果の観測をイベントごとに区別しなければならない。HTTP 202を最終結果として扱うと、その差が見えなくなる。

六件を一つの「成功」にしない

仮に企業が六件のアカウント関連イベントを提携先へ送ったとする。五件には受領確認があり、一件は検証エラーとなった。このとき「要求成功」とだけ記録すれば、エラーの一件を隠すだけでなく、残り五件がまだ現地のアクセス制御に反映されていない可能性も消してしまう。これは仕様を評価するための仮例であり、実在の障害報告ではない。

RFC 8935はSETを一件ずつHTTPSでpushする既存の仕組みを定める。新しい草案は、同じ受信者へ多数の要求を送る負荷やレート制限の圧力を下げるため、application/secevents+jsonのsetsに複数のSETをまとめる。それぞれの鍵はjtiで、受信側はackの配列と個別エラーのsetErrsを返す。IETFの記録は9月21日時点でIESG Last Callを示すだけで、採択、実装の普及、実運用での効果は示していない。

草案は受信した各jtiを確認かエラーのいずれかに載せるよう求める。一方、確認の対象をSETの解析・検証に限り、その後のアプリケーション処理で生じた問題をこの経路で報告してはならないとする。受信したイベントの主体を自社の利用者に対応付けるか、セッションを切るか、資格情報を失効させるかは、受信組織の別の判断である。202応答がその判断を代行することはない。

さらに、応答は直前の要求だけを指すとは限らない。setsを空にしたPOSTで過去の未確認分を問い合わせられ、返されたjtiが以前の送信に属することもある。監査は要求番号よりトークン識別子を軸にする必要がある。確認後、送信側は再送用のSETを保持しなくてもよい。必要な保存は受信側の責任になる。ここで記録を失えば、後から送信側のログだけで処理結果を再構成することはできない。

未確認のSETには合理的な期間後の再送が推奨されるが、送信側は回数に上限を置ける。確認またはエラーを得た同一jtiを再送してはならず、エラー後に再試行するなら新しいSETと新しい識別子が要る。受信側のリプレイ対策は必須ではなく、既に扱った識別子を黙って捨ててもよい。したがって、一括送信は「ちょうど一回実行」の保証にならない。

速度のための一括化にも上限がある。草案は件数を増やすための過度な遅延を禁じ、設定件数か最も古いSETの待ち時間が閾値に達したら送る方針を勧める。一～二秒は例示であり、共通の保証値ではない。受信側には件数と総バイト数の双方を制限し、超過時は要求全体を413で拒むことを勧める。リスト内の順序も時系列や処理順序を保証せず、複数のSETから一つのトランザクションは生まれない。

RFC 9967のSCIM非同期処理は、要求と後続イベントの対応という別の課題である。multi-SET案が扱うのは配送のまとめ方と個別の受領結果だ。いずれも他組織のアカウントへの決定権までは定めない。

参照資料

IETFの現在の状態／草案第03版／RFC 8935／RFC 8417／RFC 9967。