要約

  • RFC 9767 の「アクティブ」は、発行者、失効、時刻、証明、対象 RS、要求アクセスがそろった文脈付きの判定である。
  • AS はトークンについて答える。RS は現在の提示を検証し、ローカル方針を適用し、エラー、公開資源、保護された処理のどれを返すか自ら決める。
  • 運用記録は、イントロスペクション、当該メッセージの証明、RS の判断、観測された効果を四つに分け、キャッシュ年齢と下流派生を隠さない。

真偽値の主語

クライアントがアクセス・トークンを RS に提示する。RS はその値を AS に送り、状態を尋ねる。このとき問い合わせを署名するのはクライアントではない。RS が自分の鍵と識別子を使って、RS として質問する。

要求には、提示されたトークン値、推奨される証明方式、RS の識別、必要なら処理に要る最小アクセスが入る。AS は与えられた全パラメータを考慮しなければならない。理解できないアクセス要素などがあれば、アクティブとは答えられない。

つまり active はトークン単体の永続属性ではない。ある RS には適切でも別の RS には不適切になり得る。読み取りには足りても書き込みには足りない。期限内でも、示された proof が違えば条件を満たさない。

RFC 9635 がクライアントと AS の grant を中心に据えるのに対し、RFC 9767 は疎結合な AS と RS の接続面を定める。相互運用できることと、一方が他方の資源を統治することは同じではない。

RS の鍵を AS がどう信頼するかは範囲外である。事前登録も TOFU もあり得る。署名成功は採用された登録モデル内の鍵保有を示すだけで、資源割当や組織上の権限まで自動的に保証しない。

アクティブを構成する条件

肯定には複数の述語が必要だ。処理中の AS が発行したこと、失効していないこと、期限切れでないこと、指定された方式で鍵に結び付くこと、問い合わせ元 RS に提示してよいこと、access があればその要求に適することが全部そろう。

否定は原因コードではない。見つからない、判断できない、期限切れ、失効、対象違い、権限不足はいずれも false になり得る。false のとき他のフィールドは省かれる。「false だから失効」と書く監査は、仕様にない診断を作ってしまう。

true も万能ではない。現在の利用者の意図、要求本文の安全性、対象物の存在、残高や割当、詐欺検知、実行完了を証明しない。AS がこの文脈でトークンを評価した結果であって、業務結果ではない。

肯定応答にはアクセス権、鍵、フラグ、時刻や主体情報を含められる。ただしアクセス権は当該 RS 向けに絞れ、空配列にもできる。トークン値そのものは返してはならない。RS が受け取るのは必要範囲の投影であり、grant 全体ではない。

資源に対する決定者

RFC 9767 はイントロスペクション後の扱いを RS に残す。権利が足りなければエラーを返すことも、公開版の資源を返すこともでき、最終応答は RS の裁量である。

この裁量は認可を弱める例外ではない。AS は発行と失効を知る。RS は HTTP メソッド、具体的な資源、現在状態、ローカルな安全制約、業務規則、実行可能な代替応答を知る。作用点に決定を置く設計である。

したがって RS は判断記録を残す。資源、操作、参照した権利、方針バージョン、追加制御、ソフトウェア版、選んだ応答を分ける。権利不足時に公開情報を返したなら、それは保護情報への認可成功ではない。

効果も別だ。書き込みが commit した後に応答が失われることも、受理後に下流が失敗することもある。HTTP 200 の内部で業務が失敗する場合もある。AS の true は、いずれも観測していない。

トークンと今回のメッセージ

鍵束縛トークンでは、トークン検証と proof 検証を混ぜてはならない。鍵を持つことだけを確認しても、その鍵が侵害されていたり confused deputy が使ったりすれば、権利外の要求を正しい形式で作れる。

逆に、AS の肯定だけでは現在メッセージの proof を検証したことにならない。対象 URI、署名対象、nonce、時刻は要求ごとに変わる。RFC 9767 は proof を毎回独立に確認し、前の結果を次へキャッシュしないよう求める。

