Bitstring Status Listとは何か：W3C VC Data Model系の失効確認を読む

この記事の位置づけ

前回の記事では、VCのStatus Listを「発行済み証明を提示時点で受け入れてよいか確認する仕組み」として整理しました。

この記事では、そのうちW3C VC Data Model系で使われるBitstring Status List v1.0を扱います。

特に次の点に絞って説明します。

• VC内のcredentialStatusが何を指すのか
• Status List Credentialの中に何が入るのか
• statusListIndexとstatusPurposeをどう読むのか
• Verifierがどの順番で検証するのか
• Issuerが実装前に決めるべき設計論点

前回記事のVCのStatus Listとは何かでは、Status List CredentialとStatus List Tokenを並べて概観しました。この記事は、そのW3C側を深掘りする続編です。

DID/VC全体の基本構造を先に確認したい場合は、DID/VC入門記事も合わせて読むと理解しやすくなります。

Bitstring Status Listの基本

Bitstring Status Listは、多数のVCの状態を1つのビット列としてまとめ、Status List Credentialとして公開する方式です。

VCごとに個別の失効確認APIを用意する形にすると、Issuerは「いつ、誰が、どの証明を確認したか」を観測しやすくなります。Status Listでは、多数のVCの状態をまとめて公開し、Verifierはその中の指定位置を読むため、個別照会による相関リスクを下げやすくなります。

W3C仕様では、IssuerはStatus List Credentialをキャッシュしやすく、取得者を追跡しにくい形で公開することが推奨されています。CDNやOblivious HTTPなどを使い、Status Listの取得ログからHolderの提示行動を推測しにくくする設計が重要です。

VC側にはcredentialStatusが入る

Bitstring Status Listを使うVCでは、VC本体にcredentialStatusを入れます。

credentialStatusは、VCの状態そのものを直接持つフィールドというより、Verifierが「どのStatus List Credentialの、どの位置を見ればよいか」を知るための参照情報です。

典型的には次のような構造になります。

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

ここで重要なのは、statusListCredentialとstatusListIndexです。

statusListCredentialは、状態リストを含むVCのURLです。VerifierはこのURLからStatus List Credentialを取得します。statusListIndexは、そのリスト内で対象VCに対応する位置を示します。

statusPurposeは、そのステータス確認が何のためのものかを示します。代表例はrevocationやsuspensionです。失効と一時停止は業務上の意味が異なるため、Verifier側の判定ポリシーも分けて設計します。

Status List Credentialの中身

Status List Credentialは、それ自体がVerifiable Credentialです。つまり、Verifierは対象VCだけでなく、参照先のStatus List Credentialも検証します。

Status List Credentialの中には、圧縮されたビット列がencodedListとして入ります。W3C仕様では、ビット列は最低16KBのサイズを持ち、GZIPで圧縮したうえでbase64urlのMultibase表現として扱われます。

考え方はシンプルです。

1. Issuerが発行済みVCの一覧を持つ
2. 各VCにリスト内の位置を割り当てる
3. 状態に応じて該当位置の値を設定する
4. ビット列を圧縮してStatus List Credentialに入れる
5. Verifierは取得したリストを展開し、対象位置の値を読む

1ビットで表す場合、0と1の2状態を扱えます。statusSizeを使うと、1件あたり複数ビットを割り当て、より多い状態を表現できます。statusSizeを1より大きくする場合は、対応するstatusMessageも必要になります。

Verifierの検証フロー

Verifierは、VC本体の署名検証だけで判断を終えません。Status List Credentialも検証対象になります。

おおまかな流れは次の通りです。

1. 提示されたVCまたはVPを検証する
2. VC内のcredentialStatusを読む
3. statusListCredentialからStatus List Credentialを取得する
4. Status List Credentialの署名、発行者、目的、有効性を検証する
5. statusListIndexの位置を読み、受け入れ可否を決める

VC本体とStatus List Credentialを分けて検証し、最後に指定indexの値を読みます。

W3C仕様では、Status List Credentialを検証するときに、対象VC側のstatusPurposeとStatus List Credential側の目的が合っているかも確認します。revocationを見たいのに、参照先が別目的のリストなら、正しく判定できません。

