VCの発行者を信頼してよいか｜信頼レジストリで認定・停止を管理する方法

ある病院の採用システムが、応募者から「医師免許」のデジタル証明書（VC）を受け取りました。システムが署名を調べると、正しい署名です。署名したのは、実在する大学でした。

ところが、その大学が出せるのは在籍証明までで、医師免許を発行する立場にはありません。署名が示すのは「対応する秘密鍵で署名された」ことだけです。その組織が医療資格や修了証を発行してよいかまでは、署名からは分かりません。

署名が本物かどうかと、その組織に発行する資格があるかどうか。この2つをつなぐのが、信頼レジストリ（Trust Registry）です。どの組織が、どの証明書を、いつ発行してよいかを記録し、確かめる側に届けます。

レジストリを作るとき、最初に決めるのは台帳の技術ではありません。台帳を先に選ぶと、誤って登録したときに誰が止めるのかが決まらないまま、変えられないデータだけが残ってしまうからです。先に決めるのは、運営の取り決めです。

• 誰が発行者を認定するのか
• 誰が止めるのか
• 止めたという知らせが、いつ確かめる側に届くのか

以下では、認定する側（業界団体や監督機関など）、発行する側、確かめる側でシステムを設計する担当者が、認定・更新・停止・取消・障害からの復旧を、仕組みと運用に落とす順に見ていきます。VC全体の構成は「DID・VCの導入設計」、VCの基礎は「Verifiable Credentialsとは」で解説しています。

この記事でわかること

• 発行者を「どの証明書を、どこで、どの水準で」出せるかの組み合わせで認定する方法
• 発行者の5つの状態と、鍵の事故・認定の取消の分け方
• 障害時の判断、実装方式の選び方、PoCで試すこと

信頼レジストリは「誰が、何を、いつ発行してよいか」に答える

W3C Verifiable Credentials Data Model v2.0は、2つの確認を分けています。証明書（credential）が本物かを調べる検証（verification）と、今の用途に合っているかを判断する妥当性確認（validation）です。信頼レジストリが担うのは、主に後者の材料です。

検証者は、署名の検証が通った後も、次のことが自社の判定方針に合うかを確かめます。発行者（Issuer）、証明書の種類、法域、保証レベル、登録の状態です。

冒頭の大学は、在籍証明は出せても、医師免許は出せません。登録の単位を「発行者」や証明書1件にすると、この区別ができず、権限が広すぎてしまいます。そこで、認定の最小の単位を組み合わせにします。たとえば「大学Aは、日本で、在籍証明を、この保証レベルで発行してよい」という形です。鍵は、その認定にひも付く確かめ方として、別に管理します。

レジストリに登録する項目と、それぞれの更新の責任は次のとおりです。

各項目の具体例（法人ID、DID、スキーマ、鍵の置き場所など）は、後半の「実装する人向けの詳細」にまとめました。

発行者が法人の場合の実在確認や、担当者が法人を代表して操作する権限の検証は「法人デジタルIDと委任権限の検証」で扱います。

運営の決まりを先に作り、データの形と基盤は後から選ぶ

冒頭で見たとおり、台帳を先に選ぶと、止める人も履歴を守る人も決まらないまま、変えられないデータだけが残ります。発行者が撤退した後に、誰が履歴を保つのかも決まりません。そこで、次の順に決めていきます。

1. 信頼の起点を決める：法律上の監督機関、業界団体、契約の当事者など、発行者を認定する根拠を文書にする。
2. 登録の基準を証拠に落とす：法人の確認、資格、監査の結果、契約、更新の期限を決め、審査する人と承認する人を分ける。
3. 権限を狭くする：発行者を丸ごと許可せず、証明書の種類、スキーマの版、法域、用途ごとに許可する。
4. 状態と期限を決める：一時停止、取消、期限切れを区別する。それぞれの状態で、検証者が「確認できなくても通す（fail-open）」か「止める（fail-closed）」かを決める。個々の証明書の失効は「VCの失効設計」で扱うステータスリストで管理し、発行者の認定の状態とは分ける。
5. 届け方の目標値（SLO）を決める：更新が反映されるまでの時間、キャッシュの上限、障害時の別の経路、監査ログを残す期間を数字で決める。
6. 基盤を選ぶ：運営が1つなら署名付きのリスト、複数の組織で共同運営するなら透明性ログや許可型の台帳など、要件を満たす最小の構成を選ぶ。

