企業がDID・VCを本番に入れる前に確かめること｜発行者の信頼・失効・紛失時の再発行

目次（タップで折りたたみ）

ある資格団体が、紙の会員証をやめて、スマホで見せるデジタル会員証を出すことにしました。会員はそれを持って、別の会社が主催する展示会へ行きます。受付でスマホのQRを見せると、会員向けの枠で入場できる、という流れです。

会員証を出すのは資格団体の事務局、確かめるのは展示会の受付です。受付の端末にQRをかざし、「有効」と表示されるところまでは、すぐに作れます。困るのはその先です。

資格団体を名乗る別の組織が、正しい署名の付いた会員証を出していたら、受付は見抜けるか。
スマホをなくした会員の古い会員証が、別の人に使われ続けたら、誰が止めるのか。

こうしたデジタルの証明書を扱う技術が、DIDとVerifiable Credentials（VC）です。本番に入れてよいかの決め手は、暗号技術ではありません。受付が「発行者を信頼する根拠」を持てるか。事務局が「失効・再発行」を回せるか。この2つです。

そして、この流れのどこにもブロックチェーンは出てきません。事務局は今の会員DBを元に会員証を出し、受付は事務局の公開鍵と状態情報で確かめます。DID/VCと聞くとブロックチェーンを思い浮かべがちですが、必須ではありません。

この話が今進んでいるのには背景があります。2025年9月16日には、発行の手順を定めた仕様（OpenID for Verifiable Credential Issuance 1.0）が最終版になりました。2025年11月には、必要な項目だけを見せる方式SD-JWTが標準仕様になっています。2026年4月には、デジタル庁が「行政機関におけるVC・DIWの活用にあたる検討事項リスト（案）」を示しました。

以下では、事務局の側と受付の側を行き来しながら、それぞれが何をすればよいかを見ていきます。

この記事でわかること

VCが向いている場面と、今の仕組みで足りる場面の見分け方
確かめる側が見るべき6つのことと、発行者の信頼を運用で支える方法
失効・紛失・個人データの扱いで、本番前に試しておくべき障害

この記事で使う言葉

VC：発行元の署名が付いたデジタルの証明書。会員証、資格証明、本人確認済みの属性など。
発行者（Issuer）：証明書を出す組織。この場面では資格団体の事務局。
所持者（Holder）：証明書をウォレット（証明書を保管するアプリ）に入れて持つ人。この場面では会員。
検証者（Verifier）：提示された証明書を確かめ、申込や入場を受け付ける側。この場面では展示会の受付。
DID：発行者などの公開鍵のありかをたどるための識別子。住所のようなもの。

VCやDIDの仕組みそのものから知りたいときは、「Verifiable Credentialsとは」「自己主権型アイデンティティ（SSI）とは」が入口になります。

まず、VCが必要な場面かを確かめる

資格団体と展示会の主催会社は、別々の組織です。受付が入場のたびに、資格団体の照会APIにつなぐのは手間がかかります。会員は、ほかの団体の催しにも同じ会員証を持っていくかもしれません。VCが役に立つのは、こういう場面です。

それでも、事務局の会員DBは要らなくなりません。こうした正本の業務システムは「system of record」とも呼ばれます。事務局は資格の根拠や会員の状態を管理し続け、訂正・再発行・監査も引き受けます。

受付の側も同じです。主催会社は、検証結果にもとづく申込・入場・権限の記録を持ち続けます。変わるのは一部だけです。事務局に毎回問い合わせなくても、会員から受け取った証明を確かめられるようになります。

VCが向くかどうかは、次の5つの条件で見分けられます。

条件	中央API・ID連携（フェデレーション）が向く	VCが向く可能性がある
関係者	単一企業・固定の提携先の中	独立した組織をまたぎ、接続先が増減する
接続	常時オンライン、即時照会が必要	所持者経由、オフライン・端末をまたぐ提示が必要
データ	頻繁に変わる残高・権限・状態	発行時点の資格・属性を、期限や状態情報付きで証明
プライバシー	発行者が全照会を把握してよい	発行者に提示先を知らせたくない
運用	共通のID基盤（IdP）と契約で統制できる	発行者・ウォレット・検証者の相互運用が必要

一方、資格団体が自分の会員サイトの中だけで会員証を使うなら、事情は違います。同じバックエンドが発行・提示・検証をこなし、外部とつなぐ予定もないなら、今の仕組みの方が単純です。署名付きトークンや、既存のログイン連携（OIDC）で足ります。

