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

この記事では、C-Voxelとも馴染みの深いVerifiable Credentialsについて勉強していきます。今回は、Verifiable Credentialsのデータモデルについての前編です。前回の記事はこちらからご覧ください。

用語の説明

データモデル概念に入る前に、まずは必要な用語を紹介します。記事を読んでいて分からない単語が出てきたら、こちらを読み返してください。また以下本記事では、検証可能なクレデンシャルを「VC」と表記します。

• クレーム(Claim): ある対象(Subject)についてなされる主張のこと。
• クレデンシャル(Credential): 発行者によってなされる1つ以上の**クレーム(Claim)**のセット。中でもVCとは、暗号学的に検証できる発行者を持つ、改ざん不可能なクレデンシャルである。VCは、検証可能なプレゼンテーションを構築するために使用することができ、これも暗号的に検証することができる。クレデンシャル内の主張は、異なる対象に関するものであってもよい。
• 発行者(issuer): 1 つまたは複数の対象についてのクレーム(Cliam)を行い、VCを作成し、保有者に送信する。
• 保有者(holder): 1 つ以上のVCを所有し、そこからプレゼンテーションを生成する。保有者は通常VCの対象とイコールだが、常にそうであるとは限らない。保有者はクレデンシャル・リポジトリにそのVCを保管する。
• 対象(Subject) 主張の対象となるもの。通常はVC保有者と同一
• 検証者(verifier): 1 つまたは複数のVCを受け取り検証する
• 検証(verification): 検証可能なクレデンシャルまたは検証可能なプレゼンテーションが、それぞれ発行者または提 示者の真正かつタイムリーな声明であるかどうかを評価すること。これには、クレデンシャル（またはプレゼンテーション）が仕様に適合していること、証明方法が満たされていること、および存在する場合はステータス・チェックが成功することを確認することが含まれる。クレデンシャルの検証は、クレデンシャルにエンコードされた主張の真偽の評価を意味するものではな い。
• プレゼンテーション(presentation): 1 つ以上のVCから派生したデータで、特定の検証者と共有されるもの。検証可能なプレゼンテーションの特徴の一つは、暗号的検証プロセスを経て符号化され、改ざんが明白であること。 ある種の検証可能なプレゼンテーションは、元のVCを含まないが、そこから合成されたデータを含む。
• 派生述語(derived predicate): VC内の別の属性の値に関する、検証可能なbool値のアサーション。これらは、情報の開示を制限できるため、ゼロ知識証明スタイルの検証可能なプレゼンテーションで有用である。たとえば、VCに特定の身長をcm単位で表す属性がある場合、派生述語はVC内の身長属性を参照して、身長値を実際に開示することなく、例えば、対象者の身長は 150 cmより高いので最低身長要件を満たす身長値を保証する、ということを示すことができる。
• 分散型識別子(decentralized identifier): DIDとも呼ばれる、あるエンティティに関連付けられたポータブルなURLベースの識別子。これらの識別子は、VCで最も頻繁に使用され、VC自体 がクレデンシャルを再発行する必要なしに、あるリポジトリから別のリポジトリに簡単に移植できるように、対象者に関連付けられる。DID の例は、did:example:123456abcdef である。
• 分散型識別子文書(decentralized identifier document): DID文書とも呼ばれ、検証可能なデータレジストリからアクセス可能な文書で、関連するリポジトリや公開鍵情報など、特定のDIDに関連する情報を含んでいる。
• グラフ(graph): 主体および他の主体やデータとの関係から構成される情報のネットワーク。
• リポジトリ(repository): 保有者のVCを保管および保護するプログラム。
• 検証可能なデータ・レジストリ(verifiable data registry): 識別子、キー、およびVCのスキーマなど、VCを使用するために必要な関連データの作成と検証を仲介するプログラム。
• 選択的開示(selective disclosure): どの情報を共有するかについて、保有者がきめ細かく決定する能力。

データモデル

ここからはデータモデルの概要を説明します。

Claim

