要約

  • draft-ietf-oauth-status-list-21 では、Referenced Token が URI とインデックスで圧縮リスト内の一つの値を指す。署名または MAC で保護された Status List Token は、多数のトークンについて VALID、INVALID、SUSPENDED などをまとめて伝えられる。第21版は IESG 承認後に RFC Editor のキューへ入った Internet-Draft であり、まだ RFC ではない。
  • 通常、その値が表すのはリスト発行時点の状態である。iat、exp、ttl は発行、期限、キャッシュを扱うが、上流の変更時刻、承認者、理由、Provider での初回提供時刻、relying party の判断時刻を一つにまとめるものではない。
  • Daniel Kade は、プロトコル外に最小限の状態判断レシートを置くことを提案する。トークンとリストの指紋、URI／インデックス、発行者検証、四つの時計、解釈した状態、ローカル鮮度規則、判断、後日の訂正を結ぶ。これは IETF 要件ではなく、提示履歴を恒久追跡する仕組みでもない。

Token Status List の目的を「一件ごとの失効台帳」と考えると、設計の長所を見失う。多数の Referenced Token が同じ圧縮配列を共有し、検証側は一度取得した保護済みリストから必要な位置だけを読む。発行者に対して個別トークンを毎回問い合わせずに済み、転送量を抑えながら一定の群集プライバシーも得られる。

この設計は、情報を捨てた失敗ではない。状態の効率的な配布に必要な情報を選んだ結果である。ところが、その値が入場拒否や取引停止の根拠になると、組織は後になってビットに過大な役割を求めやすい。「その時点で何と表明されたか」と「なぜ、いつ、誰の決定で変わったか」は別の問いである。

承認済みの草案を RFC と呼ばない

Datatracker は2026年6月21日付の第21版を OAuth Working Group の Standards Track Internet-Draft としている。履歴によれば、IESG は6月4日に第20版を承認し、文書は RFC Editor のキューに入った。第21版は6月21日に投稿され、RFC Production Center の状態は8月13日に Awaiting First editor となった。標準化上の重要な段階を通過しているが、調査時点では RFC 番号を持たない。

第21版本文の失効日は2026年12月23日である。20→21 の公式差分によって、分析対象の版を固定できる。編集工程の進捗から実装の普及率や運用品質を推測してはならない。OAuth Working Groupは仕様の作成主体であり、以下の仮想的な運用例の主体ではない。

対象は JOSE または COSE で保護されるトークンで、JWT、SD-JWT、CWT、ISO mdoc の利用例が挙げられる。RFC 7515 の JWS と RFC 7519 の JWT が JSON 系の基盤を、RFC 8392 の CWT と RFC 9052 の COSE が CBOR 系の基盤を与える。Status List Token は元の資格情報そのものではなく、発行後に変わり得る状態を別に表明する保護済み成果物である。

座標は理由を持たない

リスト方式を使う Referenced Token には status_list があり、uri と非負整数の idx を含む。URI は取得先を、インデックスは読む位置を決める。この二つから「どこを見たか」は分かるが、「誰が何を根拠に状態を変えたか」は分からない。

Status Issuer は一エントリーにつき1、2、4、8ビットのいずれかを選び、固有のインデックスを割り当てる。値は各バイトの最下位ビットから最上位ビットへ詰められ、DEFLATE を ZLIB 形式で圧縮する。RFC 1951 と RFC 1950がこの圧縮層を定義する。完成した配列は JWT または CWT に埋め込まれ、署名か MAC で保護される。

役割は三つに分かれる。Issuer は Referenced Token を発行する。Status Issuer は状態情報を受けて保護済みリストを作る。Status Provider はそれを配信する。同じ法人が三役を担ってもよいし、第三者配信を使ってもよい。署名済みオブジェクトを CDN が配っても、CDN が保護済み内容の意味を決めるわけではない。

したがって、証拠の種類も分ける必要がある。署名や MAC はリストの出所と完全性を検証する。HTTP 応答は Provider からある時刻に何を受け取ったかを示す。どちらも、上流のアカウント停止時刻や承認者を自動的には示さない。同一企業の内部であっても、状態決定、リスト生成、配信は別工程である。

初期レジストリでは 0x00 が VALID、0x01 が INVALID、0x02 が SUSPENDED であり、アプリケーション固有値と将来登録用の範囲もある。複数ビットを割り当てた場合でも、ビット群全体で一つの状態を表す。履歴イベントを複数並べたものではない。

さらに、リストの VALID は Referenced Token 自身の失敗を覆さない。トークンの形式、署名、必須 claim、期限などを先に検証する。期限切れトークンは、エントリーが VALID でも期限切れである。状態を得た後も、relying party は用途固有の制約を適用する。「トークン検証」「リスト検証」「状態解読」「最終許可」はそれぞれ別の判断である。

四つの時計を一つの時刻欄に入れない

第一は状態源の時計である。現実または管理上の状態が変わった時刻を指す。アカウント閉鎖、リスク判断、審査による復帰などが考えられるが、第21版はその上流ワークフローを定義しない。コンパクトな値には担当者や理由も必須ではない。

第二はリスト発行の時計である。iat は Status List Token の発行時刻として必須で、推奨される exp は Status Issuer がそのリストを期限切れと考える時点を示す。この区間は保護された表明の時間境界であり、個別状態の変更時刻ではない。

