Verifiable Credentials（VC）は、発行者を暗号学的に確認でき、改ざんを検知できるデジタル証明書である。紙の証明書を単にPDFへ置き換えるのではなく、機械的に検証可能な形で属性や資格を表現する。
## 1. 基礎概念
VCの基本モデルには三つの役割がある。
- Issuer：証明書を発行する
- Holder：証明書を受け取り、管理する
- Verifier：提示された証明書を検証する
たとえば大学がIssuer、卒業生がHolder、採用企業がVerifierになる。Issuerは「この人物が本学を卒業した」というClaimを含むVCへ署名する。Holderは必要な場面でVCまたはそこから構成したVerifiable Presentation（VP）を提示する。
VCには、発行者、Credentialの種類、Subjectに関するClaim、有効期間、暗号学的証明などが含まれる。表現形式や保護方式には複数の選択肢があり、JSON-LDとData Integrityを使う方式や、JWT・SD-JWT系の方式などがある。
重要なのは、署名検証と内容の真実性を分けることである。署名が正しければ「特定のIssuerがこの内容を発行し、発行後に改ざんされていない」ことは確認できる。しかし、そのIssuerが信頼できるか、Claimの根拠が正しいかは別問題である。
2. 技術フロー
VCの発行と提示は次のように整理できる。
Issuer
│ 1. Subjectを確認
│ 2. Claimを作成して署名
▼
Holder / Wallet
│ 3. VCを保管
│ 4. 必要なClaimを含むPresentationを作成
▼
Verifier
│ 5. Issuerの検証鍵を取得
│ 6. 署名・有効期限・状態を検証
│ 7. Holderによる提示であることを検証
▼
サービス提供を判断Verifierは暗号署名だけでなく、Credentialの有効期限、失効・停止状態、想定するCredential Schema、Issuerの信頼性、提示先やChallengeとの結び付きを検証する。古いPresentationの再送を防ぐため、NonceやDomainを使って今回の提示要求に応じたものか確認する。
Selective Disclosureに対応した形式では、HolderがCredential内のすべてのClaimを渡さず、必要な項目だけを開示できる。たとえば生年月日そのものではなく、年齢条件を満たすことだけを示す設計が可能になる。ただし、利用できる開示機能はCredential形式と暗号方式に依存する。
3. 何を解決できる技術か
従来のオンライン確認では、VerifierがIssuerへ毎回問い合わせる、紙や画像を目視確認する、利用者が同じ情報を何度も入力するといった負担がある。VCは、Issuerが発行した証明をHolder経由で提示し、Verifierが機械的に検証できるようにする。
これにより、組織をまたいだ資格証明、本人確認結果の再利用、学歴・受講履歴・会員資格などの検証を効率化できる。必要なClaimだけを提示する設計なら、不要な個人情報の収集も抑えられる。
一方、Issuerの信頼リスト、失効確認、Walletの紛失、Subjectと提示者の結び付け、複数回の提示による行動相関は残る課題である。VCは信頼を自動生成する技術ではなく、既存の信頼判断を検証可能なデータとして流通させる技術と捉えるべきである。
VCを運用するための補足
Credentialは「卒業証明」のような形式と、氏名、資格区分、修了日などのClaimを持つ。Schemaは各項目の意味と型を共有するが、同じSchemaで作られたCredentialが同じ信頼水準を持つとは限らない。誰が、どの審査手続きで発行したかが重要になる。
HolderとCredential Subjectも常に同一ではない。保護者が子どものCredentialを保持する場合や、担当者が法人のCredentialを提示する場合がある。誰について述べ、誰が正当に提示できるかを分けて扱う必要がある。
Issuerを信頼する条件はTrust Frameworkで定める。認めるIssuer、発行可能なCredential Type、審査・監査基準、問題発生時の責任を規定する。暗号署名は署名者を確認できても、無関係な組織が「卒業証明」を発行すること自体を禁止できない。
検証は形式検証と業務判断に分かれる。前者では構文、署名、鍵、期限、Status、Holder Bindingを確認する。後者ではIssuer、資格区分、発行時期などをPolicyで評価する。形式上有効でも業務Policyを満たさなければ受け入れない。
Holder Bindingは、盗まれたCredentialを第三者が提示することを防ぐ。CredentialをHolderの鍵へ結び付け、提示時に秘密鍵の制御を証明する。強いBindingは不正利用を抑える一方、鍵紛失時の再発行を難しくする。
Selective Disclosureにも水準がある。SD-JWTでは個別のClaimを選択的に開示できるが、生年月日を隠して「20歳以上」だけを証明できるかは方式による。Zero-Knowledge Proofによる述語証明は高度だが、実装と相互運用性は複雑になる。
Status確認にもプライバシー問題がある。Credential固有URLへ問い合わせる方式では、Issuerが提示先と時刻を推測できる。複数Credentialの状態をまとめたStatus Listは、この漏えいを減らす。完全なオフライン検証では最新状態を確認できないため、鮮度と可用性のバランスが必要になる。
VCは発行、保管、提示、検証、更新、失効、再発行、廃棄までを一つのライフサイクルとして設計する。署名とデータモデルだけを実装しても、運用可能な証明書にはならない。
Credential設計の具体的な判断
一枚へ多数のClaimをまとめると管理は簡単になるが、提示のたびに不要な属性まで関連付けられやすい。目的ごとに分割すれば最小開示しやすい一方、Wallet内のCredential数と失効管理が増える。Selective Disclosureの能力と提示先から粒度を決める。
有効期限は短ければ安全とは限らない。短期Credentialは古い情報の利用を減らすが、頻繁な再発行が必要になりIssuerの可用性へ依存する。長期Credentialは使いやすいが、属性変更や資格停止をStatusで迅速に反映しなければならない。
再発行では旧Credentialを失効させるか、新しい鍵へ同内容を発行するかを決める。旧版と新版へ共通の追跡可能な識別子を持たせると管理は容易になるが、複数提示を相関させる手掛かりになる。
Verifierは検証失敗の理由を利用者へ返す必要があるが、内部Trust Policyの詳細公開は攻撃者へ情報を与え得る。利用者向け説明、運用者向け診断、監査ログで情報量を分ける。
IssuerとVerifierが常時接続でき、利用者が証明を保持する必要もないなら、中央照会APIの方が運用しやすい場合がある。複数提示先への持ち運び、データ最小化、Issuerへの提示先秘匿が必要なときVCの利点が大きくなる。
参考資料
- [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/)
- [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/)
- [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/)