採用の理由を「分散化」だけにしないでください。次のどれが必要かで判断します。

発行者との個別API接続を減らしたい
提示先を発行者に知られたくない（プライバシー）
オフラインでも確かめたい
組織をまたいで証明を持ち運びたい

受付の側では、何を確かめればよいか

製品やDIDの方式（DID method）を選ぶ前に、受付が最後に何を判断するかを定めます。展示会の受付が知りたいのは「有効な会員か」だけのはずです。そこで氏名、住所、生年月日を丸ごと出させたら、VCを使ってもデータは最小になりません。

受付のような検証者が確かめることは、次の6つです。署名が正しいかは、そのうちの1つにすぎません。

確かめること	答える質問
発行者の認定	この組織は対象の証明書を発行してよいか
署名の検証（暗号学的検証）	内容は改ざんされず、対応する鍵で署名されたか
提示者との結び付き（Holder binding）	提示者はその証明書を使う権限を持つか
状態・期限	発行後に失効・停止・更新されていないか
提示の要求	必要な属性だけが、意図した検証者へ提示されたか
業務判定	検証結果で申込・入場・権限付与を許可するか

特に大事なのは、上の2つの違いです。署名が数学的に正しいことと、その団体が「この会員証を出してよい組織」であることは別の話です。署名だけを見る受付は、資格団体を名乗る未認定の組織が出した会員証も通してしまいます。

W3C Verifiable Credentials Data Model v2.0も、この2つを分けて扱っています。証明書や提示（presentation）そのものを確かめる「検証（verification）」。主張が今の目的に有効かを判断する「妥当性確認（validation）」です。各項目の根拠と失敗時の扱いは、後半の表にまとめました。

受付は、資格団体が本物だとどう知るか

DIDは「この組織の公開鍵はここにある」とたどるための住所のようなものです。DIDからDID Documentという情報をたどると、検証用の鍵やサービスがわかります。ただし、相手が信頼できるかまでは教えてくれません。

受付がDIDをたどれても、それが正当な資格団体かは自動ではわかりません。大学、自治体、取引先でも同じです。DIDを管理する者と、DIDが指す相手が同じとは限らないからです。

そこで、鍵をたどる仕組みとは別に、発行者の台帳を持ちます。信頼レジストリ（trust registry）や契約台帳と呼ばれるものです。受付はここで「どの団体の、どの会員証を受け付けてよいか」を確かめます。主に次のことを記録します。

誰を認定したか：法人・組織ID、認定者、対象法域、連絡・障害時の窓口。
何を発行できるか：証明書の種類、スキーマ（項目の定義）とその版、対象資格、保証レベル。
どの鍵をいつ使えるか：鍵の参照先、鍵ID、有効期間、署名アルゴリズム。
変更を誰が承認するか：鍵の更新、スキーマ更新、認定停止、発行者の統廃合のときの手続き。

受付の側の方針（どの形式を受け付けるか等）も台帳に含めます。その中身は後半に回しました。

冒頭で触れたデジタル庁の検討事項リスト（案）も、この点を扱っています。検証者が発行者を信頼する方法として挙げるのは、PKI、Web PKI、Trusted List等です。PKIは、公開鍵の証明書で相手の身元を保証する仕組みです。

同じ資料は、発行者が撤退した後の公開鍵・状態情報の管理まで検討事項にしています。資格団体が解散したら、受付は何を頼りに確かめるのか、という問題です。ブロックチェーンにDIDを登録するだけでは、こうした運営の仕組みはできあがりません。

認定の単位、停止・取消の反映、登録情報の遅れや巻き戻りへの対処は「VCの信頼レジストリ設計」で詳しく扱います。会員が個人ではなく法人で、代表権や委任を確かめたい場合は「法人デジタルIDと委任権限の検証」をご覧ください。

事務局の側では、会員の個人データをどこに置くか

置き場所は、今とほとんど変わりません。本人確認の原本や会員マスターは、事務局の既存DBに残します。会員はウォレットで会員証を持ちます。受付は、提示された属性を公開鍵・状態情報と合わせて確かめます。

公開台帳やブロックチェーンを併用する構成もあります。その場合も、個人データはブロックチェーンの外（オフチェーン）に置くのが基本です。公開側に置くのは、検証に必要な最小限です。候補は次のとおりです。

DID Documentへの参照
公開鍵
スキーマのハッシュ
信頼レジストリの変更記録
集約した状態情報

氏名、住所、会員番号、提示の履歴は置きません。