クレームとは、対象(通常は保有者)の資格や状態など証明したい内容を主張することです。対象-プロパティ-値の関係を使って表現されます。

上図のクレームのデータモデルは強力で、多種多様な記述を表現することができます。例えば、ある人が特定の大学を卒業したかどうかは、以下のように表現できます。Pat(対象)が、ある大学(値)の卒業生(プロパティ)である、ということを示しています。

また個々のクレームを統合すると、情報のグラフとなります。例えば、PatがSamを知っている(プロパティ=knowledge, 値=sam)，Samが教授として働いている(プロパティ=職業, 値=教授)，というクレームを追加することでグラフとなり、最初の主張を拡張することができるのです。

Verifiable Credentials

さて、ようやく本題のVCです。VCには、メタデータ、クレーム（複数可）、プルーフ(複数)の3つの要素が含まれています。

メタデータは、VCの発行者や有効期限、証明事項の属性などのデータです。クレームは上述のように証明したい内容で、プルーフは、VC発行者によるデジタル署名が含まれています。より詳細に図示したものが下記となります。この3点セットが、VCの実体となります。

上記は簡略図ですが、実際のVCの中身としては、下記のようなデータモデルとして表されます。こちらはあくまで簡単な例ですが、DIDに紐づいてalumniOfというプロパティがCliamされているのが分かるかと思います。

{
  // set the context, which establishes the special terms we will be using
  // such as 'issuer' and 'alumniOf'.
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // specify the identifier for the credential
  "id": "http://example.edu/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "AlumniCredential"],
  // the entity that issued the credential
  "issuer": "https://example.edu/issuers/565049",
  // when the credential was issued
  "issuanceDate": "2010-01-01T19:23:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // identifier for the only subject of the credential
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // assertion about the only subject of the credential
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // digital proof that makes the credential tamper-evident
  // see the NOTE at end of this section for more detail
  "proof": {
    // the cryptographic signature suite that was used to generate the signature
    "type": "RsaSignature2018",
    // the date the signature was created
    "created": "2017-06-18T21:19:10Z",
    // purpose of this proof
    "proofPurpose": "assertionMethod",
    // the identifier of the public key that can verify the signature
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

Verifiable Presentation

一方で上記を見ると分かるように、VCには個人情報が含まれています。例えば、大学卒業済である証明をしたい場合、どこの大学を卒業したのか、という情報は過剰な情報です。また、逆に転職活動をして履歴書を作成する時には、卒業大学だけでは不充分であり、学位の専攻や、運転免許証などのVCが必要になるかもしれません。

このように与えられた状況に適したペルソナの一部分のみを表現することは、Verifiable Presentation(検証可能なプレゼンテーション)と呼ばれます。ペルソナの例としては、仕事上のペルソナ、オンラインゲーム上のペルソナ、家族としてのペルソナなどがあります。

Verifiable Presentationは、メタデータ、VC(複数可)、プルーフ(複数可)から成っています。1つまたは複数のVCが一つのペルソナを表し、そのペルソナの証明を表現しています。

下記はより詳細な図解です。VCが一つあり、そのVCに対するVerifiable Presentationのメタデータとプルーフを持っていることが分かります。

また下記には例示されていませんが重要な点としては、このVerifiable Presentationに含まれるVCsは、ゼロ知識証明などを用いることで、全ての情報を開示しなくても証明することができるということです。こちらについてはまた次回以降の記事でご紹介します。

まとめ

如何でしたでしょうか。前回に引き続きW3Cの定義をベースとしながら、Verifiable Credentialsのデータモデルの概念についてご紹介しました。VCは実際には直接利用されるわけではなく、Verifiable Presentationという形に変換されて検証される、ということだけでも覚えていただければ幸いです。

次回以降はJSON形式のデータモデルや高度な利用例など、より詳細な記事をまとめて公開できればと思います。

本業のC-Voxelの開発も全力で取り組んでいますので、ぜひご興味をお持ちいただけたらTwitterやDiscordに遊びにきてください。

Twitter: https://twitter.com/C_Voxel

Discord: https://discord.gg/TBJFmJv6uZ