要約

  • 9月29日付の個人Internet-Draftは、認可サーバーが要求ごとに方針を評価し、単一の資源サーバー宛てに短命の「Transactional Access Token」を発行する案を示した。状態はI-D Existsであり、採択済みの標準や稼働実績ではない。
  • 一つの作業で複数の資源サーバーを使っても、txnの値は宛先ごとに分ける。認可サーバーには元の対応関係が残るうえ、共通のclient_id、文脈情報、発行時刻からも相関が生じ得ると草案は認めている。

ある代理プログラムが、利用者のために二つのサービスへ順にアクセスするとする。一般のOAuthアクセス・トークンは権限の範囲を伝えるが、その一回の呼び出しがどの作業に属するかまでは十分に示さないことがある。draft-tulshi-oauth-transactional-access-tokens-00は、認可サーバーに取引単位の判断を担わせ、相手の資源サーバーに必要な情報を付したトークンを渡す提案だ。AIエージェントは主要な想定例だが、提案をAI専用の仕組みと読むべきではない。Datatracker上では個人提出のStandards Track志向の草案にとどまり、RFC番号もない。

識別子の作り方には、見せる範囲の設計が表れている。認可サーバーは内部の取引IDを外に出さず、最初の資源サーバーだけをaudに持つtxnat+jwtを発行する。同じ作業について別のサーバー向けトークンが必要なら、クライアントは不透明な取引ハンドルで追加発行を求める。二つのトークンのtxnは異なり、発行元以外がその値だけから同じ取引だと判定できてはならない。一方、発行元は内部IDを通じて監査用に結び付けられる。現場には局所的な記録、中央には横断的な記録という非対称性が生まれる。

だからといって取引全体が匿名になるわけではない。草案のプライバシー節は、client_idが資源サーバーをまたいで同じであることを明記する。主体の識別子は宛先ごとに分け、文脈に安定した余計な識別子を載せないことを勧めるが、近い時刻に出たトークン同士は、協力するサーバーに推測され得るとも述べる。消えたのは共有のtxnという一つの照合キーであり、すべての照合方法ではない。中央に残る対応表の閲覧と保存にも統治が必要となる。

有効期間の短さにも同じ注意が要る。草案ではiatからexpまでを300秒以下にすることを推奨する。しかし発行を求めるためのリフレッシュ・トークンやクライアント資格は長く残り得る。意味があるのは、元の資格が有効でも認可サーバーが個別の取引を拒めるという再評価だ。ベアラー型なら短い期間内の再利用は可能で、送信者拘束は推奨にとどまる。短命という言葉を、一回限りの使用や正当な作業の証明と取り違えてはならない。

以前のOAuth Transaction Tokens案は、同じ信頼領域の内部で取引の文脈を運ぶ仕組みを扱った。BTWの既報は署名された内部トークンに入る主張の出所を問うている。今回の論点は、その外側にいる特定の資源サーバーへ取引対応のアクセス・トークンを渡す際、複数の記録を誰がつなげられるかだ。各サーバーが自分のtxnを記録しても、横断的な再構成は認可サーバーの協力なしにはできない設計である。

出典