要約

  • 9月28日付の個人Internet-Draftは、クライアントが認める証明者をclient_attestersで示す案を提示した。認可サーバーがその証明者を信用するかどうかは別の判断である。
  • 承認を取り消しても、変更がキャッシュ越しに見えるまで新しい提示に影響しない場合があり、すでに成立した権限付与やアクセストークンは自動的に失効しない。

鍵を削除した瞬間を、運用記録に「失効完了」と書いてよいだろうか。OAuth 2.0 Client Attester Endorsement の初稿を読むと、答えは条件付きになる。鍵の公開元での変更、認可サーバーによる変更の観測、新しい認証の拒否、過去の認可を利用したアクセスの終了は、同じイベントではない。草案が定めようとするのは証明者の承認関係であり、発行済みアクセスを全域から消す装置ではない。

K. McGuinness が2026年9月28日に出した -00 は、Standards Trackを目指す個人のInternet-Draftである。Datatracker上の状態が示すのは草案の存在であって、RFC化、OAuth作業部会による採用、導入実績、被害事例ではない。基盤にある証明に基づくクライアント認証の草案が扱うのは証明と提示の仕組みだ。今回の提案は新しい資格情報を足さず、特定のクライアントについて誰の証明を受け付ける余地があるかを、クライアント側のメタデータに明記する。

登録済みクライアントにもClient ID Metadata Documentにも、client_attestersを置ける。そこに証明者と検証鍵の所在を示すのは、クライアントの発行責任者である。ただし責任者が指名しただけで、認可サーバーに信用が生まれるわけではない。このプロファイルが適用される要求では、権威あるメタデータに証明の発行者への現在の承認があり、認可サーバー自身の方針がそのクライアントに対して証明者を許し、信用する鍵の経路を決める必要がある。サーバーは承認集合を狭められるが、未承認の証明者を別の信用経路から加えてはいけない。証明者への承認は、利用者の委任でも資源へのアクセス権でもない。

では取り消しはいつ届くのか。草案の第6.1節は、承認メタデータとJWK Setのキャッシュについて、有限の最大保存期間を設定し、期限切れのコピーを再検証または更新できなければ使わないよう求める。しかし、すべての運用者に共通する上限値は定めない。新しい承認や取り消しを公表する側は、草案だけから反映所要時間を計算できない。予測可能な上限が必要なら、信頼の取り決めに書くべきだと本文はいう。この規則が対象とするのはキャッシュのコピーであり、権威あるクライアント登録そのものではない。認可サーバーが更新を取得または保存した後は、次の提示から新しい状態を使う。一方、サーバー自身の方針で拒否すれば、キャッシュ期限を待たず後続の要求に効く。

その先にも線が引かれている。第6.3節によれば、承認の取り消しは将来の認証を止めるもので、既存の権限付与とアクセストークンはそのままでは取り消されない。証明を必要とする更新要求は再検査されるが、アクセスの終了には関連する権限付与とトークンを別途取り消し、更新発行も止める必要がある。RFC 7662のイントロスペクションなら失効済みトークンを非アクティブと報告できる。ローカルにトークンを検証する資源サーバーは別の失効手段か、有効期限まで待つ運用に依存する。ここで問題にしているのは特定の実装の欠陥ではなく、提案文書に明記された境界だ。

証明そのものを過大評価する危険もある。発行責任者が証明者と鍵を選べる設定では、自ら証明者を運営できるため、その証明に発行責任者から独立した保証はない。別のクライアント認証方法を許して証明を任意にしているなら、client_attestersという項目があるだけで証明提示が必須になるわけでもない。元データの公開先を支配されたとき、今回の案だけで変更が悪意によるものか独立に判定する仕組みもない。

運用者が後で「止めた」と説明するには、単なる鍵削除の時刻より多くの記録が要る。承認一覧の前後、変更権限、各認可サーバーの鍵信頼方式とキャッシュ期限、変更後に拒否された最初の新規提示、対象の権限付与とトークン、更新停止、資源サーバー側の扱いを分けて残すべきだ。これは本稿の監督上の提案であり、IETFが義務付けた書式ではない。

出典