要約

  • 最初の代理が出した値と次の代理が受け取った値は、認証された引き継ぎの中で同一でなければならない。
  • 「1を受けて1を出す」「3を受けて2を出す」はそれぞれ合格し得るが、二つの記録を一本の鎖にはできない。

一社目は権限値1を受け取り、1を渡した。二社目は3を受け取り、2を渡した。どちらも受け取った値より広いものを出していない。検査画面には二つの合格が並ぶだろう。しかし一社目の1と二社目の3の間には、委任が存在しない。見栄えのよい検査履歴は、その空白を埋めない。

この例を示すのは、Sumit P. Ahujaが10月20日に提出した「A Policy Grammar for Inter-Domain Agent Routing」第03版だ。個人提出のInternet-Draftであり、IETFが承認した標準ではない。焦点は代理そのものの賢さより、企業の境界をまたぐ時に何を証明したと言えるかにある。

提案は四つの属性を分ける。受託の優先度を段階的に下げる通知、自社の窓口に関する拘束力のない順位、当事者間の契約でだけ意味が決まる不透明なタグ。この三つは二者間の情報だ。残る「鎖の有効性」だけが複数段階を通じた判断の対象になる。二者間の約束を全員に通じる許可証へ昇格させることはできない。

複数段階の鎖には、まず各段階で NO_BROADER という比較結果が要る。次に、前段階の出力と次段階の入力が同じ値であり、その同一性が両者を結ぶ認証済みの関係に含まれる必要がある。比較には同じ不変のプロファイルと規則を用い、規則の推移性は定義から導くか機械的に確認する。「推移的」と書いただけでは足りない。局所的な成功は LOCAL_ONLY のままだ。

不変のプロファイル識別には、固定された標準文面か内容に基づく識別子が必要だと草案は定める。根拠として引用する能力レシートの草案も、後から意味を変えられる識別子を退ける。ただし隣接する委任を認証する仕組みはAhujaの草案の外にある。この文書自体は証拠を生成しない。

比較が規則に反して広がった場合は BROADER、必要な比較を完了できない場合は UNDECIDED。原因を混ぜれば障害対応を誤る。草案には導入件数や実際の事故の計測値はない。実装が示すべき事実は、各社間で共有された値とその認証、規則の固定性、推移性の検証結果だ。二つの合格印より、真ん中の接続を見せてもらう方が早い。

Ahujaの草案 · 能力レシートの草案 · 代理通信の要件草案