VCのStatus Listとは何か：失効確認を実装するための設計ポイント

この記事の対象読者

この記事は、Verifiable Credentials（VC）を発行・検証するシステムで、失効確認や一時停止確認をどう設計するかを整理したい人に向けた解説です。

特に、次のような方を想定しています。

• VCを発行するIssuer基盤を設計している方
• Verifier側で提示されたVCの有効性を判定したい方
• 卒業証明、資格証明、在籍証明、本人確認済み属性などのVC活用を検討している方
• Status Listを使う理由と実装時の設計論点を整理したい方
• 失効確認のプライバシー、鮮度、運用負荷を設計論として理解したい方

VCでは署名検証だけで「今も使える証明か」までは判断できません。発行後に資格が取り消される、在籍状態が変わる、鍵漏えいで再発行が必要になる、といったケースがあるためです。

この記事では、VCのStatus Listを、失効リストという狭い見方に閉じず、デジタル証明のライフサイクルを成立させるための確認ポイントとして整理します。

VCでStatus Listが必要になる理由

VCの検証では、主に次の観点を確認します。

• VCやVPの署名・改ざん検知に問題がないか
• Holderが正しく提示しているか
• 有効期限内か
• 信頼できるIssuerが発行しているか
• 失効・停止・更新などの状態に問題がないか

署名が正しいVCでも、発行後の状態が変わっていることがあります。

たとえば、企業の在籍証明VCは、退職後もウォレット内に残る可能性があります。資格証明VCでは、資格停止や取り消しが起こることがあります。卒業証明VCのように背後の事実は変わりにくい証明でも、署名鍵の漏えい、発行ミス、スキーマ変更、再発行などによって、特定のVC自体を無効にしたい場面があります。

ここで重要なのは、Status Listが扱う状態は「現実世界の事実そのもの」と常に同じとは限らない点です。W3C Bitstring Status Listの仕様でも、ステータス情報はVC自体に関する情報であり、背後にある学位や資格そのものの状態とは分けて考える例が示されています。

credentialStatusとVCの関連性

W3C Verifiable Credentials Data Model v2.0では、VCの中にcredentialStatusを入れ、Verifierが参照すべきステータス情報を示せます。DID/VC全体の前提は、先に公開したDID/VC入門記事でも整理しています。

credentialStatusは、VCの中に状態そのものを直接書き込むフィールドというより、Verifierが「どのステータスリストの、どの位置を見ればよいか」を知るための参照情報です。

VC本体は発行時点の証明を持ち、credentialStatusは提示時点の状態確認先を示します。

たとえばW3C VC Data Model系のStatus Listを使う場合、VC側には次のような情報が入ります。

{
  "credentialStatus": {
    "id": "https://example.com/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/status/3"
  }
}

Verifierは、VC内のstatusListCredentialを参照し、ステータスリストを取得します。そしてstatusListIndexで指定された位置の値を確認します。

この構造によって、VCごとに個別の失効確認APIを呼ぶ設計を避けやすくなります。多くのVCの状態を1つのリストにまとめ、Verifierはそのリストの中の該当インデックスを見る形になります。

Status Listには2つの系統がある

Status Listには、大きく分けるとW3C VC Data Model系で使うStatus List Credentialと、JWT/SD-JWT VC/CWTなどのトークン系で使うStatus List Tokenがあります。

W3C Verifiable Credentials Data Model v2.0では、VC内のcredentialStatusからStatus List Credentialを参照します。その具体的な方式として、W3C Bitstring Status List v1.0があります。

SD-JWT VCやJWT/CWT系では、IETF OAuth Working GroupのToken Status Listが関係します。SD-JWT VCでは、status claimを使う場合、status_listメカニズムに紐づくStatus List TokenはJWT形式である必要があります。

この記事では、両者に共通する「失効確認をどう設計するか」に絞ります。細かなデータ構造やJWT/CWTでの表現差分は、採用するVC形式を決めた後に確認する論点です。

VCは発行・保管・提示・検証だけで終わらず、失効確認や再発行まで含めて設計します。

なぜステータスリストを利用するのか

失効確認だけを見ると、VerifierがIssuerのAPIに「このVCは有効ですか」と問い合わせる設計も考えられます。

