こんにちは。C-VoxelというdAppを開発しているKantaroです。C-Voxelは、オンチェーン上の活動をDIDと紐づけてweb3の個人の職歴として公開できるプロダクトです。

この記事では、C-Voxelとも馴染みの深いVerifiable Credentialsについて勉強していきます。

そもそもCredentialsって何?

まずそもそもクレデンシャル(Credentials)とは何なのでしょうか？直訳すれば資格情報となりますが、クレデンシャルは現代社会では必要不可欠なもので、私たちの生活の中で至るところで活用されています。

例えば運転免許証は、自動車を運転する能力があることを証明します。大学の学位は教育レベルを証明しますし、政府発行のパスポートであれば国籍を証明し国家間の移動をする際に利用されます。

このように、ある発行機関が個人の何らかの資格情報や性質を証明するものがクレデンシャルです。このような従来のクレデンシャルは、Physical Credentialsと呼ばれます。

Physical Credentialsは、以下の6つの要素を持っていると言われています。

1. クレデンシャルの対象者を識別するための情報（例：写真、名前、識別番号など）
2. 発行機関に関する情報（例：市役所、国家機関、認証機関など）
3. クレデンシャルのタイプに関する情報（例：パスポート、運転免 許証、健康保険証など）
4. 発行機関が主張する特定の属性や特性に関する情報（例：国籍、運転可能な車両のクラス、生年月日など）
5. クレデンシャルがどのように導き出されたかに関連する証拠
6. クレデンシャルの制約に関する情報（例：有効期限、使用条件など）

Physical Credentialsは現代社会で生きていくために必要不可欠なものであり、物理的な世界で使用される場合は私たちに利益をもたらしますが、一方で不便な点も多く存在します。

例えば運転免許証や健康保険証は物理的なカードであり、必要な場合は常に持ち歩く必要がありますし、カードを紛失すると悪用される恐れもあります。また例えば学位などは偽装できる可能性もありますし、学位の検証は大学に問い合わせたりとそれなりにコストがかかります。

またお店やオンラインサービスでは身分証明として運転免許証やパスポートの提示を求められることがありますが、多くの場合ではカードそのものを提示するために証明したい内容以上の個人情報まで開示せざるを得ないケースがあると思います。

このようなPhysical Credentialsの不便さを解決するために提唱されているのが、Verifiable Credentialsです。

Verifiable Credentials とは何か？

ここからは、W3Cの策定するVerifiable Credentialsの定義をベースに紹介していきます。2017年にドラフトが作成され、2022年3月に最新版のRecommendationとなっています。

Verifiable Credentialsは、直訳すると検証可能なクレデンシャルとなります。暗号的に安全で、プライバシーを尊重し、システム的に検証可能な方法で Web 上でクレデンシャルを表現する標準的な方法を提供するもの。つまり、内容の検証がオンラインで可能なデジタル個人情報のことを指しています。

Verifiable Credentialsは先述のPhysical Credentialの6つの要素を全て満たしており、加えていくつかのメリットが存在します。

その一つは、デジタル署名などの特徴が追加されることで、改ざん防止性が高く、より信頼できる という点です。偽装がされづらい、ということですね。

また、ゼロ知識証明を組み合わせることで、自分の個人情報を開示することなく、その資格を持っていると証明できるという点も他の利点として良く挙げられます。

ゼロ知識証明については長くなるので別の機会に改めて紹介しますが、もし詳しく知りたいという方はWIREDのこちらの動画もおすすめです。

他には、Verifiable Credentialsはweb上で表現されるため、遠距離で証明を行い信頼を確立したい場合にはPhysical Credentialsよりも便利です。特にweb3の領域ではグローバルな活動が前提となることが多いため、Verifiable Credentialsの普及が特に望まれている領域と言えるかもしれません。

Verifiable Credentialsのエコシステム

では、もう少し具体的にVerifiable Credentials(以下, VC)の仕組みを見ていきましょう。W3Cによれば、個別具体的なケースでは様々なファクターが関わり合いますが、抽象化したエコシステムには5つのコアなアクターが存在すると定義されています。

