Summary

  • 個人草案は /.well-known/agent-capabilities にフロー、認可サーバー、呼び出し先を掲示する方式を提案した。
  • 掲示されたどのフローにもない操作は閉じる。以前に承認した認可インスタンスに含まれていても、リソースサーバーは実行してはならない。

アプリの配布物はそのまま。けれどエージェントが見る業務の入口だけは変わる。11月2日の草案では、サービスのオリジンが能力文書を配り、エージェントはそこから利用可能なフローと認可先、呼び出し面を知る。承認済みの認可インスタンスも万能の通行証にはならない。文書内のどのフローにも載らない操作を、リソースサーバーは実行できない。認可サーバーも、その操作を含むインスタンスを拒むべきだとされる。

これは撤回を効かせる仕組みであると同時に、静的ファイルの編集権限を重くする。草案の第8.6節は、オリジンの静的コンテンツを書ける攻撃者が文書を置き換えれば、その後に訪れるエージェントを別の呼び出し面へ誘導したり、本来のフローから遠ざけたりできると記す。アプリ本体の変更は要らない。著者はこの文書をアプリのリリース管理に含めるよう勧める。RFC 8615が指摘した、管理者が見落としがちな .well-known の場所に、実行範囲を左右する情報を置くからだ。

ネイティブアプリでは、同じ文書をパッケージに同梱してオフライン発見に使える。ただし各セッション最初の遠隔操作前にオリジン版を確認し、食い違えばそちらを採用しなければならない。古いパッケージに操作が残っていても、現行のオリジン版から消えれば実行は禁止される。配布の審査と実際の権限更新は別の時計で動く。

表示名やロゴも証明書にはならない。草案はオリジンと認証された通信路を結び付けの基礎とし、OAuth保護リソースメタデータを使う場合は認可サーバー一覧の一致を求める。IETFの記録では、まだ個人草案である。実際のアプリで入口が変わったかを判断するには、配信ファイルの変更履歴とサーバーの拒否記録が必要だ。