発行者のDB → 発行API → 所持者のウォレット → 提示 → 検証者

公開・共有層：発行者の鍵 / 信頼レジストリ / スキーマの版 / ステータスリスト

非公開層：本人確認の原本 / 個人属性 / ウォレットの秘密鍵 / 提示・業務ログ

こう分けても、付随情報（メタデータ）から会員の動きがつながることがあります。

受付が会員証1枚ごとに状態を問い合わせると、事務局は「誰かが今その会員証を使った」と推測できる。
会員が同じDIDや固定の識別子を複数の催しで出すと、主催者どうしで名寄せされるおそれがある。

デジタル庁資料も、ログや利用状況の送信データ（telemetry）を減らすよう求めています。提示・照会の履歴も同じです。つながるおそれのある識別子・メタデータの棚卸しも求めています。

事務局は、会員証の状態をどう管理するか

「発行済み」「失効済み」の2つだけでは足りません。例えば再発行中の会員や、紛失の申告を扱えません。事務局の鍵の事故や、状態情報の配信障害にも対応できません。

そこで、事務局の業務の状態と、受付から見える会員証の状態を対応させます。状態は次の7つです。

発行対象（審査済み）
発行手続き中
有効
一時停止
失効
期限切れ
後継の証明書に置き換え済み

それぞれの証拠、外に公開するもの、やり直しのときの決まりは、後半の表にまとめました。要点は2つです。同じ依頼で二重に発行しないこと。元に戻せない失効は再有効化せず、再発行することです。

失効を、受付にどう伝えるか

会員が退会したとき、その会員証を受付で通さないようにする仕組みが要ります。方法の1つがW3C Bitstring Status List v1.0です。多くの証明書の状態を1本のビット列にまとめて配る方式です。1枚ごとに問い合わせるより、会員を追跡されにくくなります。

このリスト自体にも署名が付き、受付の端末は取得・検証・キャッシュ（手元に保存）できます。ただし、更新の間隔を長くすると失効の反映が遅れます。短くすると、事務局が止めずに配り続ける負担や配信の負荷が増えます。

どの方式にするかは、何を優先するかで変わります。

要件	設計の選び方	受け入れ時に試すこと
すぐに止めたい	キャッシュの有効期間を短くし、プッシュ通知かオンライン照会を検討	失効から全検証者への反映までを計測
提示の追跡を抑えたい	集約したステータスリストを配信網（CDN）で配り、証明書ごとのAPIを避ける	発行者のログから個別の提示先を推定できないこと
オフラインでも確かめたい	オフラインを許す最長期間と、状態情報をどこまで古くてよいかを明示	期限内のキャッシュで通り、期限を過ぎたら定めた代替手段へ
発行者が止まっても続けたい	署名済みリストのミラー（写し）、運営の移管、短い証明書期限を設計	発行者の配信先が止まっている間の挙動と、復旧後の同期

鮮度の決め方や巻き戻りの検知など、実装の詳細は「VCの失効設計」で整理しています。

会場の通信が途切れ、状態を確かめられないこともあります。そのとき有効として通すか、入場を止めるかも決めておきます。影響は、施設入場、年齢確認、専門資格などで違います。本人確認済みの属性でも異なります。そのため共通の既定値にせず、証明書の種類ごとに選びます。

受付に必要な情報だけを見せるには

選択的開示とは、ウォレットが証明書の一部の属性だけを見せる機能です。冒頭で触れたSD-JWTが、そのための方式です（仕組みは後半）。ただ、「選択的開示に対応」と書いてあるだけでは、プライバシーは守られません。つまずきやすい点は4つです。

受付の要求が氏名・住所・生年月日を常に必須にしていれば、ウォレットは減らしようがない。
珍しい属性の組合せ、固定の主体ID、発行者固有の値から、本人を推測できる。
同じ証明書や、同じ鍵との結び付きを繰り返し見せると、検証者どうしで照らし合わせられる方式がある。
ウォレット画面が「この検証者へ何を、何の目的で渡すか」を示さなければ、暗号方式が正しくても同意の中身が見えない。

まず主催会社の業務の責任者と、要求そのものを見直します。例えば年齢制限のある催しなら、「18歳以上か」という結果だけで足りるのか。生年月日そのものが必要なのか。

保存が必要な項目と期間は、業務ごとに定めます。技術側は、次の設定ができるように作ります。

目的と保持期間
アクセス制御と削除
監査の記録

部分開示と、派生属性・ゼロ知識証明の使い分けは「年齢・資格証明の選択的開示設計」で詳しく扱います。