• 保有者(Holder) : VCの所有者。 1 つ以上のVCを所有し、それらから検証可能なプレゼンテ ーションを生成する。例としては、学生、従業員、およびあるサービスの顧客などがある。
• 発行者(Issuer) : 1 つ以上の対象についてのClaimを行い、ClaimからVCを作成し、 Holderに送信することによってエンティティが果たす役割。発行者の例としては、企業、NPO、業界団体、政府、および個人がある。
• サブジェクト(Subject) : claimの対象となる実体。例えば、人間、動物、物などが含まれる。多くの場合、VCの保有者と同一だが、そうでない場合もある。たとえば、親（保有者）が子供（対象者）の検証可能なクレデンシャルを保持する場合や、ペットの所有者（保有者）がペット（対象者）のVCを保持する場合がある。これらの特殊なケースの詳細については、後述
• 検証者(Verifier) プレゼンテーションを通じて、1 つ以上のVCを検証する役割。検証者の例としては、雇用者、セキュリティ要員、および Web サイトがある。
• 検証可能なデータ・レジストリ(Verifiable Data Registory) システムが、識別子、キー、および他の関連データ（検証可能なクレデンシャル・スキーマ、失効レジス トリ、発行者公開キーなど）の作成と検証を媒介する役割で、VCを使用するために必要な場合がある。構成によっては、対象者に相関可能な識別子を必要とする場合がある。検証可能なデータ・レジストリの例には、信頼できるデータベース、分散型データベース、政府 ID データベース、および分散型台帳が含まれる。エコシステムで利用される検証可能なデータレジストリは、多くの場合、1種類以上ある。

ここで、聞き慣れない新しい概念が出てきました。「検証可能なプレゼンテーション(Verifiable Presentation)」です。これは、下記のように定義されています。

1 つ以上のVCから派生したデータで、特定の検証者と共有されるもの。 ある種の検証可能なプレゼンテーションは、元のVCを含まないが、そこから合成されたデータを含むことがある。例えば、ゼロ知識証明などを利用し、詳細は開示しないが条件を満たしていることを証明することができる。

つまりVCのエコシステムでは、具体的なVCを開示するのではなく、ゼロ知識証明や他のVCを組み合わせて証明したい事柄(または検証可能な証明結果)のみを提示することができるということがお分かりいただけたかと思います。

Verifiable Credentialsの 27 Requirements

さらに上記のVCのエコシステムには、望ましい要件として下記の27要素が挙げられています。

この要件は、エコシステムの各アクターの振る舞いや性質を細かく定義しています。

全部読むのは結構大変だと思うので読み飛ばして構いませんが、眺めておくだけでも、全体像が理解しやすくなると思います。

