エージェントの権限は願い事では決まらない

要約

IETFの新しい個人草案は、利用者がサービス側の画面で権限、期限、必要なら呼び出し回数の上限を決め、一回限りの接続票を自分でエージェントに渡す方式を提案する。
利用者が文章で書く目的は同意と監査の記録になる。次のAPI呼び出しを許すかどうかは、選択した権限と毎回の検査が決める。

願い事欄の隣に大きなチェック欄

「この請求書だけ送って」と書いた人が、その横で「すべての請求書を編集できる」を選んだらどうなるか。エージェントが次の操作を試みるとき、サービスが判定するのは選んだ権限だ。Christopher Emersonの改訂草案は、目的を記した文章と実際に効く許可を別々のものとして扱う。画面がこの違いを隠せば、利用者は自分の願いに署名したつもりで、ずっと広い操作権を渡すことになる。

10月27日の公開通知が版01を告知した。IETFの文書記録では、RFCの審議系列に入っていない個人Internet-Draftとして扱われている。設計の最初の場面は、エージェントのチャット欄ではない。利用者が自分のデータを預けたサービスにログインし、その接続管理画面で権限を選ぶ。サービスは利用者自身の権限から上限を計算する。利用者は範囲と期間を決め、必要なら資源群ごとに一定期間の呼び出し上限を置く。既存の許可も見直し、不要なものは取り消せる。

草案には、本人確認器で選択内容に署名する任意の手順もある。署名の対象は権限、期限、回数上限、サービスが示す目的、利用者の記述を含む正確な組み合わせだ。サービスは短命で一度しか使えない接続票を一回だけ表示する。利用者がそれをエージェントに渡し、エージェントは範囲を絞ったアクセストークンに交換する。自動更新はできない。許可を決めて票を渡す場所を利用者側へ移すのが、この提案の骨格である。

説明文は証拠、権限表は錠前

版01で追加された節は、サービスが申告する用途と利用者が自由に書く意図を、同意、照会、監査、取り消しの記録に残す。文章を政策エンジンに読ませて権限へ翻訳する仕組みではない。自由記述によって許可を広げてはならず、自動解釈は人の確認に回す補助情報にとどめるという。だから「この一件だけ」という文も、広く選んだ権限を自動的には狭めない。細かく制限したいなら、サービスが細かい選択肢を作る必要がある。

エージェントがAPIを呼ぶたび、introspectionが選択済みの範囲と回数を検査して記録する。特定の権限には「使用のたび確認」を付けられる。その操作では要求をいったん止め、正確な要求内容をダイジェストで特定する。利用者が自分の側の画面で本人確認器を使って承認し、エージェントは承認識別子を付けて再試行する。拒否された要求はそこで終わり、接続を取り消せば待機中の承認も使えなくなる。ここまで来て初めて、一般的な「請求書を扱う権利」と「この宛先にこの請求書を送る許可」が分かれる。

版00にも人による票の受け渡しはあった。版01は回数上限、既存許可の確認、本人の在席手順、個々の操作の承認、取り消し後の処理を詳しくし、自由記述の役割を明記した。著者が運営する実装も紹介するが、独立した適合性試験は示していない。草案自身が残す難問は表示画面だ。エージェントが確認内容を描く端末を支配できるなら、本人が確認器に触れた事実だけでは、何を見て承認したかは分からない。