会員がスマホをなくしたら、事務局はどう再発行するか

会員証用のウォレットは、暗号資産のウォレットと同じとは限りません。会員証は事務局が出し直せるからです。会員に秘密鍵のバックアップを強いるより、再発行の方針を整える方が大切です。

方針には、端末の追加、機種変更、紛失を含めます。死亡・退職や、組織が管理する端末の交換も対象です。再発行は次の順で進めます。

新しい端末の持ち主を、既存のID基盤で再認証する。保証レベルも記録する。
古いウォレットの鍵に結び付いた会員証を、一時停止か失効にする。
新しい鍵に結び付けて会員証を再発行する。旧・新IDの対応は、事務局の監査DBだけに持つ。
状態情報が受付まで行き渡るまでの、新旧が重なる期間を測る。高リスクの操作では追加認証を求める。
端末が見つかっても、旧会員証を自動で有効に戻さない。

ここでも、会員証の中身や会員の属性をNFTにする必要はありません。この構成では勧めません。鍵の一般的な回復設計は「ソーシャルリカバリーの実装設計」、ウォレットの利用者認証は「PasskeyとWebAuthnを使うWallet設計」も参考になります。

一方、会員が個人ではなく企業の従業員で、会社がウォレットを配る場合は、入社・異動・退職まで絡むので事情が違います。その運用は「企業向け証明書ウォレットの運用設計」で扱っています。ほかの関連記事は末尾にまとめました。

採用してよい条件と、PoCで試すこと

DID/VCを採用してよいのは、複数の組織で持ち運べる証明が必要な場合です。資格団体と、会員証を受け付ける主催会社のような関係です。そのうえで、次のことを関係者と共同で運用できる必要があります。

発行者の認定と、検証者の方針
スキーマ、鍵の更新、状態情報
ウォレットの復旧

冒頭の場面のとおり、個人情報をブロックチェーンに置くことも、中央DBをなくすことも要りません。

反対に、次の条件がそろうなら、既存のOIDC、署名付きトークン、中央APIを続ける方が安全です。

関係者が固定され、常時オンラインの照会で足りる
資格が頻繁に変わる
信頼レジストリの運営主体も決められない

PoC（本番前の試験導入）では、QRを読んで緑のチェックが出るデモだけでは本番採用を判断できません。受付で「有効」と出る流れより、信頼が壊れる場面を試します。まずは会員証のような証明書の種類を1つに絞り、少なくとも次を自動試験と運用演習に入れてください。

未認定の発行者による正しい署名を拒否できるか。認定済み発行者の誤ったスキーマや、許可外の署名アルゴリズムも同様。
提示の再送や、別の検証者への転送を拒否できるか（試し方は後半）。
失効反映の遅れ、状態確認の配信先の停止、古いキャッシュ、発行者の鍵更新を起こしても正しく動くか。
ウォレット紛失後、旧証明書が拒否され、新しい証明書だけが通るまでにかかる時間。
要求していない属性が、通信内容、ログ、分析基盤に残らないか。
発行者の統廃合、信頼レジストリの誤更新、スキーマの版の不一致から元に戻せるか。

合格の条件は、相互運用の見栄えより次の4つに置いてください。

失効が反映されるまでの時間
再発行が終わるまでの時間
不要な属性を持たないこと
発行者が撤退しても続けられること

実装する人向けの詳細

ここから先は、事務局と主催会社で実際にシステムを作る担当者が使う内容です。認証基盤の用語をそのまま使います。

6つの判定の根拠と、失敗時の扱い

判定ごとに根拠を分け、失敗時の扱いも別々に定義します。

判定	必要な根拠	失敗時の扱い
発行者の認定	信頼レジストリ（trust registry）、契約、認定、PKI等	署名が正しくても拒否
暗号学的検証	proof、公開鍵、許可する署名アルゴリズムの方針	検証エラーとして拒否
提示者との結び付き（Holder binding）	鍵による結び付け（key binding）、端末認証、セッションごとのchallenge	盗まれた証明書の再利用を拒否
状態・期限	validFrom/validUntil、ステータスリスト	期限切れと状態不明を区別
提示要求	nonce、audience、要求定義、同意画面	再送（replay）・過剰要求を拒否
業務判定	自社の判定規則とその版、個別の事情	人手審査や既存手段へ切り替え

実装ではsignature_valid=trueを業務承認と同一視しないでください。6つの判定結果と判定規則の版は、別々に記録します。

