Summary

  • draft-saha-aadp-bound-permit-00 は、送信側の状態に依存する AADP 判断を、一つの受信者、一つの提示鍵、一つの HTTP 要求、一つの行為インスタンスに結び付け、信頼境界の外へ運ぶ短命な許可証を提案する。
  • 許可証の検証は必要条件にすぎない。参照された mandate、受信者のローカル方針、判断の currentness がそれぞれ成立しなければならず、どの層も他の層を上書きできない。
  • (iss, jti) の原子的な消費は検証順序の最後に置かれる。同じ本文の再送は保存済み結果を返せるが、外部効果の exactly once は保証されない。結果不明なら新しい許可で再送せず、照合する。

状態の場所でしかできない判断

エージェントが40ユーロの支払いを求める。送信側の PDP は累積予算、未解消の予約、期限内の承認、過去の実行、キルスイッチを見て permit を返した。支払サービス側には、その台帳がない。到着時に同じ判断を再計算することはできない。

受信者が確認できるのは、誰が判断したか、どの種類と上限について信頼されているか、何を判断したか、届いた要求がその対象か、である。要求額が40.01ユーロに変わっていれば、正しい JWT 署名だけでは足りない。

Shamik Saha の action-bound permit revision 00 は、この限定された空白を扱う。ヘッダーに Standards Track を意図すると記された現役の個人 Internet-Draft であり、RFC、IETF 合意、ワーキンググループ成果、導入実績ではない。

文書自身も、これは一つの判断を運ぶ封筒であり、ドメイン横断の認可制度ではないと線を引く。

受信者、鍵、バイト列、意味、時間

形式は typ が aadp-permit+jwt の compact JWS JWT である。aud は一つの受信者だけを示し、複数なら拒否する。cnf.jkt は提示者の proof-of-possession 鍵を指定する。信頼境界を越える場合、その鍵で HTTP Message Signature を検証しなければならない。これを省けば bearer token になり、草案の条件を満たさない。

署名対象には最低でも method、authority、path、query、Content-Digest、Idempotency-Key、許可証フィールドを含める。受信者は受け取った本文の正確なバイト列から、解析や再シリアライズより先に Content-Digest を再計算する。意味が同じ JSON でも表現が変われば拒否され得る。

意味の照合は別である。登録された行為型が、path、query、本文から行為オブジェクト A を導く規則を持つ。受信者は RFC 8785 で正規化し、domain separation を加えて action_digest を再計算する。バイト列が同じでも、金額や受取人の導出が決定時と違えば失敗する。意味が合っていても、改変された wire bytes を免責しない。

さらに exp は AADP の execute_within を越えない。指定がなければ iat から最大120秒で、行為型は短くできても長くできない。記録する clock skew は最大60秒であり、本来の締切を延ばす道具にはならない。

使い回しにくいことは欠点ではない。一つの宛先、一つの鍵、一つの要求、一つの行為、一つの短い時間だけに狭めることが設計目的である。

三つの拒否権

受信者は三条件の AND で動く。まず bound decision と要求の結び付きが検証できること。mandate が参照されるなら、同じ取引について独立に PERMIT となること。そして受信者自身の方針が許すことだ。

提案中の Agent Authorization Envelope は、何を委任されたかを扱う。bound permit は、状態を持つ PDP が今どの具体的行為を許したかを扱う。受信者が AAE を得た場合、digest を比べ、主体、有効期間、単回性、失効、委任を自分で評価する。DENY、PENDING、digest 不一致、必須 mandate の取得不能はいずれも拒否である。許可証は PENDING を PERMIT に変えない。

ローカル方針も残る。署名、金額、mandate が正しくても、口座状態、不正対策、制裁、サービス上限で拒否できる。他ドメインの判断を検証することと、自組織が結果を引き受けることは同じではない。

発行者への信頼も scope table で限定する。鍵、行為型、フィールド上限、有効期限、最低 currentness を明示する。少額送金の発行者を信頼したからといって、口座削除や無制限額まで信頼したことにはならない。

「短命」と「現在も有効」は違う

署名後に方針が置き換わり、mandate が失効することはある。短い exp は変化を発見せず、見えない期間を短くするだけだ。

