要約

  • Agent Authorization Center案では、利用者とエージェントの対応と自動アクセス方針をセンターが保管する。許可名簿のサービスは自動で通し、禁止名簿は拒否し、それ以外は本人に尋ねる。
  • アクセストークンには利用者、エージェント、センターの識別子を含める一方、今回の承認が自動か人手かを表す項目は任意だ。安全性の検討欄はまだTBDである。

玄関の前で毎回呼び鈴を鳴らす代わりに、管理人の名簿へ先に名前を載せる。Agent Authorization Centerの草案は、個人の端末で動くエージェントにこの近道を与えようとする。手間を減らす設計の要はトークンの暗号より、どのサービスを「次から無人で通してよい」と決めるかだ。

草案のAACは利用者の情報、エージェントのグループと個々のエージェントの対応、自動アクセス方針を持つ。エージェントが利用者とAACの識別子を添えてサービスを訪ねると、サービスはAACへの認可手続を案内する。AACは利用者、エージェント、相手サービスを照合する。自動名簿にあればその回の人手を省き、禁止名簿なら拒み、どちらにもなければ本人に確認する。

認可後はOAuth型の認可コードを発行し、サービスがそれをアクセストークンへ交換する。トークンには利用者の口座、エージェント、AACの識別子を含めるべきだと草案は述べる。だが、承認が自動だったか本人によるものかは任意の情報である。受け取るサービスはトークンを検証できても、この一件について本人が画面を見たかを知れない。

名簿は繰り返し作業に便利だ。しかし草案は、載せたサービスで許される個別の操作、名簿の変更履歴、項目の期限、取り消し後の扱いを定めていない。サービスの利用権限に従って処理するとは書くものの、「このサイトへ行ける」と「この購入を決められる」は別の許可だ。前者をAACが扱うなら、後者の境界と証拠を誰が持つのかが実装時の賭けになる。

Security Considerationsの本文はTBDのままだ。既存のOAuth安全性指針RFC 9700と、認可コードを守るPKCEのRFC 7636は比較の基準になる。新しい三者の間でその保護をどう使うかを草案に記す必要がある。配備試験の記録もない。

Datatracker上の状態は個人のInformational草案、I-D Exists。次の検証ではサービスを自動名簿に追加し、一つの限定した作業を許し、その後で項目を変更する。次のトークンを見たサービスが何を確かめられるかを記録すれば、名簿の権限と本人の同意を混同せずに済む。