VCの失効をすぐ効かせるには｜ステータスリストの選び方と確認できないときの扱い

ある会社が、社員の資格や所属を証明するVC（Verifiable Credentials）を発行しています。社員はスマホのウォレットにそれを入れ、取引先の入館受付や業務システムで見せます。ある日、1人の社員が退職しました。人事の担当者は、すぐにその証明を失効させます。

ところが取引先の受付では、その証明がしばらく「有効」と表示され続けました。受付の端末は、状態の一覧表を手元に取っておいて使い回していたからです。一覧表の配信が止まった日には、確認できないまま通してしまう設定になっていました。

発行する側が失効させても、確かめる側がそれを知るまでには時間差があります。その間に使われたらどうするのか。本番で失効を確実に効かせるには、方式を選ぶ前に2つのことを決めます。

• 状態が確認できないときに、「有効」とみなさないこと
• 失効が何分以内に届けば許せるか

以下では、発行する会社の側と、確かめる受付の側を行き来しながら、失効の仕組みを本番で動かす手順を追います。VC全体の信頼の仕組みとデータの置き場所は「DID・VCの導入設計」、VCの基礎は「Verifiable Credentialsとは」で解説しています。

まず、4つの状態ごとに「通す・止める・人が確認する」を決める

さきほどの退職者の証明も、署名そのものは正しいままでした。署名が正しくても、その後に失効や一時停止をしていれば、受け入れてはいけません。そこで受付の側では、少なくとも次のことを別々に確かめます。

• 署名が正しいか（暗号の検証）
• 証明書（credential）の有効期間内か
• ステータスリストの署名が正しく、情報が新しいか

そのうえで、業務上の判定方針に照らします。特に大事なのは、「状態を確認できない」と「有効である」を同じ結果にしないことです。

状態は4つに分け、それぞれで扱いを変えます。

どうすれば元に戻せるかは状態ごとに違います。

• 一時停止：解除する権限を持つ人が、新しく状態を更新する
• 失効：元には戻さない。必要なら新しい証明書を再発行する
• 状態不明：許容鮮度内の正しいリストを取れたとき、または別の方法で確かめたとき

W3C Bitstring Status List v1.0は、失効（revocation）を取り消し不能、一時停止（suspension）を取り消し可能な目的として定義しています。

発行する会社の側では、「退職」「不正利用の疑い」など詳しい理由を社内に持てます。ただし、公開するリストから個人や理由を推測できる作りにはしません。公開するのは、受付が必要とする最小限の状態だけです。

ステータスリストは、どうやって状態を届けるのか

ステータスリストは、多数の証明書の状態を1つのファイルにまとめて配る仕組みです。

証明書には、「状態の一覧表のどこを見ればよいか」という住所が書いてあります。発行者は多数の証明書の状態を1列の0と1（ビット列）にまとめ、圧縮します。そして、そのリスト自体をVCとして署名します。

受付の側は、リストの発行者、署名、有効期間、目的を確かめます。そのうえで、自分が確かめたい証明書の位置の値を読みます。

W3C仕様のビット列は最低16KBです。1ビットの状態なら131,072件分にあたります。

大きなリストに多くの人を混ぜるほど、受付が誰の状態を確かめたのかが分かりにくくなります。証明書ごとに発行者へ問い合わせる方式より、提示の記録を結びつけにくいのです。CDNや手元の保存（キャッシュ）も使えます。

逆に、所属や属性ごとにリストを細かく分けると、1つのリストに入る人が少なくなります。するとリストのURLだけで、所属や属性を推測されます。リストをどこまで分けるかは、更新の手間だけでなく、何人の中に紛れられるか（匿名集合の大きさ）でも考えます。

失効が何分で届けば許せるかを決める

さきほどの退職者の例で、人事が失効させてから受付の判定が変わるまでには、次の4つの区間があります。

1. 社内の手続きが確定するまで：申請を受けてから、承認が確定するまで
2. リストを作るまで：確定してから、署名したリストのスナップショット（ある時点の写し）ができるまで
3. 配り終えるまで：公開してから、CDNの各拠点に行き渡るまで
4. 受付が使うまで：手元のリストが発行されてから、それで判定するまで

「5分ごとに更新する」という実装の値は、このうち一部の区間の話にすぎません。それだけでは、失効がいつ届くかを保証できないのです。そこで4つを足し合わせ、判定の時点で許せる状態情報の古さの上限を決めます。これが最大許容鮮度です。各区間で起きやすい失敗と対策は、後半の「実装する人向けの詳細」にまとめています。

