デジタル資格情報の標準技術仕様「VCs」の概要からユースケースまでを解説！

2023.3.24

NRIデジタルの小松です。前回の記事では、SSIおよびSSIの実現手段としてのDIDsについて解説しました。本記事では、DIDsと組み合わせることでSSIの実現が期待されるVCs（Verifiable Credentials）について、解説します。

VCsとは

VCsとは、W3C（Web技術の標準化団体）が推奨する、デジタル資格情報の標準技術仕様を指します。暗号的に安全で機械的に検証可能な仕様を目指し、W3Cがデータモデル等を定義しています。Verifiable Credentialsの略で、「検証可能な資格情報」として、運転免許証、卒業証明書など現在私たちが物理的に所有する様々なクレデンシャルを、デジタル上で検証可能にしたものです。

リアル世界では、私たちが所有するさまざまな資格情報の検証は、多くの場合物理カードの提示によって成立します。例えば、年齢確認を求められた際には、自身の運転免許証などを見せれば確認が取れたことになります。それは、国や地方自治体などの公的な団体が発行主体であり、必要十分な身元確認を行ったうえで発行されたものである、という信頼に基づいています。特に運転免許証は、発行元（＝身元確認を行った第三者機関）が信頼できる団体であることが自明ですし、物理的なカードに厚みやICチップなどを付与して複製を難しくしています。

一方で、非対面での資格情報の検証を上記のようなUXで実現するのは困難です。オンライン上でユーザが提示したデータが、偽造されていないことを保証する確実な手段がないからです。したがって、従来から、データを利用する事業者は、情報連携途中のデータの改ざんを防ぐため、デジタル上のデータのやり取りの際は直接データの発行元への問い合わせをする形式が取られてきました。例えば、OpenID Connectを利用したID連携などです。これは、今後、様々な資格情報を様々な企業間でオンラインにて手続きするシーンが増えてゆくことを考えると、事業者側にも、ユーザにとっても不便な状態です。そこで、物理カードと同じように、発行元に問い合わせずともデジタルデータの検証ができる仕組みとして考えられたのがVCsです。

VCsの実体は、電子署名が施されたJSONドキュメントですが、物理カードが持つクレデンシャル情報と同じ内容を表現することができます。前回の記事で紹介したDIDsと組み合わせることで、発行元への問い合わせ・システム間でのデータ連携が不要になるため、資格証明の永続性と相互運用性が担保され、自己主権型ID(SSI)の実現が期待されています。具体的には、万が一証明書の発行元がつぶれたとしても、署名を検証するための情報が分散台帳上に公開されている限り、管理主体（発行元）に依存しない形で、データの真正性を検証できます。この特徴により、サービスを利用する個人が、発行した資格情報を自身で保管・任意のタイミングで提示することができるので、SSIの実現手段の１つとしてDIDs＋VCsが期待されています。

VCsの発行～検証の仕組み

VCsの発行～検証の仕組みについて、W3Cの標準化仕様を元に紹介します。なお、Verifiable Credentials Data Model v1.1ではデータモデルのみ定義され、暗号化手法や通信プロトコルについては未定義となっています。

まず、この仕組みにおける資格情報の流通形態をまとめた図が以下です。登場人物として、発行主体をIssuer、提示先をVerifier、所有者をHolderと呼称します。前提として、それぞれが特定のIdentifier（識別子）など検証可能な属性を持ち、Verifiable Data Registry（検証可能な資格情報を格納するレジストリ）に保管します。詳細は後述しますが、やり取りする情報データに、識別子などの属性を含めた署名とその検証を行うことで、資格情報の発行/提示時の真正性確認を行います。本記事では、識別子としてDIDsを用いたVCsの発行～検証を説明します。

Tech Blog komatsu VCs 01 — VCsのエコシステム概略図
https://www.w3.org/TR/vc-data-model/#ecosystem-overview

VCsの流通を実際の例に置き換えると、以下の図のようになります。
〇×大学に在籍中の花子さん（仮名）が大学に学生証（VCs）を発行してもらい、それを映画館に提示して学割サービスを受ける、というシナリオを思い浮かべてください。
このとき、Holderが花子さん、Issuerは〇×大学、Verifierは映画館にあたります。まず花子さんは、〇×大学から学生証VCsを発行してもらい、ウォレット^※にそれを格納します。VCs入手後は、ウォレットを介して、映画館へ学生証VCsを必要なタイミングで提示することができます。映画館は、提示された学生証VCsから、花子さんが学生であることを確認します。VCsは、確かに〇×大学が発行したものであり、改ざんされていないことが暗号的に検証できるので、大学に在籍確認をする必要はありません。VCsの提示のみで、花子さんは割引サービスを受けられます。

Tech Blog komatsu VCs 02 — VCsのエコシステム概略図を元に作成した図

※ウォレット…DIDsおよび関連する秘密鍵やその他の機密性の高い情報を安全に保管することができるアプリケーションまたはハードウェア端末。

続いて、VCs発行の具体的な流れとVCsの中身を説明します。
まず初めに、HolderがWalletを介してIssuerに資格情報（＝VCs）の発行を依頼します。Holderが依頼する形式は明確に定められておらず、Issuerが事前に用意しておいたVCs発行用のQRコードを読み取る方法などが提案されています。
IssuerはHolderが資格情報の発行条件を満たしているか確認し、IssuerのDIDsに紐づく秘密鍵で署名したVCsを発行します。Holderは自身のウォレットに発行されたVCsを格納します。
簡易的なシーケンス図で表すと以下のようになります。

Tech Blog komatsu VCs 03 — VCs発行の簡易シーケンス図（筆者作成）

VCsの中身は、電子署名が施されたJSONドキュメントです。３層構造になっており、Credential Metadata、Claim(s)、Proof(s)で構成されます。

Credential Metadata：VCsの種別・発行組織名・発行日時など、資格情報に関するその他の情報
Claim(s)：資格情報本体
Proof(s)：Issuerの公開鍵情報や電子署名などの情報

続いて、VCs発行後、Walletに格納したVCsを提示し、Verifierに検証を受ける流れは以下です。
まず、サービス利用時に、VerifierがHolderに資格情報の提出を求めます。Holder は、Verifier が生成したQRコードを読み取るなどして、Verifierからの資格情報要求を受け取ります。
このとき、Holderは自身の保有するVCsの中から、要求を満たすVCsを選択します。そして、自身のDIDsに紐づく秘密鍵で署名してVerifierに提示します。
VCsを受け取ったVerifierはVCsに含まれるIssuerのDIDsとHolderのDIDsを取得します。
取得したDIDsから、DID Resolverを用いるなどしてIssuer/Holderの公開鍵情報を取得し、VCsのデジタル署名を検証する、という流れです。
こちらも、簡易的なシーケンス図で表すと以下のようになります。

Tech Blog komatsu 04 — VCs提示の簡易シーケンス図（筆者作成）

また、Issuerから発行してもらった複数のVCsを一度にVerifierに提示できるVPs（Verifiable Presentations）という形での提示も規定されています。VPsは、１つ以上のVCsデータを含む電子署名付きJSONドキュメントです。VCsと同様の３層構造となっており、Presentation Metadata、Verifiable Credential(s)、Proof(s)で構成されます。

Tech Blog komatsu 06 — VPの基本構成
https://www.w3.org/TR/VC-data-model/#presentations

VCsとは

VCsの発行～検証の仕組み

VCsのユースケース