要約

  • PrivateToken チャレンジは、トークン種別、発行者、償還コンテキスト、Origin 集合、鍵を指定し、応答トークンはその問い全体のダイジェストに結び付く。
  • 開かれたサービスでは、対応可能なクライアントも無視できる。無応答は、未対応・失敗・選択を区別しないよう意図的に設計されている。
  • チャレンジ、検証、在庫、応答選択、発行、暗号検証、再利用判定、認可、副作用、配信は別々の受領証で管理すべきである。

「対応なし」という一行は観測ではなかった

ログには、チャレンジ送信と次の通常リクエストだけが残った。運用者はその間を unsupported で埋めた。しかし RFC 9577 では、その空白を一つの原因で埋めることができない。

未知の token_type、壊れた構造、挑戦した Origin を含まない origin_info は、クライアントに処理中止を要求する。適合するキャッシュがない、発行者へ到達できない、ローカル方針が拒む、再試行前に利用者が離れる場合もある。さらに、すべてが正常でも応答しない枝がある。

トークンなしでも利用でき、トークンによって CAPTCHA の頻度だけを下げるようなサービスでは、対応クライアントが非微小な確率でチャレンジを無視できる。Origin から見れば、未対応または生成不能なクライアントと同じに見える。その曖昧さが、任意機能の強制化を防ぐ。

wire 上の座標は命令ではない

既定の TokenChallenge は四つの座標を持つ。token_type が発行方式を、issuer_name が許可された発行者を、redemption_context が償還の範囲を、origin_info が受け入れ可能な Origin の集合を示す。HTTP ヘッダーには token-key もある。

クライアントは発行や償還より前に形式と範囲を検査する。非空の Origin 一覧に挑戦元がなければ先へ進んではならない。標準の条件を通過しても、追加のローカル制約を適用できる。

つまりチャレンジ到着は、Origin が提示した選択肢の証拠にすぎない。クライアントの実装能力、発行者への信頼、在庫、応答意思、業務上の資格までは運ばない。

完全一致は結論を狭くする

応答トークンにはクライアント nonce、チャレンジ全体の SHA-256、鍵識別子、認証子が含まれる。キャッシュしたトークンは、種別、発行者、コンテキスト、Origin 情報がすべて一致するときだけ使える。

この厳密さは、トークンを一般的な信用証明へ拡張する考えと両立しない。Origin 一覧の順序を変えただけでも別の文字列となる。メンバーを増減しても別の問いである。正しい認証子は、その狭い問いへの暗号応答を証明するだけだ。

Cookie を消したり、Origin 固有状態がないままネットワークを変えたりした後、コンテキスト付きトークンを捨てるべき場合がある。古い在庫を使うと、新旧セッションが再び結び付くからだ。在庫を使わない判断は故障ではなく、分離を守る動作である。

問いを細かくすると待ち時間が増える

Origin は複数の種別、発行者、コンテキストを提示できる。並び順はヒントであって拘束ではない。クライアントは選べるし、候補は機能上同等の性質を備えるべきだ。大量の候補は処理を圧迫する。

毎回固有の redemption_context を入れると既存キャッシュは使えず、新たな発行が必要になる。応答率低下をクライアントの能力低下と読む前に、Origin が問いの費用を上げなかったか確認しなければならない。

GREASE は未知値への耐性を継続的に試す。予約済みのランダム種別をときどき混ぜ、任意利用の環境ではチャレンジそのものを出さない機会も作る。予約値を不正と判定する運用は、相手ではなく自分の硬直化を検出している。

再利用の意味は副作用が決める

認証子の検証成功は終点ではない。Origin は nonce の既使用状態を調べる。二重使用防止は重要だが、RFC は再利用を一律に攻撃とはしない。元からリンク可能で、副作用を起こさない処理なら許容できる場合がある。支払い、削除、予約などを伴う場合、特に 0-RTT では危険が変わる。

したがって、暗号的有効性、再利用方針、アプリケーション認可、コミット、提供結果を別々に残す。暗号モジュールは業務効果の価値を知らない。アプリケーションは署名成功だけで nonce の歴史を推測できない。

逆方向も同じである。トークンなしという事実は、拒否や危険判定を自動的に正当化しない。

複数 Origin は状態と権力を共有する

複数 Origin 向けトークンは事前発行を便利にする一方、正確なチャレンジと二重使用状態の共有を要求する。同期が欠ければ同じトークンが別の場所で通る。一つの Origin がクライアントの在庫を使い切り、ほかの Origin の利用可能性を奪うこともある。

クライアントは一定時間内にすでに償還したなら、追加提示を止めて在庫を守れる。この沈黙を低い信用へ変換すると、共有集合の一員が他者のアクセス判断まで支配する。

必要なのは、同期範囲、消費上限、障害時の扱い、責任者、離脱手順の受領証である。同じ Origin 一覧が配布されたという設定だけでは、運用上の合意を証明しない。

登録は利用実績ではない

IANA の登録は名称と番号の衝突を防ぐ。RFC 9576 は役割を分け、RFC 9578 と VOPRF・RSA ブラインド署名仕様は発行を定義する。しかし、特定ブラウザの実装、発行者の可用性、組織的独立、再利用ストアの同期、無応答者への公平な提供は証明しない。

稼働コード優先の考え方では、標準と現場の受領証を混同しない。標準は許される状態遷移を示す。現場は実際の遷移を、必要最小限の記録で示す。拒否を決めた主体は、その判断をプロトコルに転嫁せず、自分の方針として説明する。

出典

出典