Verifiable Credentials（VC）実装ガイド

VC（検証可能な証明書）とは、W3Cが標準化した「電子的に署名され、第三者が真正性を検証できる証明書」の仕様です。学位・資格・在職証明・住民票などの「属性証明」を、紙やPDFではなく改ざん不可能な署名付き電子データとして発行・流通させる仕組みです。VC Data Model 2.0 は2025年5月15日にW3C勧告として正式標準化されました。

DIDは「識別子」、VCは「属性証明書」です。たとえばDIDが免許証番号に近い識別子だとすれば、VCはその免許証に書かれた情報（氏名・生年月日・運転種別など）に相当します。ただし、VCのsubject IDが常にDIDである必要はありません。ユースケースによってはDIDを使わず、別の識別子や識別子なしの属性証明として設計することもあります。DIDの詳細は当社の「DID（分散型ID）とは？」記事を参照ください。

既存のJWT基盤と互換性を重視するならJWT-VC、W3C VC 2.0のセマンティックな表現や語彙連携を重視するならJSON-LD/Data Integrity、選択的開示（最小開示）が必要なケースではSD-JWT VCを選びます。モバイル運転免許証（mDL）や組込み・バイナリ効率を重視する領域ではCOSE-VCも選択肢になります。実務では、対象市場・ウォレット互換性・検証者側の実装負荷で決めるべきです。

保有者が自分のVCの一部だけを提示者に開示できる仕組みです。たとえば運転免許証VCを使って酒類購入時の年齢確認をする場合、氏名・住所・免許番号は隠して「20歳以上である事実」のみを提示する、といった使い方ができます。SD-JWT または BBS+ Signatures（ZK）で実装します。

VC 2.0文脈では Bitstring Status List v1.0 が重要な選択肢です。発行者が公開するビット列の特定位置に各VCの状態を対応させ、失効・停止などの状態を検証者が確認できるようにします。検証者はVC内のstatus情報からステータスリストを参照し、該当ビットを確認します。設計時には、更新頻度、キャッシュ、プライバシー、SLAをあわせて決める必要があります。

可能です。マイナンバーカードの公的個人認証（JPKI）で本人確認を行い、その結果を VC として発行する設計が現実的です。デジタル庁の「Trusted Web」推進会議でも、公的認証と自己主権型VCを橋渡しする方向性が示されています。

OpenID for Verifiable Credential Issuance（OID4VCI）はVC発行のプロトコル、OpenID for Verifiable Presentations（OID4VP）はVC提示のプロトコルです。OID4VCI 1.0は2025年9月、OID4VP 1.0は2025年7月にFinal Specificationとして公開されました。どちらもVCの形式を1つに限定するものではなく、SD-JWT VC、ISO mdoc、W3C VCDMなど複数形式を扱える設計です。

欧州デジタルアイデンティティウォレット。EU eIDAS 2.0規則に基づき、EU加盟国が市民・居住者向けにデジタルIDウォレットを提供していく枠組みです。2026年末頃までに各加盟国が少なくとも1つのウォレットを提供することが求められると整理されています。VCやデジタル属性証明の大規模実装事例になる可能性が高く、日本企業がEU向けサービスを提供する場合は、今後の実装仕様・受入義務・対象業種を継続確認すべきです。

最小構成のPoC（Issuer + Verifier + Holder Walletサンプル）であれば、4〜8週間で動作確認まで可能です。Netsujo の PoC設計パッケージ（80万円・4週間）では、想定ユースケースのVCスキーマ定義・セキュア化形式選定・実装ライブラリ評価までを伴走します。詳細は /pricing ページを参照ください。

4つあります。1) ウォレット普及（ユーザーが VC を受け取れる環境がないと普及しない）、2) Issuer の信頼性確認（誰が正当な発行者かを Verifier 側で判断する仕組み）、3) Revocation 運用（失効更新の頻度とSLA）、4) ユーザーの鍵紛失リカバリ。設計段階で全て言語化することが本番化の前提条件です。