ただし、VCの文脈ではこの設計に注意が必要です。

Verifierが毎回Issuerへ問い合わせると、Issuerは「どのHolderが、いつ、どのVerifierにVCを提示したか」を推測できる可能性があります。年齢確認、資格確認、所属確認などでは、提示先そのものがセンシティブな情報になることがあります。

Status Listは、多数のVCやトークンの状態をまとめて公開することで、個別照会による相関リスクを下げます。Verifierは公開されたリストを取得し、その中で対象の状態を確認するため、Issuerに対して特定VCの提示イベントを直接伝えずに済みます。

個別API照会は提示イベントをIssuerに伝えやすく、Status Listは公開リストを読む形に寄せることで相関リスクを下げます。

一方で、採用するVC形式によって見るべき仕様は変わります。

• W3C VC Data Model / JSON-LD系: credentialStatusとBitstring Status Listを中心に見る
• SD-JWT VC / JWT系: status claimとToken Status Listを中心に見る
• ISO mdoc / COSE系: COSE/CWT表現を含むToken Status Listの扱いを確認する

ただし、Verifier側の確認フローを抽象化すると大きくは同じです。証明本体を検証し、ステータス参照を読み、リストを取得し、リスト自体を検証し、指定インデックスの状態を解釈します。違いは、VC内で参照するフィールド名、取得するリストの形式、リスト自体の署名・発行者・有効期限をどう検証するかにあります。

実装では「Status List」という言葉だけで判断せず、自社が採用するVC形式、署名方式、ウォレット、Verifierプロファイルに合わせて仕様を選ぶ必要があります。

Verifierが確認する流れ

Status Listを使う検証は、おおまかに次の流れになります。OpenID4VCIやOpenID4VPのような発行・提示プロトコルを使う場合でも、最終的にVerifier側ではVC本体とステータス情報を確認します。

VerifierはVC本体の署名やIssuerを確認したうえで、Status List自体も検証し、指定インデックスの状態を読んで受け入れ可否を決めます。

1. VCまたはトークン本体を検証する
2. ステータス参照からURLとインデックスを取得する
3. Status List CredentialまたはStatus List Tokenを取得する
4. リスト自体の署名、発行者、有効期限、キャッシュ期限を検証する
5. 指定インデックスの状態を読み、受け入れ可否を判断する

ここで落とし穴になりやすいのは、ステータスリスト自体も検証対象であることです。

リストを取得できたとしても、そのリストが信頼できるIssuerまたはStatus Issuerによって発行されているか、有効期限内か、改ざん検知に通るかを確認する必要があります。古いリストをキャッシュし続けると、失効済みVCを受け入れるリスクが残ります。

VerifierはVC本体だけでなく、参照先のリスト、リストの発行者、キャッシュ鮮度まで確認します。

Issuerが設計すること

Issuer側では、少なくとも次の項目を決める必要があります。

1. どの状態を公開するか

失効だけを扱うのか、一時停止や更新通知も扱うのかを決めます。

資格証明では、取り消しと停止を分けたい場面があります。在籍証明では、退職を失効として扱うのか、証明の有効期限切れとして扱うのかを整理する必要があります。本人確認済み属性では、本人確認の再実施や属性変更をどう扱うかが論点になります。

2. どの粒度でリストを分けるか

すべてのVCを1つのリストに入れる設計も、証明種別や発行時期ごとに分ける設計もあります。

リストを細かく分けすぎると、グループプライバシーが弱くなりやすくなります。一方で、巨大なリストを少数の運用単位で扱うと、更新・配信・障害影響の範囲が大きくなります。

証明種別、発行量、更新頻度、Verifierのキャッシュ設計、CDN配信を合わせて決めるのが現実的です。

3. インデックスをどう割り当てるか

Status Listでは、VCやトークンごとに「リスト内のどこを見るか」を示す情報を持たせます。実装方式によってフィールド名や表現は変わりますが、発行時期や発行規模を推測されにくくする観点は共通して重要です。

連番で割り当てると、Verifierが複数のVCを観察したときに発行順や発行量を推測できる可能性があります。実装では、未使用インデックスの管理、再利用方針、衝突防止を含めて設計します。

4. どの鮮度で反映するか