HTTP Message Signatures、DPoP、証明書束縛トークンは、それぞれ異なる提示束縛を実現する。それらが RS の業務判断を代行するわけではない。ログではイントロスペクション ID と proof ID を分け、署名対象、鍵、アルゴリズム、鮮度入力と結果を結ぶ必要がある。

キャッシュが作る時間差

毎回 AS に照会すれば遅延と可用性依存が増える。RS は検証結果をキャッシュできるが、RFC 9767 は交換条件を明記する。処理量は減る一方、情報の生存性と正確さが落ち、失効済みトークンが古い肯定によって受け入れられる窓が生じる。

TTL は RS の方針決定である。AS が一度 true を返した事実は、十分後の要求まで認めたことを意味しない。公開読み取りと不可逆な送金に同じ既定値を適用するなら、その既定値が事実上の権限者になる。

キャッシュ・キーには token だけでなく RS、proof 方式、必要アクセスを含む文脈が要る。token だけのキーは狭い回答を別の質問へ拡張する。false は不確定も含むため、長い負キャッシュも回復を隠し得る。

RFC 7009 の失効要求は AS 側の状態変更であり、全 RS のキャッシュ無効化を証明しない。RFC 9767 は能動的シグナルを想定し得ると述べるだけで範囲外に置く。運用上は無効化イベント、対象エントリ、その後に変わった判断までを確認する。

最小開示と利用履歴

イントロスペクションは RS ごとに情報を絞れる。医療 API に必要な患者番号を、同じトークンを受け取る非医療 API に見せない設計が可能だ。しかしライブ照会は、特定トークンが特定 RS で使われた時刻を AS に知らせる。

構造化トークンならローカル検証でき、AS のリアルタイム観測を減らせる。その代わり claim が広く配られ、失効反映が遅れる可能性がある。不透明トークンは AS に知識を集め、オンライン依存を強める。鮮度と開示を同じ表で比較すべきだ。

鍵素材にも差がある。非対称方式の公開鍵を RS が得ても私有署名は作れない。対称鍵を共有すれば、RS 自身が新しい提示を作れる。単に「sender constrained」と呼ぶだけでは、再利用可能性を説明できない。

資源集合の参照識別子は不透明であるべきだ。内部形式を読み始めると情報漏えいと実装ロックインが起きる。乱数または暗号化された値は、その識別子を AS の保存意味への参照にとどめ、単独の権利証へ変質させない。

下流では新しい証跡が始まる

RS1 が RS2 を呼ぶとき、クライアントの bearer token をそのまま回すのは危険だ。RFC 9767 では、RS1 が自分の鍵でクライアントとして新しい grant 要求を署名し、existing_access_token を文脈として示せる。

AS は元トークンが RS1 に適切だったか確かめ、RS2 向けに権利を狭め、RS1 の鍵へ結び付けた派生トークンを出せる。さらに下流でも同じ形を繰り返せる。

ただし派生は効果を継承しない。RS2 のトークンは、RS1 が元要求を正しく解釈したこと、RS2 が処理したこと、結果が元クライアントへ届いたことを示さない。OAuth Token Exchange と同様、新しい actor、subject、audience、scope の帳簿が必要になる。

四つの受領記録

一つ目はイントロスペクションの質問と答え。二つ目は現在メッセージの proof。三つ目は RS のローカル方針と選択。四つ目は commit、下流確認、配信または補償という効果である。

テストでは、正しい token を誤った RS へ送る、範囲外アクセスを要求する、未知の要素を混ぜる、proof を別メッセージに再利用する、失効後も古い肯定を使う、空の権利を受ける、commit 後に応答を失う、入ってきた bearer を RS2 で再利用するといった境界を壊す。

堅牢性とは常に true が返ることではない。各役割が自分の証拠だけで判断し、次の受領記録を捏造しないことだ。

情報源