状態が確認できないとき、どう判定するか

状態の配信先が止まったとき、常に「通す（fail-open）」にすれば、失効した証明も通ってしまいます。常に「止める（fail-closed）」にすれば、正しい証明まで拒まれ、業務が止まります。どちらか1つにそろえると、どちらかを失うのです。だから、許せる損失と、代わりに使える手段で、証明書の種類ごとに方針を変えます。

• 高リスクな権限を与えるとき：許容鮮度を超えたら拒否するか、人手の審査へ回します。古いキャッシュだけで新しい権限は与えません。
• 低リスクな利用を続けるとき：短時間だけ、直近の正しいスナップショットを使います。利用範囲を狭め、後で確かめ直します。
• オフラインで提示するとき：ウォレットが署名済みのリストを一緒に渡す方式（stapling）もあります。その場合も、受付が求める鮮度を満たすかを確かめます。
• 個別の照会に切り替えるとき：提示先が発行者に知られるというプライバシー上の違いと、監査の条件をはっきりさせます。

復旧したら、最新のリストを取れたことだけでは足りません。障害中に受け入れた証明書を確かめ直し、結果が変わった取引や権限を追えるようにしておきます。

どの方式を選ぶか

方式は、プライバシー、情報の新しさ、オフラインで使えるかで選びます。方式ごとの向き不向きは次のとおりです。

多数のVCを扱い、提示を追われたくないなら、まとめたステータスリストが向きます。採用する前に確かめることは、方式ごとに違います。後半の「方式ごとに採用前に確かめること」にまとめました。

IETFでも、Token Status Listという別系統の仕様が策定中です。JWTやCWTといったトークンの状態を、圧縮したリストで配ります。W3Cの方式と目的は近いものの、仕様はまだ策定の途中です。2つを混ぜて使わないようにします。

ブロックチェーンに個別の状態を載せる必要はあるか

個人ごとの失効の理由は個人情報なので、訂正やアクセス制御が要ります。まとめたリストは、速く配れることが大事です。どちらもブロックチェーンより、社内のDBやWebの方が向いています。情報ごとの置き場所は次のとおりです。

次のような情報をブロックチェーンに置くと、消しにくい形で人と行動が結びつきます。

• 個別の証明書ID
• リスト上の位置と人物の対応
• 受付が照会した履歴

ブロックチェーンに載せても、失効がすぐ届くようにはなりません。受付がノードにつなぎ、確定を待ち、最新のブロックを見るまでに時間がかかります。障害時の判定方針も別に要ります。発行者が1社で受付も決まっているなら、署名したファイルをCDNで配る方が運用しやすいことが多いでしょう。

誰が止め、誰が解除できるかを分ける

ステータスリストに署名する組織は、元のVCの発行者と同じでなくてもかまいません。W3C仕様も、両者が異なる構成を認めています。

そのため受付の側では、VCの発行者だけを確かめても足りません。ステータスリストの発行者に、その証明書の状態を変える権限があるか。これを、誰を信頼するかの方針で確かめます。信頼する相手の管理は「VCの信頼レジストリ設計」で詳しく扱います。

発行する会社の側では、権限を次のように分けます。

• 申請する人、承認する人、リストに署名するサービス、配信の管理者を分ける。
• 一時停止の解除と、取り消せない失効を別の権限にする。失効済みの証明書をビットの操作で復活させない。
• 一括更新、鍵の更新、発行者の撤退には、2人の承認と、元に戻す演習を求める。
• リストの署名鍵をVCの発行鍵と別にする。鍵が漏れたときの影響と更新の手順を狭くできる。

発行者が事業をやめた後も、有効期間の残る証明書を受け入れることがあります。その場合は、次のことを契約と運用手順に入れておきます。

• 署名済みリストのミラーと、最後のスナップショットを保管する組織
• 鍵の失効
• 問い合わせ窓口

引き継ぐ組織が決まらないと、有効期間の残る証明書を、誰も確かめ続けられなくなります。その場合は長く使う証明書を避け、有効期間を短くして再発行する方が単純です。

本番の前に、失効から業務の結果までを通して試す

1. 一時停止、解除、失効を実行し、権限・監査イベント・取り消し不能性が判定方針どおりか確認する。
2. 各イベントからすべての検証者の判定が変わるまでを計測し、最大許容鮮度以内であることを確認する。
3. 配信先の停止、DNS障害、CDNの古いキャッシュ、署名不正、期限切れ、未対応の目的（statusPurpose）を起こしてみる。
4. 新しいスナップショットを受け入れた後に古い正しいスナップショットを返し、巻き戻しとして拒否できるか試す。
5. 発行者の配信ログから個別の所持者や提示先を推定できないこと、検証者のログに証明書の全文が残らないことを確認する。
6. 鍵の更新、一括の誤更新、発行者の撤退を演習し、ミラーと責任の移管によって検証を続けられるか確認する。

