検証可能な資格情報 (VCs: Verifiable Credentials) （前編）
【概要】2019年11月19日、W3C (World Wide Web Consortium)からVerifiable Credentials Data Model 1.0 のW3C勧告 (W3C Recommendation)が発表され検証可能な資格情報が標準化されました。分散型アイデンティファイアー(DID)の標準化の3年前のことです。なぜ新しい資格情報 (証明書) が必要になり、それによってこれまで出来なかった何が出来るようになり、その実現のための技術的なイノベーションは何だったのかについて解説していきます。
************** 目次 ****************
【1】物理的な証明書
【2】信頼のトライアングル：発行者、保持者、検証者
【3】VCとDIDの関係
【4】VCのスケーラビリティ
【5】ガバナンスフレームワーク
*************************************
【1】物理的な証明書
検証可能な資格情報(VCs: Verifiable Credentials)はインターネット上の証明書として使われますが、これを理解する第一歩は物理的な証明書（運転免許書、パスポート、卒業証書、社員証、など）の働きを知り、必要となる機能がVCでどのように実現されるかを調べることです。
上図にVCと物理的な証明書の対応を示しましたが、VCには以下の項目と機能が必要です。
① 検証者が必要とする主張内容 (Claims)
② 有効期限などのメタデータ
③ 証明書ID（証明書の識別子）
④ 正規の発行者により発行されていることの証明
⑤ 改竄されていない（改竄が非常に困難である）ことの証明
⑥ 証明書の保持者が証明対象であることの証明
証明書の内容に関する項目①〜③はVCと物理的な証明書で基本的に共通ですが（VCのデータフォーマットについては後述）、④⑤はVCではVC発行者(issuer)の電子署名により、⑥はVCの保持者(holder)の電子署名によって実現されます。暗号を利用することでVCの真正性（発行者の真正性）とインテグリティ（内容が改竄されていないこと）は物理的な証明書より大幅に強化され、また検証のための時間とコストは限りなくゼロになります。
【2】信頼のトライアングル：発行者、保持者、検証者
VCには発行者(issuer)、保持者(holder)、検証者(verifier)が関与し、VCの真正性とインテグリティ⑤〜⑥はこの三者の信頼のトライアングルの上に成り立っています。
· 発行者と保持者の信頼：発行者は保持者が証明書の対象(subject)であることを信頼し(保持者が証明書の対象でないケースについては後述)、保持者は発行者が保持者の資格情報を主張するに相応しい機関・団体・個人であることを信頼する。発行者は保持者が当該資格情報を持つに相応しいこと（例えば社員証VCならば実際に社員であること）について予め把握している。
· 保持者と検証者の信頼：保持者は検証者が資格情報を開示して良い相手であることを信頼する。検証者は保持者が資格情報の対象者であることを保持者のDIDとVC中の対象者のDIDが一致することで確認する。ただし検証者は保持者自身が資格情報を主張できるとは考えていない。
· 発行者と検証者の信頼：検証者はVCの発行者が主張する保持者の資格情報を信頼する。発行者は検証者を知らないのでこの信頼関係は検証者から発行者への一方通行である。
ここで重要なことは、検証者は保持者の資格情報について保持者を信頼しているのではなく発行者を信頼していることです。これは物理的な証明書について、たとえば免許証であれば検証者は免許証の保持者ではなく発行者である都道府県公安委員会を信頼しているのと同じです。
【3】VCとDIDの関係
VCとDIDは独立したW3C標準で互いに依存関係はありませんが、両方を使うことで自己主権型ID (SSI: Self Sovereign Identity)が効果的に実現できます。
上図は信頼のトライアングルの参加者がそれぞれDIDを持ち、DIDに紐づく秘密鍵で発行者はVCに、保持者はVPに署名している状況を表しています。VPは検証可能なプレゼンテーション (Verifiable Presentation)の略で、保持者は一般に複数の発行者から受け取った複数のVCをウォレットに保管し、それらの中から検証者に提示する資格情報を選択し、保持者の署名をつけてVPを構成し、検証者に提示します。
直接コミュニケーションする発行者と保持者、保持者と検証者はメッセージを相手のDIDに紐づく公開鍵で暗号化することでセキュアな通信を行います。発行者と検証者は直接コミュニケーションしませんが、VPに含まれるVCが発行者に署名されており、発行者の公開鍵はDIDドキュメントとしてVDR (Verifiable Data Registry)で公開されているため、検証者は資格情報の真正性とインテグリティを発行者に問い合わせること無く確認できます。物理的な証明書の場合も保持者が使用する度に検証者から発行者に問合せはありませんが、それと同じです。
【4】VCのスケーラビリティ
信頼のトライアングルのところで検証者はVCの発行者を信用して保持者の資格情報を受け入れていることを説明しました。実装としては、検証者は信頼できる発行者のリストを持っていて、保持者から提示されたVPに含まれるVCがリストに載っている発行者の署名付きかどうかを確認することが考えられます。この方法は発行者の数が少ない時は良いですが、エコシステムの拡大に伴い新たな発行者を確認・管理する検証者の負担が増大するためスケーラビリティが問題です。これを解決しないと保持者から提示されたVPが正当な発行者のVCを含んでいるにも関わらず検証者に受け付けられない不都合が生じます。このような問題は信頼のトライアングルを二重化することで解決できます。
上図で上側のトライアングルはこれまで説明してきたもの、下側のトライアングルがVCの発行者を認定するために新たに追加されたものです。この構成で検証者が信頼するのはガバナンスオーソリティです。ガバナンスオーソリティは発行者を認定・登録して、その証としてVCを発行者に送ります。つまりここではガバナンスオーソリティが発行者、発行者が保持者となります。検証者は保持者から提示されるVPに
· 発行者が保持者の資格情報を主張するVC
· ガバナンスオーソリティが発行者の認定済情報を主張するVC
の両方が含まれていることを確認し、保持者の資格情報を受け入れます。これにより検証者はガバナンスオーソリティだけを信頼すれば良く自ら多数の発行者を確認・管理する必要が無くなります。
この二重の信頼のトライアングルは既存の様々なビジネスシステムでも見ることができます。典型的な例はクレジットカードです。多数のクレジットカード発行会社（銀行、信販、旅行会社など）を小売店（検証者）が個別に確認・管理することは不可能ですが、VISAやMastercardなどの決済ブランド運営会社（ガバナンスオーソリティ）がカード発行会社を認定することで問題を解決しています。
【4】ガバナンスフレームワーク
上記説明の図の中でガバナンスオーソリティがガバナンスフレームワークを発行していますが、これはエコシステムを統治するための規約です。多数の参加者からなる人間社会の営みを統治するにはAPIや通信プロトコルを決めるだけでは不十分であり、ビジネス、法律、技術に関する規約を定めることが必要で、これらの頭文字をとってBLTサンドイッチと呼ばれることもあります。それぞれの規約には以下のような項目があります。
· ビジネス(B)：参加資格、参加費、ビジネスモデル、組織運営、等
· 法律(L)：司法管轄、税務、法的責任、知的所有権、等
· 技術(T)：技術標準、プロトコル、ベンダー選定、ユーザビリティ、等
本連載第２回目「Web3におけるアイデンティティレイヤー（後編）」で紹介したToIP(Trust over IP Foundation)スタックの4レイヤーはテクノロジースタックとガバナンススタックの２本柱から成りますが、ガバナンスフレームワークはガバナンススタックに対応しています。
なお非中央集権型のエコシステムにガバナンスフレームワークは不要ではないかと思われるかも知れませんが、非中央集権型だからこそ参加者が合意できるガバナンスが必要なのです。既存の社会システムにおいても力が拮抗した多数の参加者からなるコミュニティほど統治のための規約やその合意プロセスが重要であり、デジタル世界でも同じことが言えます。
以上、検証可能な資格情報 (VC)とその利用について物理的な証明書と対比しながら説明してきました。(中編)ではそのような特徴を持つVC/VPの中身について詳しく見ていきたいと思います。
最後までお読み頂きありがとうございます。
記事へのご意見やご質問などがございましたらお気軽に下記までご連絡ください。
info@kaula-lab.com
カウラ株式会社HP: kaula.jp
（カウラ株式会社はBACEコンソーシアム、MOBIの会員企業です。）
関連記事
· Web3.0におけるアイデンティティレイヤー（前編）https://medium.com/kaula-lab/web3-0-identity-layer-89494f479c14
· Web3.0におけるアイデンティティレイヤー（後編）https://medium.com/kaula-lab/web3-0-identity-layer-2-4632344ec069
· 分散型アイデンティファイヤー (DIDs: Decentralized Identifiers)（前編）https://medium.com/kaula-lab/%E8%A8%98%E4%BA%8B%EF%BC%93-%E5%88%86%E6%95%A3%E5%9E%8B%E3%82%A2%E3%82%A4%E3%83%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%83%A4%E3%83%BC-dids-decentralized-identifiers-%E5%89%8D%E7%B7%A8-9f4f6421bd01
· 分散型アイデンティファイヤー (DIDs: Decentralized Identifiers)（中編）https://medium.com/kaula-lab/%E5%88%86%E6%95%A3%E5%9E%8B%E3%82%A2%E3%82%A4%E3%83%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%83%BC-dids-decentralized-identifiers-%E4%B8%AD%E7%B7%A8-fddbabd7eff1
· 分散型アイデンティファイヤー (DIDs: Decentralized Identifiers)（後編）