1. クレデンシャルとは、発行者の意思表示を表すものである。
2. 検証可能なクレデンシャルは、改ざん防止およびプライバシーを尊重した方法で発行者によって作成されたステートメント**を表す。
3. 保有者は、異なる発行者からのクレデンシャルや検証可能なクレデンシャルのコレクションを、単一の成果物であるプレゼンテーションに組み入れることができる。
4. 保有者は、プレゼンテーションを検証可能なプレゼンテーションに変換し、改ざんを防止することができる。
5. 発行者は、あらゆる対象について検証可能なクレデンシャルを発行できる。
6. 発行者、保有者、または検証者として行動する場合、当事者間の信頼に関わるため、いかなる当局による登録や承認も必要としない。
7. 検証可能なプレゼンテーションは、任意の検証者が任意の発行者からのVCの真正性を検証することを可能にする。
8. 保有者は、誰からも検証可能なクレデンシャルを受け取ることができる。
9. 保有者は、任意の発行者および任意の検証者と対話することができる。
10. 保有者は検証可能なプレゼンテーションを共有することができ、検証者の身元を発行者に明かすことなく検証することができる。
11. 保有者はVCを任意の場所に保存することができる。(発行者がその保存場所やアクセスについて何も知る必要はない)
12. 保有者は自由に検証可能なプレゼンテーションを任意の検証者に提示することができる。
13. 検証者は、任意の発行者の主張の証明を含む、任意の保有者からの検証可能な提示物を検証することができる。
14. 検証は、発行者と検証者の間の直接的なやりとりに依存すべきではない。
15. 検証は、検証者の身元をいかなる発行者にも明かすべきではない。
16. この仕様は、発行者が選択的開示をサポートする検証可能なクレデンシャルを発行する手段を提供しなければならないが、適合するすべてのソフトウェアがその機能をサポートすることを要求してはならない。
17. 発行者は、選択的開示をサポートする検証可能なクレデンシャルを発行することができる。
18. 単一の検証可能なクレデンシャルが選択的開示をサポートする場合、保有者は検証可能なクレデンシャル全体を明らかにすることなく、主張の証明を提示することができる。
19. 検証可能な提示は、検証可能なクレデンシャルの属性を開示するか、検証者が要求する派生述語を満 たすかのいずれかである。派生述語は、より大きい、より小さい、等しい、集合の中にある、などのブール条件**である。
20. 発行者は、取り消し可能な検証可能クレデンシャルを発行できる。
21. クレデンシャルとプレゼンテーションを暗号的に保護するプロセス、および検証可能なクレデンシャルと検証可能なプレゼンテーションを検証するプロセス**は、決定論的、双方向的、およびロスレスでなければならない。検証可能なクレデンシャルまたは検証可能なプレゼンテーションの検証は、決定論的プロセスでこの文書で定義された汎用データ・モデルに変換可能でなければならず、その結果生じるクレデンシャルまたはプレゼンテーションが元の構成と意味的および構文的に等しくなり、相互運用方式で処理できるようにしなければならない。
22. 検証可能なクレデンシャルおよび検証可能なプレゼンテーションは、1 つ以上の機械読取可能なデータ・フォーマットで直列化可能でなければならない。シリアライズおよび／または非シリアライズのプロセスは、決定論的、双方向的、かつロスレスでなければならない。検証可能なクレデンシャルまたは検証可能なプレゼンテーションのシリアル化はすべて、 決定論的プロセスでこの文書で定義された汎用データ・モデルに変換可能でなければならず、その結果 生じる検証可能なクレデンシャルは相互運用可能な方法で処理できるようにしなければならない。シリアル化された形式は、データまたはコンテンツの損失なしにデータ・モデルから生成できる必要がある。
23. データ・モデルおよびシリアライゼーションは、最小限の調整で拡張可能でなければならない。
24. 発行者による取り消しにあたり、対象者、所持者、特定の検証可能なクレデンシャル、または検証者の識別情報は一切明らかにすべきではない。
25. 発行者は、取り消しの理由を開示**することができる。
26. 検証可能なクレデンシャルを取り消す発行者は、暗号的完全性（たとえば、署名鍵が危殆化した場合） のための取り消しと、状態変化（たとえば、運転免許証が停止された場合）のための取り消しを区別する必要がある。
27. 発行者は、検証可能なクレデンシャルを更新するためのサービスを提供できる。

まとめ

ここまでW3Cの定義をベースとしながら、Verifiable Credentialsとは何かについてご紹介してみました。本記事はあくまで導入部分なので、より詳細な仕組みやシステムの話は、次回記事にてまたまとめる予定です。

昨今のweb3の盛り上がりを受けVerifiable CredentialsやDIDについて耳にすることも増えてきましたが、原点の定義から改めて学んでみることで、個人的にも理解が深まってきたように感じます。専門用語も多く長くて読みづらい部分も多かったかと思いますが、全体像のイメージだけでも掴めていただければ幸いです。

個人的にはVerifiable CredentialsやDIDといった領域は私たちの生活と密接に関わる部分であり、将来的にはDefiやNFT以上に、今後多くのベネフィットを私たちにもたらすものだと考えています。C-Voxelというプロダクトに全力で取り組んでいるのも、そのような未来を実現したいという想いに依るものです。もしご興味を持っていただければ、ぜひTwitterやDiscordに遊びにきてください。

Twitter: https://twitter.com/C_Voxel

Discord: https://discord.gg/TBJFmJv6uZ

この続きは下記の第二回目にまとめています！