草案は二モードを区別する。time-bounded は exp まで追加確認をせず、設定上そのリスクを許す発行者・行為だけに使う。status-checked は検証時点で、許可証、policy_version、mandate が現在も有効かを status list または発行者署名の新鮮な statement で確認する。

状態を取得できない、解析できない、古い場合は原則 status-unavailable である。限定的な fail-open は、低リスク分類についてローカルに明示し、監査し、記録した場合だけ許される。一般的な「token valid」に吸収してはならない。

Lu Heng の reality layers を当てはめれば、署名済み許可証は過去の判断の表現、status check は後の観測、外部効果はさらに別の現実である。三つを関連付ける必要はあるが、前の記録を後の事実と同一視してはならない。

十三番目にだけ状態を変える

順序は、構造、発行者と署名、audience、時刻、行為型、発行者 scope、本文 digest、提示者署名、semantic action、currentness、mandate、ローカル方針、最後に atomic consume である。効果はその後に実行する。

先に消費すれば、攻撃者は誤った audience や壊れた本文で有効な一回を潰せる。ローカル拒否で許可証を失わせることもできる。consume store が利用不能なら could-not-check として止める。全サービングノードで共有された durable かつ atomic な store を持てない受信者は、この許可証を受け入れてはならない。

jti は AADP 内部の permit_id ではない。相互に導出できない値として発行し、送信側だけが対応表を保つ。境界を越える jti が Idempotency-Key になる。内部ライフサイクルの識別子に、外部 credential の意味を持たせないためである。

初回は consume、effect、result 保存を行う。後から同じ (iss, jti) と同じ content digest が来れば、保存結果を返し二度目の効果は起こさない。本文が違えば idempotency-conflict。初回が実行中なら retryable な応答になる。

それでも exactly once ではない。応答が失われ、効果が起きたか不明なら、新しい許可証を得て送り直してはならない。jti または受信者の action ID で照合し、解決しなければエスカレートする。idempotency は再試行を束ねるが、現実の不明状態を消さない。

相手側の署名で記録を閉じる

受信者は consume と効果の試行後、permit、request digest、signature base digest、action digest、mandate verdict、outcome、recipient action ID を含む confirmation に署名する。提示者はその digest を AADP report に入れ、present_bound の discharge evidence とする。

発行者は「判断した」、提示者は「この要求を送った」、受信者は「こう扱った」と別々に署名する。受信者が署名した refusal なら failure と no_effect: true の根拠になる。単なるエラー応答では効果がなかったと証明できず、confirmation 不在や effect-unknown は timeout のままである。

許可証は single hop で、parent claim は chained-permit-unsupported として拒否する。B が C を呼ぶなら、B の状態で新しい判断を行う。前の hop は provenance として参照できても authority ではなく、C の検証を省略させない。

Minimum Initial Specification の役割はここにある。同じ試行を照合する最小の binding と refusal を共有し、発行者選択、リスク許容、本地の結果判断は当事者に残す。共通仕様は中央の命令権ではない。

実装証拠には二つの空欄がある

草案は onedoor の固定 commit を参照する。manifest は24 vector、traceability map は22を implemented とする。未実装は、status-checked で差し替え済み policy を検出する V17 と、別 request digest を指す recipient confirmation を検出する V22 である。草案は permit suite 92 tests の成功も報告する。

著者関連の再現可能な証拠としては有用だが、独立検証ではない。指定 commit の message は permit 専用リリースではなく、リポジトリ内の別メンテナンスを説明している。Running-Code Primacy は第三者が vector、とくに二つの gap を実行し、差異を公表することを求める。snapshot 自体を合意とみなすことではない。

情報源と限界

これらは、活動中の個人提案、その依存仕様、著者関連の実装 snapshot を確認する。IETF 合意、RFC、独立相互運用、安全な導入、正しい方針、正直な受信者、exactly-once effect は証明しない。本稿が扱うのは revision 00 の一論点だけである。一つの stateful AADP decision を、受信者、提示者、要求、行為に結び付いた一回の attempt として運び、受信者の署名回答で閉じる。