Status Listはキャッシュしやすい仕組みです。だからこそ、どれくらいの鮮度を要求するかが重要になります。

金融、資格、入退場、雇用など、失効反映の遅れが大きなリスクになる領域では、短いTTLや頻繁な更新が必要です。卒業証明のように状態変化が少ない証明では、長めのキャッシュでも問題が小さい場合があります。

常に最新を求めると可用性と負荷の問題が出ます。鮮度、可用性、コスト、リスクのバランスを業務要件として決める必要があります。

Verifierが設計すること

Verifier側では、Status Listを読むだけでなく、受け入れポリシーを決める必要があります。

• ステータスリストに到達できないときに拒否するか、保留するか
• キャッシュ済みリストを何分まで許容するか
• revocationとsuspensionを同じ拒否として扱うか
• IssuerとStatus Issuerが異なる場合に、どの信頼関係を確認するか
• messageや独自ステータス、監査ログをどう扱うか

特に、通信障害時の扱いは事前に決めるべきです。

Status Listを取得できないたびに全拒否すると、可用性が下がります。一方で、取得できないから受け入れる設計にすると、失効済みVCを通すリスクが残ります。本人確認、資格確認、決済、入退場など、ユースケースごとにリスク許容度を決めます。

よくある設計ミス

失効確認を署名検証の後回しにする

PoCでは署名検証までで満足しがちです。本番では、有効期限、Issuer Trust、Status List、Holder Bindingまで含めて検証設計を作る必要があります。

VCごとの個別API照会に寄せすぎる

個別照会は実装しやすい反面、Issuerが提示イベントを観測しやすくなります。プライバシー要件がある証明では、Status Listやキャッシュ戦略を先に検討します。

失効と一時停止を混ぜる

取り消し、停止、更新通知、注意メッセージは運用上の意味が異なります。statusPurposeや独自メッセージを使う場合は、Verifier側の判定ルールまでセットで定義します。

キャッシュ設計を決めていない

Status Listは配信しやすい仕組みですが、古いリストを使い続けると失効反映が遅れます。TTL、取得失敗時の扱い、再試行、監査ログを決めます。

Status Issuerの信頼を確認していない

Token Status Listでは、Referenced TokenのIssuer、Status Issuer、Status Providerが分かれる場合があります。役割が分かれる構成では、誰が誰にステータス発行を委任しているのかを確認できるようにします。

実装前に決めるチェックリスト

Status Listを実装する前に、次の問いを整理すると設計が進めやすくなります。

1. VC形式、署名方式、Status List仕様をどの組み合わせにするか
2. 失効、停止、更新通知など、どの状態を扱うか
3. Status Listの発行主体とIssuerとの信頼関係をどう表すか
4. リストの分割粒度、インデックス割り当て、キャッシュ方針をどう決めるか
5. 取得失敗時、監査ログ、状態理由の表示をどう扱うか

このチェックリストを決めずに実装すると、仕様上は動いていても、実運用で受け入れ可否の判断がぶれます。

まとめ

VCのStatus Listは、発行済み証明の状態をVerifierが確認するための仕組みです。

署名検証は「発行時点の証明が改ざんされていないか」を確認します。Status Listは「提示時点でそのVCを受け入れてよいか」を判断するために使います。

W3C VC Data Model系ではStatus List Credential、SD-JWT VCやJWT/CWT系ではStatus List Tokenとの関係を確認する必要があります。

実装で大事なのは、仕様名の選定に加えて、どの状態を、誰が、どの鮮度で、どの信頼関係のもとで公開し、Verifierがどう判定するかを決めることです。

DID/VCを社会実装するなら、Status ListはIssuer、Wallet、Verifier、監査、運用をつなぐ中核設計として扱うべきです。

参考資料

• W3C, Verifiable Credentials Data Model v2.0: https://www.w3.org/TR/vc-data-model-2.0/
• W3C, Bitstring Status List v1.0: https://www.w3.org/TR/vc-bitstring-status-list/
• IETF OAuth Working Group, Token Status List: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
• IETF OAuth Working Group, SD-JWT-based Verifiable Digital Credentials: https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
• OpenID Foundation, OpenID for Verifiable Credential Issuance 1.0: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html