EU Digital Identity Walletの公式の案内でも、発行者の登録、Trusted List（信頼できる事業者を載せる公式の一覧）への信頼の起点の追加、認定の停止・取消は、別々の運用として示されています。EUDI Walletの発行者向け資料は、技術的な鍵だけでなく、登録・認証・続けて負う義務まで、信頼のしくみに含めています。

ブロックチェーンに載せてよいのは、公開してよく、めったに変わらず、共有する情報だけ

ブロックチェーンが候補になるのは、次のような場合です。独立した複数の組織が、同じ登録の状態を参照する。1つの主体が過去の履歴を書き換えたら、それに気づきたい。一方、運営者が1つで、署名付きのリストを止まらずに配れるなら、中央のDBと透明性ログの方が、更新・訂正・費用を単純に管理できます。ですから、ブロックチェーンは必須ではありません。

データごとの置き場所は、次のように決めます。

• 発行者ID、権限の範囲、状態、判定方針のハッシュ：共有の台帳か署名付きのリストに置く。検証者が同じ判断の材料を確かめられるからです。
• 変更の記録のハッシュ、版、時刻：必要ならチェーン上に置く。順番と改ざんを見つける証拠になるからです。
• 法人の審査資料、契約、担当者の情報：アクセスを制限した運営のDBに置く。機密を守り、訂正し、保存期限を管理する必要があるからです。
• VCの本文、氏名、住所、会員番号：チェーン上には置かない。公開され、ずっと残り、ほかの情報と結び付けられる危険が大きいからです。
• 検証者の照会の履歴：各組織で、最小限の監査ログとして持つ。共通の台帳に集めると、誰がいつ使ったかを追えてしまうからです。

公開の台帳に置く値をハッシュだけにしても、安全とは限りません。候補になる値が少なければ、全部の候補をハッシュにして照らし合わせる辞書攻撃で推測できます。更新の時刻や参照の頻度から、組織の活動が分かることもあります。個人データをハッシュにして、ずっと残る台帳に置く設計は避けます。公開する必要、推測しやすさ、削除・訂正の要件を、1つずつ評価します。

発行者の登録は5つの状態で管理し、鍵の事故と認定の取消を分ける

鍵が漏れた場合と、不正な発行があった場合では、止めるべきものが違います。鍵の漏えいなら、その鍵だけを無効にして、新しい鍵へ移れば済みます。不正な発行や、認定の失効なら、発行者の権限そのものを止める必要があります。そのため、発行者の状態と、署名鍵の状態は別々に管理します。

発行者の状態は次の5つです。

状態が変わるときに残す証拠は、後半にまとめました。

状態の変更には、時刻を2つ持たせます。業務の上でいつから無効になるかと、検証者がいつから取れるようになったかです。たとえば取消が決まってからレジストリに載るまでに時間があけば、そのあいだの提示は、古い情報のまま通っているかもしれません。この差を測れば、事故のときに「何時までの提示を確かめ直すか」を決められます。

検証者は、署名の確認と認定の確認を分けて記録する

「有効」という1つの結果だけを残すと、後から何が通っていたのかを説明できません。署名は正しかったが、発行者の認定が切れていた、といった場合を見分けられないからです。

そこで検証の処理では、次のものを順に確かめ、結果を別々に残します。証明書の署名、発行者の鍵、信頼レジストリの署名か台帳上の証明、発行者の権限、登録の状態、判定方針の版です。記録の例は後半に載せました。

監査ログには、VCの全文や要らない属性を残しません。残すのは、要求ID、発行者ID、証明書の種類、参照した版、それぞれの判定、最後の結果です。キャッシュは署名と版を確かめて使い、有効期間（TTL）を過ぎたときの扱いを、証明書の種類ごとに決めます。

障害のときは「古い情報」と「不正な情報」を分けて扱う

レジストリに届かなくなったときでも、最後に取れた署名付きのスナップショットが期限内なら、検証を続けられる場合があります。情報が古いだけで、改ざんされたわけではないからです。

一方、署名が合わない、版が巻き戻った、認定を取り消したという知らせが来た、といった場合は違います。誰かが古い状態や偽の状態を見せようとしているおそれがあります。止まらないことを優先して、古い状態に戻してはいけません。

