要約

  • draft-deshpande-secevent-http-multi-set-push-03の202応答は、一部のjtiをackで確認し、別のものをsetErrsで拒否し、過去の要求に対する結果も返せる。202は封筒の受理であり、全イベントの完了証明ではない。
  • この文書はArea Directorがスポンサーとなるindividual submissionで、IETF Last Callは2026年9月23日まで。Working Group state、確認済み実装、IESG承認、RFC番号、完了済みIANA登録はいずれもない。

四つのSecurity Event Tokenを一つのPOSTで送る。受信側は202を返す。しかし本文では三つだけが確認され、残る一つにはエラーが付くかもしれない。さらに、前日に送ったjtiの結果が同居することもある。確認済みのトークンが、セッション失効やアカウント制御を下流で実行したかどうかは、そこからは分からない。

HTTP Push Delivery of Multiple Security Event Tokensの第03版は、この非対称性を意図している。通信回数を減らしても、SET群をトランザクションにはしない。したがって、要求単位の緑色表示を一括完了の証拠に変えることは、仕様が残した個別結果を捨てる行為になる。

照合の単位はjti

application/secevents+jsonのsetsは、各トークンのjtiをキーにする。受信側はSETを個別に検証する。202本文には必須のack配列があり、jti別のsetErrsを追加できる。草案の例も、一つの受理応答に成功とエラーを同時に含む。

応答は現在のPOSTだけに拘束されない。以前の要求に含まれたSETの結果を返せるほか、送信側は空のsetsで遅延結果を問い合わせられる。未知の識別子に対する確認やエラーは無視しなければならない。追跡対象はHTTP呼び出しではなく、識別されたイベントである。

未確認のSETは、確認、SET固有エラー、または最大試行回数のいずれかに達するまで再送される。時間や保存容量の方針により、未配達イベントを破棄する場合もある。最初の202からは、その判断も最終結果も復元できない。

受領と業務処理は別の状態

草案の確認が意味するのは、受領、構文解析、検証までである。後続の業務処理は保証しない。RFC 8935もSETの配達と後処理を分け、RFC 8417はSETを命令ではなく、発行者から見た事実の表明と位置付ける。

RFC 9110の202も、処理のために受け付けたが未完了であり、処理されない可能性さえあることを示す。Multi-SET Pushは、その意図的に非確定な封筒へイベント別証拠を加えるだけで、HTTPの意味は変えない。

順序も生まれない。各SETは独立し、要求内の位置は時間的依存を示さず、トランザクション要件もない。二つのイベントの因果関係は、JSON上の隣接とは別の証拠で示す必要がある。

Last Callの現在地

Datatrackerでは第03版をSecurity Areaのactive individual Internet-Draft、目標をProposed Standardとしている。Last Callは8月26日に始まり9月23日に終了する。Working Group stateはNoneで、telechat予定はない。

shepherd記録によれば、SECEVENTは終了済みで、再編成するだけの勢いが不足していた。そのためDeb Cooleyの下でAD-sponsored individual submissionとして進む。これは技術的拒絶を意味しないが、Working Groupの合意と書き換えることもできない。

Security Directorateレビューは軽微な表現提案を添えてReadyとした。一方、確認済み実装はなく、OpenID Shared Signals Frameworkへの導入予定は実装証拠ではない。IANAの措置も将来の承認が条件である。Last CallはIESG承認やRFC発行ではない。

イベント別の証拠を残す

Daniel Kadeは、各jtiについて元要求IDと時刻、正確な確認またはエラー、過去要求との対応、試行回数、次の再送判断、最終的な破棄理由を保存するよう提案する。さらに受信側設定の版、検証時刻、下流での適用済み・拒否・保留状態を結び付ける。

これは編集上のガバナンス設計であり、IETF要件ではない。集計は可能だが、必ず個々のイベントへ掘り下げられる形にする。202が証明するのは封筒の受理までであり、jtiの連鎖を失えば、その後を後日証明することはできない。

出典