この仕様の解説はまだ書かれていない。下の要約・関係・対応状況は維持されている。
発行者が公開する圧縮ビット列で、検証者はトークンやクレデンシャルが失効・停止されていないかを確認できる。
Token Status List
発行者が公開する圧縮ビット列で、検証者はトークンやクレデンシャルが失効・停止されていないかを確認できる。
- 現在地
- 承認済み、RFC Editor 待ち
- 公式に文書化された対応
- 0
他の仕様との関係
関係図
flowchart LR s_status_list["Token Status List"] s_jwt["JSON Web Token"] s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"] style s_status_list stroke-width:3px s_status_list -->|土台とする仕様| s_jwt s_sd_jwt_vc -->|土台とする仕様| s_status_list
公式に文書化された対応
利用状況には、公式のドキュメント（ベンダーやプロジェクト自身のもの、または標準化団体がその名前を挙げているページ）に対応が明記されているものだけを載せている。引用した文言がそのページにまだあるかは毎週確認している。実験的・アルファ・ベータの対応は「プレビュー」として別に数える。
出典付きの対応情報はまだ集めていない。普及していないという意味ではない。
動き
Datatracker の revision 履歴、このサイトの日次 run が書いた解説、draft 名を挙げた ML の件名。
このサイトの解説
Mikhailは、過去のアクターが停止されたことを理由に呼び出しを拒否できないとする記述の修正を、エビデンス束縛ドラフトの著者に求めた。
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
解説を読む
KieranはRFC 8693 Section 4.1により、入れ子のactクレーム内の過去のアクターはアクセス制御の判断に使えないという読みを認め、著者は-02でこれを取り入れるとしている。Mikhailは、SCITT -02の本文が依然として、過去のアクターが停止されたことを理由にServing Partyが呼び出しを拒否できないと記している点を指摘した。別途検証された委任トークンは別の根拠となる。draft-asor-wimse-agent-delegation-chain-03形式のチェーンはホップごとに検証され、ステップ7では、受け入れたステータス応答がいずれかのトークンを失効としていれば、ステータスリストの鮮度の範囲内で拒否される。そこで、拒否できないのは入れ子のactクレームに基づく場合に限るという文言と、履歴が完全でも証拠でもないという表現の修正を提案している。
flowchart LR A[Token with nested act claims] --> B[Serving party reads top-level claims and current actor only] C[Delegation chain tokens] --> D[Verify each hop] D --> E[Check status list answer] E -->|any token revoked| F[Deny]
- 上流のアクターが後から停止される、複数ホップのエージェント呼び出しの監査やServing Partyのポリシーを設計する場合。
- ホップごとの権限を、act クレーム(帰属のみ)から確認するか、ステータス参照を持つ別途検証された委任トークンから確認するかを選ぶ場合。
- 関連: OAuth WG:
draft-ietf-oauth-status-list. 委任チェーンドラフトのステータス参照と鮮度は、ステータスリストの応答に対して確認される。
Kathleen Moriarty による workload-creds のレビューは文言の明確化と数点のセキュリティ面の提案を含み、Yaron が issue #418 として登録した。
Review of draft-ietf-wimse-workload-creds
解説を読む
レビューは、アブストラクトを、クレデンシャルがアイデンティティを表すのではなく紐づくものだと言い換えることを提案する。序文では、WIT は HTTP などのアプリケーション層向け、WIC は主に mTLS のトランスポート層向けだと直接述べることも提案する。5 節ではロードバランサでの TLS 終端がアプリケーション層クレデンシャルを使う理由になると説明することを勧める。5.1 節では exp の「数時間」という目安をより短くすべきか、また deny-list ではなく allow-list としない理由を尋ねる。9.6 節では、サーバー認証のみの TLS に加えて mTLS も許容することを提案する。メッセージは途中で切れており、以降のコメントは確認できない。Yaron は s2s-protocol の issue #418 として登録した。これらは提案であり、採用された変更ではない。
- TLS を終端するロードバランサがある環境で WIT と WIC のどちらを使うか選ぶ場面。
- WIT の有効期間や、deny-list と allow-list のどちらでステータスを管理するかを決める場面。
- 関連: OAuth WG:
draft-ietf-oauth-status-list. レビューは WIT のトークンステータスにおける deny-list と allow-list を問題にしており、Token Status List が扱う領域に近い。ただし資料は両ドラフトを結びつけていない。