• 届け方の障害：署名付きのスナップショット、複数のミラー、どこまで古くてよいかの上限で、続けるかを判断する。
• 誤った登録：対象の版を止め、訂正の記録を追加する。過去の履歴を消して、つじつまが合ったように見せない。
• 管理鍵の漏えい：緊急停止用の別の経路、鍵の更新、複数人の承認（閾値）、影響を受ける版の一覧を用意する。
• 発行者の撤退：発行済みのVCをいつまで認めるか、状態の情報と信頼の起点を誰が保つかを、契約が終わる前に決める。
• ネットワークの分断：リスクの高い処理は止め、低い処理は期限付きのスナップショットで続けるなど、業務ごとに決める。

中央DB・署名付きリスト・ブロックチェーンを、運営の条件で比べる

方式ごとの向いている条件と注意点は、次のとおりです。

方式ごとの主な利点は、後半にまとめました。

ブロックチェーンを選んでも、運営の決まりは自動では決まりません。誰が検証ノードになるか、緊急停止を誰が承認するか、ソフトウェアのアップグレードをどう合意するか、です。EBSIのTrust Chainの説明は、具体的な例の1つです。認定を証明書としてつなげ、Trusted Issuers Registry（認定済み発行者の登録簿）で監査できるようにしています。ただし、これは参考の実装です。すべてのVCのしくみが、同じ階層を必要とするわけではありません。

PoCでは、誤った登録・遅れ・巻き戻りをわざと起こす

正常な発行者を登録してVCを確かめるだけでは、冒頭のような場面を一度も通りません。それでは本番の運用を評価できません。証明書の種類を1つに絞り、次の受け入れ試験を自動で回します。

• 署名が正しくても、未認定の発行者、許可外の証明書の種類、期限切れの認定を拒否する。
• 発行者の停止から、すべての検証者に反映されるまでを測り、決めた目標値に収まる。
• 古いスナップショット、版の巻き戻り、レジストリの署名の不一致を見分けて、拒否・警告する。
• 管理鍵が1本漏れただけでは、認定の追加や停止の解除を確定できない。
• レジストリが止まっているあいだはリスクの高い処理が止まり、戻った後に二重に処理しない。
• 誤った登録を訂正した後も、誰がいつ何を承認したかを監査できる。
• ログ、アクセス解析、公開の台帳に、VCの本文や個人の属性が残らない。

ブロックチェーン型のレジストリを採用してよいのは、2つの条件がそろうときです。独立した組織のあいだで発行者の認定を共有する必要があること。認定の基準と状態の変更を、共同で運用できること。反対に、運営する主体が決まらない、関係者が固定されている、中央のAPIで足りる、登録が秒単位で頻繁に変わる場合は、採用しない方が安全です。

実装する人向けの詳細

ここからは、レジストリと検証の処理を実際に作る担当者向けに、前半で後回しにした例と記録の形をまとめます。

認定の単位と、登録項目の例

最小の認定単位は issuer × credential type × jurisdiction × assurance level（発行者×証明書の種類×法域×保証レベル）です。

状態ごとの遷移の証拠と、2つの時刻

状態の変更には effective_at（業務上いつから無効か）と published_at（検証者がいつ取得できるようになったか）の両方を持たせます。

検証結果の記録例

単一の valid=true にまとめず、少なくとも次の結果を残します。

{
  "credential_signature": "valid",
  "registry_integrity": "valid",
  "issuer_authorization": "active",
  "scope_match": true,
  "registry_version": "2026-08-12T09:00:00Z",
  "policy_version": "employment-v3",
  "decision": "accept"
}

実装方式ごとの主な利点

XTELAができること

私たちは、VCの信頼モデル、登録データ、権限と状態遷移、検証者の判定方針を設計し、誤登録・配信遅延・巻き戻りを注入する障害試験を含むPoCとして実装しています。貴社が認定する側でも検証する側でも、証明書の種類を1つに絞って運営の取り決めと技術構成を同時に固められます。認定の法的効力や業法上の資格に関わる判断は、弁護士と連携して進めます。技術構成の整理が必要な場合はお問い合わせください。

参考資料

• W3C Verifiable Credentials Data Model v2.0
• W3C Threat Model for Decentralized Credentials
• European Commission: EUDI Wallets for Issuers
• European Commission: EUDI Wallet Trust Ecosystem
• EBSI: Introduction to Trust Chains

資料の確認日

仕様・資料は2026年9月24日に確認しました。