WIMSE Workload Credentials

ワークロード識別子に鍵を結び付ける Workload Identity Token（JWT）と Workload Identity Certificate（X.509）を定める。

現在地: WG ドラフト
公式本文: draft-ietf-wimse-workload-creds-03; 2026-10-30
公式に文書化された対応: 2
動き: 4 件の動き (90 日)

この仕様の解説はまだ書かれていない。下の要約・関係・対応状況は維持されている。

ワークロード識別子に鍵を結び付ける Workload Identity Token（JWT）と Workload Identity Certificate（X.509）を定める。

他の仕様との関係

関係図

flowchart LR
  s_wimse_creds["WIMSE Workload Credentials"]
  s_wimse_arch["WIMSE Architecture"]
  s_jwt["JSON Web Token"]
  s_wpt["WIMSE Workload Proof Token"]
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  s_wimse_mtls["WIMSE Mutual TLS"]
  style s_wimse_creds stroke-width:3px
  s_wimse_creds -->|土台とする仕様| s_wimse_arch
  s_wimse_creds -->|土台とする仕様| s_jwt
  s_wpt -->|土台とする仕様| s_wimse_creds
  s_wimse_httpsig -->|土台とする仕様| s_wimse_creds
  s_wimse_mtls -->|土台とする仕様| s_wimse_creds

公式に文書化された対応

利用状況には、公式のドキュメント（ベンダーやプロジェクト自身のもの、または標準化団体がその名前を挙げているページ）に対応が明記されているものだけを載せている。引用した文言がそのページにまだあるかは毎週確認している。実験的・アルファ・ベータの対応は「プレビュー」として別に数える。

製品・IdP・サービス

SPIFFE (仕様): WIT-SVID 仕様が、すべての WIT-SVID を WIMSE の Workload Identity Token と定めている出典 (確認 2026-11-11)
Solo.io (Istio 1.30.x ambient) (製品)アルファ: Solo の Istio ambient ディストリビューションが、WIMSE の Workload Identity Token にアルファ機能として対応出典 (確認 2026-11-11)

動き

Datatracker の revision 履歴、このサイトの日次 run が書いた解説、draft 名を挙げた ML の件名。

このサイトの解説

議論IETF WIMSE
workload-creds に対し、可読性向上の編集提案と、exp の有効期間・deny-list 表現・9.6節の mTLS についての指摘があった。
Review of draft-ietf-wimse-workload-creds
解説を読む
レビュアーは、抽象で、クレデンシャルがワークロードのアイデンティティを「表す」ではなく「に紐づく」と書き換えることを提案している。WIT（HTTP などのアプリケーション層）と WIC（mTLS などのトランスポート層）の使い分けを、根拠付きの2つの推奨パターンとして書き直すことも提案している。5章には、ロードバランサーで TLS が終端する場合にアプリケーション層のクレデンシャルが改変されずに維持される必要があることの説明を加えるよう提案している。5.1節については、一部で既に5分程度の有効期間が使われていることから exp の「数時間」という目安を短くすべきか、また jti の説明がなぜ allow-list ではなく deny-list なのかを質問している。9.2節には、exp を短くすることがその問題の緩和策であると明記するよう提案している。規範的な修正は9.6節のみで、WIT と PoP を送る「サーバー認証 TLS」接続の要件に mTLS も明記するというものである。WG からの応答はこの資料には含まれていない。
- WIT の有効期間を決める実装者は、WG が exp の「数時間程度」という目安を短くするかどうかに注目するとよい。
- サービス間で mTLS 経由で WIT を送る運用者にとっては、9.6節が mTLS をチャネル要件の充足として明記すれば有益である。
議論IETF WIMSE
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 が扱う領域に近い。ただし資料は両ドラフトを結びつけていない。

メーリングリスト

[WIMSE] Re: Review of draft-ietf-wimse-workload-creds 11月6日 · IETF WIMSE
[WIMSE] Review of draft-ietf-wimse-workload-creds 11月6日 · IETF WIMSE