また、対象VCのIssuerとStatus List CredentialのIssuerが同じとは限りません。委託運用や共同運用では、Status Issuerが分かれる場合があります。Verifierは、両者の信頼関係を確認できるようにしておく必要があります。

statusListIndexの設計

statusListIndexは単に配列の番号に見えますが、プライバシーと運用に影響します。

発行順に連番を振ると、複数のVCを観測したVerifierが発行量や発行時期を推測できる可能性があります。特定の証明種別だけ小さなリストに分けると、グループプライバシーも弱くなります。

Issuerは、次の論点を決めておく必要があります。

• インデックスを連番にするか、推測されにくい割り当てにするか
• 未使用インデックスをどの程度混ぜるか
• リストを証明種別、発行時期、Issuer単位でどう分けるか
• 再発行時に古いインデックスをどう扱うか
• リスト更新とキャッシュ反映のタイミングをどう決めるか

リストを大きくすればグループ性は高まりやすくなります。一方で、更新範囲や配信負荷は大きくなります。失効頻度、発行量、Verifierの取得頻度を合わせて設計するのが現実的です。

失効と一時停止を分けて考える

Bitstring Status Listは、失効確認だけの仕組みとして捉えられがちです。しかし、statusPurposeを使うことで、一時停止やメッセージなどの用途も設計できます。

たとえば資格証明では、完全な取り消しと一時停止を分けたい場面があります。在籍証明では、退職を失効として扱うのか、証明期限切れとして扱うのかを整理する必要があります。

Verifier側では、revocationなら拒否、suspensionなら一時保留、独自メッセージなら追加確認といった判定ルールをあらかじめ決めます。Status Listの値だけを読んでも、業務判断は完成しません。

実装時の注意点

Bitstring Status Listを実装するときは、仕様のデータ構造だけでなく運用設計も重要です。

特に注意したいのは、キャッシュと取得失敗時の扱いです。

Status List Credentialはキャッシュしやすい形式です。古いリストを使い続けると、失効済みVCを受け入れるリスクが残ります。一方で、常に最新取得を強制すると、可用性やプライバシーの問題が出ます。

ユースケースごとに、次のような方針を決めます。

• 何分前までのStatus List Credentialを許容するか
• 取得失敗時に拒否、保留、再試行のどれを選ぶか
• 失効反映のSLAをどう設定するか
• 監査ログに何を残し、何を残さないか
• CDNやミラー配信をどう使うか

本人確認、資格確認、入退場、金融取引では、同じStatus Listでも要求される鮮度と可用性が変わります。

Token Status Listとの違い

Bitstring Status Listは、W3C VC Data Model系のStatus List Credentialを中心にした方式です。JSON-LD VCやW3C VC Data Modelに寄せた実装では、この仕様を確認することになります。

一方、SD-JWT VC、JWT、CWT、ISO mdocなどのトークン系では、IETF OAuth Working GroupのToken Status Listが関係します。

両者は、どちらも「リスト内の指定位置を見る」という発想を共有しています。ただし、VC側の参照フィールド、リストの表現、署名方式、有効期限やTTLの扱いが異なります。

どちらを使うかは、先に採用するVC形式でほぼ決まります。W3C VC Data Model系ならBitstring Status List、SD-JWT VCやJWT/CWT系ならToken Status Listを中心に読むのが自然です。

まとめ

Bitstring Status Listは、W3C VC Data Model系でVCの状態を確認するための主要な仕組みです。

VC本体にはcredentialStatusが入り、VerifierはそこからStatus List CredentialのURLとインデックスを読みます。Status List Credentialはそれ自体がVCなので、署名、発行者、目的、鮮度まで検証する必要があります。

実装で重要なのは、ビット列の読み方にとどまりません。リスト分割、インデックス割り当て、キャッシュ、取得失敗時の扱い、Status Issuerの信頼関係まで含めて設計することです。

W3C VC Data Model系でIssuer/Verifierを作るなら、Bitstring Status ListはVCライフサイクル全体の一部として最初から設計するべきです。

参考資料

• W3C, Bitstring Status List v1.0: https://www.w3.org/TR/vc-bitstring-status-list/
• W3C, Verifiable Credentials Data Model v2.0: https://www.w3.org/TR/vc-data-model-2.0/
• IETF OAuth Working Group, Token Status List: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
• DID/VCメディア, VCのStatus Listとは何か: /vc-status-list-revocation