DIDと信頼レジストリ

DIDはURI形式の識別子で、DID Documentから検証用の鍵（verification method）やサービスを参照できます。W3C DID 1.0は、DIDの管理者（DID controller）とDIDが指す主体（DID subject）を分けています。両者が常に同一とは限らないモデルです。

信頼レジストリの「どの鍵をいつ使えるか」では、鍵の参照先をDID/JWKS/X.509等で持ちます。検証者側の方針として、許可する形式、proof、状態確認の方式、情報の鮮度、例外処理も記録します。

7状態の管理表

状態ごとに、確定させる証拠と再実行時の規則を持たせます。

状態	確定する証拠	外部へ公開するもの	再実行時の規則
発行対象（`ELIGIBLE`）	原本・審査結果、本人/組織との対応	なし	審査基準の版が変われば再評価
発行手続き中（`ISSUANCE_PENDING`）	発行オファーのID、所持者のセッション、証明書内容のハッシュ	短命な発行オファー	同じ冪等キー（idempotency key）で照会
有効（`ACTIVE`）	証明書ID、発行時刻、署名鍵、スキーマの版	必要なら集約した状態情報	同じ要求で重複発行しない
一時停止（`SUSPENDED`）	一時停止の理由、開始・解除の承認	一時停止（suspension）の状態	解除は新しい監査イベントとして記録
失効（`REVOKED`）	失効理由、承認者、時刻	失効（revocation）の状態	不可逆なら再有効化せず再発行
期限切れ（`EXPIRED`）	validUntilと検証時刻	証明書内の期限	更新条件を再評価して新規発行
置き換え済み（`SUPERSEDED`）	後継の証明書との対応	状態情報または短い旧有効期限	旧証明書を再利用しない

発行の手順にはOpenID for Verifiable Credential Issuance 1.0 Final（2025年9月16日公開）を採用候補にできます。提示の手順にはOpenID for Verifiable Presentations 1.0 Finalが候補です。

ただし仕様に準拠するだけでは、元データの審査や発行者の認定は決まりません。再発行の承認や、業務上の代替手段も同じです。各要求にissuance_request_idを付けてください。タイムアウト後は発行結果を照会し、未発行と確認できるまで新しい証明書を作りません。

状態を確認できないときの扱い

status_unavailableをactiveとして扱うか、業務を止めるかはリスクで変わります。「状態不明でも通す（fail-open）」「状態不明なら止める（fail-closed）」は、共通ライブラリの既定値にしません。証明書の種類ごとに設定します。

SD-JWTの仕組み

2025年11月発行のRFC 9901（SD-JWT）が定義するのは、開示値をソルト付きハッシュへ対応付ける仕組みです。ソルト付きハッシュは、ランダムな値を足してからハッシュ化した値です。所持者の鍵への結び付けも同じ仕様で定義されています。

PoCの試し方と、最小の監査記録

提示の再送と転送の試験では、nonce、audience、セッション期限を変えて、拒否されることを確かめます。

最小の監査記録には、次を保存します。

verification_request_id、証明書の種類、発行者の識別子
鍵ID、スキーマの版、状態情報の取得時刻
判定方針の版、各判定結果、業務結果

証明書の全文や不要な個人属性は、デバッグログへ残さないでください。同じ要求IDで再処理しても、二重申込・二重の権限付与が起きないことも確認します。

本記事の前提

一次資料（仕様・公的資料）は2026年9月24日に確認しています。

企業が従業員に配るウォレットの入社・異動・退職・紛失の運用：「企業向け証明書ウォレットの運用設計」
DIDそのものの鍵更新と支配権の復旧：「DIDの鍵更新とアカウント復旧」
ウォレットでのログインと証明書提示を一つの流れにまとめる設計：「VC提示でログインする設計」
一般的なブロックチェーンウォレットの方式と責任分界：「ブロックチェーンウォレットとは」
オンチェーンで表すIDとの違い：「SBTとデジタルアイデンティティ」

XTELAができること

私たちは、ID連携の要件整理から、信頼の起点とデータの流れの設計、ウォレットと発行・検証APIのPoC、失効遅延や発行者停止を注入する障害試験の設計・実装までを行っています。貴社の業務で「どの判定をVCに任せ、どこを既存システムに残すか」を一緒に決め、証明書の種類を1つに絞った検証から始められます。個人情報保護や証明書の法的効力に関わる判断は、弁護士と連携して進めます。技術構成の整理が必要な場合はお問い合わせください。

参考資料

記事一覧