第三は配信・取得の時計である。リストは Status Provider や CDN を経由できる。relying party が実際に取得した時刻は、発行時刻より後になる。この時刻は観測の証拠になるが、上流イベントの時刻にはならない。

第四はアプリケーション判断の時計である。取得直後に使う場合も、キューやバッチ処理の後に使う場合もある。この時点で、ローカル規則がキャッシュの鮮度と状態値を他の条件に組み合わせ、許可、拒否、追加審査を決める。

ttl はキャッシュを制御するが、四つの時計を同一化しない。文書は、取得時刻に ttl を加えて更新を確認する方式と、重要な用途では iat + ttl を基準に小さな配信余裕を置く方式を示す。HTTP のキャッシュヘッダーと保護済み claim が衝突する場合、Status List Token の exp と ttl が優先する。RFC 9110は HTTP セマンティクスを定めるが、許容鮮度はエコシステムと relying party が選ぶ。

短すぎる間隔は Provider に過大な負荷を集中させ、長すぎる間隔は古い表明を使う時間を延ばす。仕様はクライアントに合理的な上下限を持たせ、誤設定または悪意ある値による過剰なリクエストを避けるよう求める。監査では ttl の数字だけでなく、どの起点から数え、判断時に何秒経過していたかを残す必要がある。

過去のスナップショットは変更命令書ではない

標準の取得は最新状態を返す。任意機能として time=<timestamp> を付けた履歴解決がある。対応サーバーは指定時刻に有効だったリストを返すか、エラーにできる。静的ホスティングがクエリを無視して現在のリストを返したとき、要求時刻が返却トークンの iat／exp 区間に入っていなければ、クライアントは拒否しなければならない。

履歴スナップショットは有用である。しかし、10時の VALID と10時15分の INVALID から分かるのは変化が二つの表明の間に反映されたことまでだ。10時2分に人が決定し、10時7分に源システムが更新し、10時14分に配信された、という因果列は別証拠がなければ言えない。

しかも文書は、強い必要性とプライバシー検討がない場合に履歴機能を勧めない。検証者が URI／インデックスを保存して繰り返し調べれば、資格情報の状態プロフィールを作れる。外部者が一覧を収集すれば、発行量や失効率を推測できる。ある判断を説明する証拠と、全員の状態を永続追跡する仕組みは同じではない。

群集プライバシーには端がある

多数のトークンを同じリストに入れることで、Issuer は一回の取得だけから対象トークンを特定しにくくなる。仕様はこれを herd privacy と呼ぶ。リストが大きいほど匿名集合は広がる一方、転送量も増える。

一トークン一 URI、小さすぎるリスト、特徴的なサイズはこの利点を弱める。HTTP リクエストには relying party のアドレスが見えることもある。URI／インデックスの組は追跡可能で、複数の検証者が比較すれば同じ Referenced Token の提示を関連付けられる。RFC 9901は SD-JWT の選択的開示を定義し、RFC 9458の Oblivious HTTP は送信元観測を抑える中継例である。

第三者ホスティング、ランダムまたは疑似ランダムなインデックス、ダミー項目、複数リスト、一回限りのバッチ、再発行時の新規エントリーなどが緩和策になる。状態の語彙自体にも注意が要る。SUSPENDED や業務固有状態は、単なる許可不能以上の情報を外部に示し得る。

判断レシートも同じ節度を守るべきである。完全な資格情報、IP アドレス、あらゆる提示履歴を保存するのではなく、必要なハッシュと時刻だけを期限付きで持つ。履歴問い合わせは実際に判断へ使った場合だけ記録する。

ビットの復号は事務処理ではない

仕様はビット順を明記する。各バイト内では最下位から最上位へ、バイト自体は通常の増加順で進む。誤ったデータを展開し、位置計算を誤り、範囲外インデックスを許せば、隣のトークンの状態を読んだかのような結果になり得る。第21版にはテストベクターがある。

実行順序も記録対象である。まず Referenced Token を検証する。URI を解決し、Status List Token の型、署名または MAC、claim、subject と URI の一致を確かめる。iat、exp、ttl とローカル鮮度を適用し、展開し、インデックスを読み、登録済み意味を解釈して、最後に業務規則を適用する。

インデックスが範囲外なら状態について何も表明できず、Referenced Token は拒否される。リスト検証に失敗した場合も状態は不明であり、拒否が推奨される。これは明示的な INVALID とは異なる。前者は証拠取得の失敗、後者は Status Issuer の状態表明である。

二つの指紋と四つの時刻を残す

Daniel Kade の提案するレシートは、Referenced Token の最小指紋と、実際に使った Status List Token の正確な指紋から始まる。URI／インデックス、Status Issuer、観測した Provider、鍵解決、署名／MAC 検証、復号実装またはテスト適合も記す。

次に、状態源の変更時刻が確認できる場合だけそれを記し、不明なら不明のままにする。iat、exp、ttl、取得時刻、使用時のキャッシュ年齢、判断時刻を分ける。現在照会か履歴照会か、要求 timestamp、数値状態、登録意味、ローカル鮮度上限、適用規則、実行結果、後日の訂正・終了を結ぶ。

これは Token Status List への追加提案ではない。長く残る結果を説明するためのローカル統制であり、ハッシュ、最小参照、アクセス制御、短い保存期間を優先する。The Policy Mirrorは宣言と観測の照合を、Running-Code Primacyは実行経路の確認を、Reality, Not Advocacyは不明を不明として残す態度を与える。いずれも実在する OAuth 障害の証拠ではない。

出典