合格の条件は、HTTP 200が返ることではありません。対象の証明書が意図した時間内に拒否され、状態不明が誤って有効扱いされず、復旧後に影響範囲を追えることです。ウォレットをなくしたときの停止と再発行の運用は「企業向け証明書ウォレットの運用設計」を参照してください。

実装する人向けの詳細

ここからは、発行する会社と受付の側で、実際に仕組みを組む担当者向けの話です。

証明書に書く参照情報

VCのcredentialStatusには、次の3つを入れます。

• 参照するステータスリスト用証明書のURL
• statusPurpose（失効・一時停止など、状態の目的）
• statusListIndex（リスト上の位置）

発行者はビット列をGZIPで圧縮し、ステータスリスト自体をVCとして署名します。検証者はリストの発行者、署名、有効期間、目的を検証し、対象の位置（index）の値を読みます。

鮮度の区間ごとの失敗と対策

冪等キーは、同じ要求を何度送っても1回分しか処理されないようにする識別子です。

ttlとvalidUntilを別々に検査する

W3C仕様のttlは、再取得を試みるまでの時間をミリ秒で表します。HTTPのCache-Controlと合わせることが推奨されています。

ただしttlは、ステータスリストのvalidUntilの代わりにはなりません。検証者は次の2つを別々に検査します。

• キャッシュを取り直す時刻（ttl）
• リストを暗号的・業務的に受け入れてよい期限（validUntil）

古い正しいリストへの巻き戻しを見つける

攻撃者や設定の誤りで、署名は正しいが失効前のスナップショットが返ることがあります。署名の検証だけでは、この巻き戻し（rollback）を防げません。

発行者は、単調に増える世代番号か発行時刻を持つ、完全なスナップショットを公開します。検証者は、発行者・リストIDごとに、最後に受け入れた世代を記録します。新しい世代を受け入れたら、古い世代へは戻しません。例外は、判定方針で認めた過去時点の検証だけです。

リストを更新する順番

「ビットを変えてから署名」する作りにはしません。次の順で進めます。

1. 業務イベントを永続化する
2. そのイベント列から、新しい完全なスナップショットを作る
3. 署名し、版付きのオブジェクトとして公開する
4. 最後に「最新版」への参照を切り替える

途中で失敗したスナップショットは配信しません。同じイベントIDで再実行しても、二重に反映しないようにします。

検証ログに残す項目

検証ログには証明書の全文を残しません。代わりに次の項目を保存します。

• 要求ID、発行者、証明書の種類
• リストID、スナップショットの世代、取得時刻
• 判定結果、判定方針の版

方式ごとに採用前に確かめること

• 集約したBitstring Status List：匿名集合、最大許容鮮度、ミラー
• 個別のオンライン照会：認証、流量制限、監査、プライバシー上の合意
• 短寿命の証明書：発行負荷、オフライン期間、猶予期間
• オンチェーンのレジストリ：個人ごとのデータを置かない、アップグレードと緊急停止

IETF Token Status Listの位置づけ

IETFのToken Status Listは、まだRFCとして発行されていません。IESGの承認を経て、RFC編集待ちのInternet-Draft（第21版）です。W3C Bitstring Status Listとは、項目名、符号化、検証手順を混在させません。採用する証明書の形式と、相互運用先が求める仕様を先に確認します。

XTELAができること

私たちは、ID・信頼基盤の要件整理から、ステータスリストを含むデータの流れと権限の設計、配信停止や巻き戻しを注入する障害試験、PoCの実装までを行っています。貴社の証明書の種類ごとに許容鮮度と状態不明時の扱いを決め、失効操作から業務結果までを通して確かめられる形にします。証明書の法的効力や保存義務に関わる判断は、弁護士と連携して進めます。技術構成の整理が必要な場合はお問い合わせください。

参考資料

• W3C Bitstring Status List v1.0
• W3C Verifiable Credentials Data Model v2.0
• IETF Token Status List（Internet-Draft）
• OpenID for Verifiable Credential Issuance 1.0 Final

資料の確認日

仕様の状態（Token Status Listの策定段階を含む）は、2026年9月24日に確認した一次仕様に基づいています。