要約

  • draft-ietf-oauth-attestation-based-client-auth 第11版は2026年9月3日に公開され、OAuthワーキンググループは8日にLast Callを開始した。意見の期限は22日である。
  • サーバーがチャレンジを使うことは任意だ。寿命と一回限りか再利用可能かは、すべてサーバーのローカルポリシーで決まる。クライアントは最新値を使わなければならないが、再利用してよい。
  • 一回限りのサーバーは二度目をuse_attestation_challengeで拒み、新しい値を返す。クライアントは一度だけ再試行し、無限に繰り返してはならない。DPoP併用モードはRFC 9449のnonceを使う。
  • 第11版は方式と署名アルゴリズムのメタデータを加えたが、消費やリプレイの方針は示さない。Daniel Kadeはprofileで鮮度ポリシーを宣言する案を示す。IETFの現行要件ではない。

Last Callは合意を確かめる入口だ

OAuthワーキンググループの通知は、9月22日までに支持を表明するか、反対理由を説明するよう求めている。Datatrackerでも第11版は「In WG Last Call」と表示される。これは文書を先へ進められるか判断する制度上の節目であり、完成したRFCやIETF全体の承認ではない。

提案の狙いは、同じclient_idを名乗るソフトウェア全体ではなく、一つの導入インスタンスを認証することにある。Client Attesterが、そのインスタンスの公開鍵に結び付けたClient Attestation JWTへ署名する。インスタンスはサーバーとの通信時に、対応する秘密鍵をいま保持していることを別の証明で示す。

通常モードの証明はClient Attestation PoP JWTである。作成時刻と一意なjtiを含み、サーバーが値を渡した場合は不透明なチャレンジも入る。値はエラー応答、以前の別の応答、専用challenge endpointのいずれからも届き得る。受け取った後、クライアントは常に最新のものを採用する。

第11版が共通化しないのは、その値の寿命と消費回数だ。同じチャレンジを複数のPoP JWTに使えるかは、認可サーバーまたはリソースサーバーのローカルポリシーだけで決まる。クライアントには再利用が認められ、サーバーには二度目を拒む自由がある。

この余地には意味がある。値を一回で消費すれば管理は厳しくなるが、状態保存と並行処理の調整が必要になる。短い期間の再利用なら分散システムを動かしやすいが、同一証明のリプレイはjtiなどで別に見抜かなければならない。問題は選択肢の存在ではない。どちらの契約かを、受け取った値から判別できないことだ。

二度目の失敗が仕様の問い合わせになる

不一致が起きた後の手順は明確だ。認可サーバーはHTTP 400とuse_attestation_challengeを返す。保護リソースはHTTP 401の認証応答を使う。どちらもOAuth-Client-Attestation-Challengeヘッダーに新しい値を載せる。クライアントは新しいPoP JWTを作り、一度は再試行すべきだが、際限なく繰り返してはならない。

停止条件は整った。しかし、最初の拒否そのものがポリシー照会になっている。アプリケーションがendpointから値を先に取得し、複数のtoken要求へ配ったとする。再利用可能なサーバーなら、それぞれ異なるjtiを持つ証明を処理できる。一回限りなら最初の一件が値を消費し、残りはほぼ同時に作られていても失敗する。

セキュリティの章を読むと、「チャレンジ対応」だけでは保証を表せないことが分かる。サーバーは有効なスライド窓の間、確認済みjtiを保存できる。同じPoP JWTが再送されれば、リストとの照合で検出する。challenge endpointが発行した値も保存すれば、サーバー自身が選んだ値による強いリプレイ検出を得られる一方、状態と追加往復の費用がかかる。

別の実装は、確認済み一覧を持たない自己完結型チャレンジを使える。拡張しやすいが、保証するのは鮮度だけで、許容窓の中のリプレイを防がない。さらに、Client Instanceのセッションへ特定の値を結び付け、そのセッションで期待する一個だけを検証する構成もある。同じclaimに入る値でも、運用と安全性は同じではない。

チャレンジを任意としたのは、必須実装を軽くするためだ。jtiは必須のままで、既定の代替手段になる。サーバーにはiatまたはチャレンジに基づく時間窓の検査も求められる。それでも、チャレンジが存在するだけで一回限りやリプレイ防止を意味するわけではない。

DPoPのnonceは別の経路に残る

併用モードでは、RFC 9449のDPoP証明一つでインスタンス鍵の所持とアクセストークンの送信者制約を担う。第11版は、このモードがDPoP nonce機構だけを使うと明確にした。

期待するnonceがなければ、エラーはuse_dpop_nonceで、新しい値はDPoP-Nonceヘッダーに入る。通常モードのuse_attestation_challengeではない。challenge endpointがDPoP nonceを事前に返すことはできるが、同じ窓口を使うからといって二種類の鮮度値が同義になるわけではない。

第10版との公式差分には、併用モードでのDPoP nonce専用化、endpointからの配送、任意チャレンジとエラーの整理が並ぶ。SDKが両者を一つのキャッシュで扱えば、新しい版がせっかく明確にした境界を消してしまう。

メタデータが知らせるのは能力までだ

第11版はRFC 7591の一般モデルに沿ってクライアントメタデータを加えた。クライアントとサーバーは、対応する署名アルゴリズムやattestation_pop_jwt、dpop_combinedといった方式を公開できる。challenge_endpointがあれば、値を事前取得する場所も分かる。

それでも、要求の組み立てを最も変える部分は見えない。チャレンジが必須か、寿命はどの程度か、一回で消費されるか、確認済み値を保存するか、自己完結型が鮮度しか保証しないか、どのルールがどのモードに属するかは宣言されない。ポリシー変更とエラー増加を結び付ける版番号もない。

正確な秒数やデータ構造を公開する必要はない。負荷に応じて値を変える余地も残せる。だがsingle-use、reusable、session-boundという外から観測できる分類は出せる。witnessed-stateかfreshness-onlyかも、内部実装をさらさずに保証の違いを表す。

Daniel Kadeが提案するのは、profileに置く小さなfreshness-policyだ。証明方式ごとに、サーバー提供の鮮度が任意か必須か、配送経路、寿命クラス、消費方式、リプレイ上の姿勢、自動再試行回数、ポリシーepochを示す。署名付きの発見receiptで、クライアントが参照したメタデータ版に結び付けてもよい。

これは第11版にない編集上の提案であり、ワーキンググループの合意でもない。文書はエコシステムによるprofileを認めている。基本仕様の裁量を保ちつつ、確定した挙動を必要とする導入分野だけが先に試せる場所である。

出典