要約

  • 9月29日付の個人提出草案 Agent Registry Protocol 第04版は、権限評価の結果を決定、理由コード、評価時刻、適用した方針などで表す新たな仕様案を加えた。条件付きの許可には条件を、重要な過去・派生情報には出所のチェックポイントを求める。
  • 許可を支えた情報の有効期間をHTTPキャッシュが超えてはならず、重要なイベントの欠落を検知した利用者は権威ある状態と再同期するか、肯定しない結果を返すという提案だ。IETFが承認した標準でも、運用実績の報告でもない。

登録簿からエージェントの識別子が返る。ところが、委任はその数分前に停止されていた――この場合、識別子の検索は成功しても「実行してよい」という判断は成立しない。Sankarshan MukhopadhyayのARPA草案第04版が掘り下げたのは、この時間差である。文書はIETFの保管庫で公開されている現役の個人提出Internet-Draftだ。表紙の「Standards Track」は目指す地位を示すにすぎず、作業部会の採択やIETFの承認、RFC化を意味しない。

第03版も、識別、認証、能力の提示、実際の権限を混同してはいなかった。鮮度が重要な状態を評価し、判断不能を安易に許可へ変えないという考え方も既にあった。したがって新たな点は、一般原則そのものではなく、それを通信上の結果と障害時の処理へ細かく落とした第29節である。第29.1.7項は、決定と機械可読の理由、評価した時刻、選んだ方針の識別子・版・適用可能性を結果に含める。allow_with_conditionsなら条件は省略できない。過去の情報や加工された情報が結論を左右したときは、元の状態をたどれるチェックポイントも要る。

ここで「許可」と呼べる結果にも線が引かれる。第29.3項ではallowと条件付きの許可だけを肯定とし、deny、indeterminate、not_applicableを別々の非肯定の結果として残す。第29.4項は、古い状態、矛盾する状態、解釈できない重要な状態を黙って有効へ読み替えることを禁じる。これらはあくまで草案内部の規定案であり、あらゆる事業者に現に課された義務ではない。ただ、利用側がどの版の方針といつの観測に依拠したかを示せないなら、単純な緑色の表示では説明責任を果たせないことが分かる。

キャッシュの扱いは運用上の要点だ。第29.7項はHTTPキャッシュ自体を否定しないが、権限評価に使う重要情報の有効性・鮮度の上限より長く応答を保持して肯定判断に用いることを認めない。識別情報の保存期間が長くても、許可の根拠に同じ寿命が与えられるわけではない。鮮度が確認できなければ非肯定にとどめる。草案には、これが既に障害を防いだという測定結果も、実装の普及率もない。

もう一つの要点は更新の欠落である。イベント配信口を備えると広告する登録機関には、イベントの安定した識別子と欠落検知に足る順序位置またはチェックポイントを求める。重要な変更を取りこぼした利用側は、不完全な配信だけで「まだ許可」と言い続けてはならない。権威あるスナップショットなどに再同期するか、肯定を控える。復旧して再評価する道があるため、これは無期限の拒絶ではない。書き込みについても原則拒否とし、運営者という肩書だけで無関係の委任記録を変更する権限は生まれないとする。

第29.16項は将来の適合性主張に、実装する役割と正常・敵対の双方の試験項目を結び付ける。試験を要求する文章と、試験に合格した独立実装の存在は別だ。今回の改訂が示したニュースは、長く残る登録情報と、その瞬間に限られる肯定的な権限判断を、応答の形で切り離そうとしている点にある。

出典