要約

  • RFC 9770 の TRL は失効済みで未期限切れのトークン・ハッシュを知らせるが、RS が知る前にアクセスが通る脆弱な時間帯を明記している。
  • 失効の判断、AS の TRL 更新、Observe または照会、受信、保存済みトークンの削除、実際の要求結果は別々に確認すべきである。

「失効」は状態名として便利だが、分散した装置を一斉に変える命令ではない。RFC 9770 は Marco Tiloca、Francesca Palombini、Samuel Echeverria、Grace Lewis の共同作業として 2025 年に公開された。ACE の登録済みデバイスは CoAP を使い、Authorization Server の Token Revocation List を全量照会、差分照会、または Observe で取得できる。TRL が持つのは該当する失効トークンのハッシュであり、利用者の身元、失効理由、後の操作結果ではない。

そもそも仕様は、どの手続でトークンを失効と宣言するか、AS がそれをどう知るかを範囲外に置く。よって TRL の一行から、ポリシー判断の正しさや侵害の原因、組織の意図を読み込むことはできない。そこにあるのは AS の表現が更新されたという限定的な事実である。

Observe は即時性の保証でもない。AS は関連する購読者へ更新通知を送るが、RFC 9770 は外部攻撃者が通知を抑止すれば、要求者が失効を永遠に知らない可能性を指摘する。このため Observe だけに頼らず、可用性や省電力を考えたアプリケーション方針で定期的に完全照会すべきだとする。応答がない、またはエラーなら、要求者は失効・期限切れのどちらについても結論を出してはならない。差分履歴は上限に達すれば古い項目を失い、完全照会は小さな装置の処理能力を越えうる。

受信後には厳密な行為がある。関連ハッシュを含む TRL 応答を受けた登録デバイスは、対応する保存済みトークンを削除しなければならない。RS は削除後もハッシュを残す。この規則は受信側の状態遷移を示すが、過去の通知が全端末に届いた証明にも、将来のすべての要求が拒否される証明にもならない。

RFC が名指す通り、失効後・RS 認知前には、保存済みトークンでアクセスが成功しうる。それは security violation である。だから必要なのは中央画面の失効表示ではなく、端末がいつ知り、何を削除し、どの要求をどう処理したかの連結した記録である。

Heng Lu の最小共通面という見方では、TRL は独立した参加者に限定情報を渡す層である。到達性、再照会、保存状態、実行中のコードによる判定は各地点に残る。

出典