Ava Labs JPテックブログPublicationへの投稿
🪪

Verifiable Credential（検証可能な資格証明）の概要

hiro
に公開
ブロックチェーン
VC
did
W3C
tech

はじめに

昨今のブロックチェーンや分散型ID（DID）技術の発展により、安全に発行・利用できるデジタル証明書の仕組みが注目されています。
その中核となる概念がW3C標準で定義されているVerifiable Credential（VC）です。
本記事では、W3Cが発表しているVerifiable Credentials Data Modelというドキュメンテーションをもとに、VCの仕組みやデータ構造、そして実際にどのようにして発行・利用されるかを解説します。

検証可能な資格証明とは

まずVerifiable Credential（VC）とは検証可能な資格証明と定義されています。
もう少し詳しく説明すると、発行者（Issuer）が対象者・ユーザー（Subject）について行った主張（Claim）を、暗号的に署名して検証可能にする仕組みです。
大学の卒業証明書や会社の社員証、運転免許証など、今までは紙で存在していたものを、暗号技術を使ってデジタル化した形式と考えると理解しやすいでしょう。
簡単に言い換えると、従来の物理的な証明書をデジタル上で安全に再現したものです。

特徴:

  • 発行者のデジタル署名により、改ざん検知が可能。
  • 保有者は、VCを基にVerifiable Presentation（VP）を生成し、特定の検証者に対してのみ必要な情報を提示できる。
  • オープンスタンダードとしてW3C Verifiable Credentials Data Modelで定義されている。

従来の証明方法とは何が違うの？

従来型のデジタル証明は、中央集権的なシステムに依存しており、利用者が「何を、誰に、どの範囲まで見せるか」を柔軟に制御することはできません。
現在の多くのデジタル証明システムは、紙の証明書をそのまま電子化したにすぎず、データがオンラインで扱われているだけで、情報の開示範囲を選択的に制御する仕組みは存在しません。
つまり、ユーザーは自分の情報をどの範囲まで、誰に提示するかを細く制御することができず、認証のたびに、必要以上の個人情報が相手に渡ってしまうこともあります。

たとえば、コンビニでお酒を買う際に店員から年齢確認を求められたとします。
このとき本来必要なのは「20歳以上である」という事実だけのはずですが、現実には運転免許証を提示することで、氏名・住所・生年月日など、本来見せる必要のない情報まですべて開示してしまうことになります。

コンビニのような場面であればまだしも、これがもしオンライン上での本人確認や資格証明など、よりセンシティブなデータを扱う場面で繰り返されるとしたらどうでしょうか。

VCはこの構造を根本から変えることができます。
発行者のデジタル署名によって改ざんを防ぎつつ、保有者自身が「どの情報を、どの相手に、どの範囲で提示するか」を選択的にコントロールできる仕組みを持っています。

同じ場面をVCで例えて考えると、店員に提示するのは「この人は20歳以上である」という事実だけ。氏名や住所など、この取引で不要な情報は一切開示されません。それでも、店員は暗号的に「確かにこの人は20歳以上である」ということを第三者を介さずに検証することができます。

つまりVCは、情報の真正性を担保しながらも、「必要なときに、必要な範囲の情報だけを安全に共有できる」という、これまでの証明方法とはまったく異なるアプローチを実現しているのです。

Verifiable Presentationとは

ここで一度Verifiable Presentation（VP）について触れておきます。
VPとは、1つまたは複数のVCから生成された提示データのことを指します。
保有者が検証者にVCを提示する際に用いられ、必要最小限の情報のみを特定の検証者に対して共有することができます。
これにより、証明の真正性を保ちながら個人情報の過剰開示を防ぎ、安全に証明を行うことができます。
先ほどのコンビニの例で例えると、実際に定員に提示する年確用のデータ部分に当たります。

特徴:

  • 1つまたは複数の発行者によるVCを含む
  • 改ざん検知可能であり、暗号的に真正性が検証可能
  • オリジナルのVCを直接含まず、そこから派生したデータのみを含む場合もある

用語と登場人物

VCのユースケースやデータ構造を解説する前に、いくつかの重要な登場人物と用語を押さえる必要があります。

登場人物

役割 説明 例
Issuer（発行者） 証明書を発行する主体。発行および廃止、訂正することができる 大学、企業、政府など
Holder（保有者） 証明書を受け取り、保持し、必要に応じて提示する主体。発行者から証明書を受け取る側 個人、Walletサービスなど
Subject（発行の対象者） 発行対象となる人物や組織。保有者と同一になる場合もある 個人、企業など
Verifier（検証者） 提示された証明書を検証する主体。 採用企業、サービス提供者など

用語

役割 説明
Claim（主張） 発行者が主体に対して行う主張。例：「この人物はA大学を卒業した」
Credential（資格証明） 複数のClaimをまとめたデジタル証明書
Presentation（提示） 保有者が検証者に対して行う、資格証明の提示行為
Proof（証明情報） 暗号署名など、真正性を担保する情報
Repository（保管庫） Holderが自身のVCを保存するための安全なストレージ

VCとVPのデータ構造

概要と用語などを説明したので、次に実際のVCとVPのデータ構造を見ていきましょう。
下記にそれぞれの構成要素と、実際のデータ型サンプルが載せてあります。

Verifiable Credentialのデータ構造

VCは主にメタデータと主張、証明情報で構成されています。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "did:example:6fb1f712ebe12c27cc26eebfe11",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://subject.example/subject/3921",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2021-11-13T18:19:39Z",
    "verificationMethod": "https://university.example/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
  }
}

Verifiable Presentationのデータ構造

VPは主にメタデータと提示対象のVC群、証明情報で構成されています。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{ ... }],
  "proof": { ... }
}

エコシステムの全体像と機能

次に、実際にそれらがどのように発行・提示・検証・管理されるのか、エコシステム全体の流れを見ていきましょう。
各登場人物の役割を図にすると下記のようになります。

図を簡単に説明すると、発行者（Issuer）が証明を発行し、保有者（Holder）がそれを安全に保持・提示し、検証者（Verifier）が独立的にその真正性を確認できるという仕組みです。

  1. Issue Claim（発行）:

    • 発行者（Issuer）が、対象者（Holder）に対してVCを発行するプロセス。
    • 発行者は、特定の主張（Claim）を暗号的に署名することで、改ざん不可能な証明を作成。
    • 要件としては、発行者が信頼できる形式で署名を行い、VCを安全に生成できる仕組みを持つことが求められる。

  2. Assert Claim（提示）:

    • 保有者（Holder）が、検証者（Verifier）に対してVCを提示するプロセス（提示されるのは、VCそのものではなく、そこから生成されるVP）。
    • 保有者は提示する情報を必要最小限に制御でき、不要な属性を開示せずに検証要件を満たすことができる。
    • VPに対して有効期限の設定も可能。

  3. Verify Claim（検証）:

    • 検証者側が受け取ったVPに含まれるデータの真正性を確認するプロセス。
    • 具体的には、発行者の署名が有効であるか、発行者および対象者のDIDが正しく存在するかを検証する。
    • 自動的に実行できるのが必須条件。

  4. Store / Move Claim（保存・移動）

    • VCの保管先
    • 必要に応じてリポジトリ間でVCを移動することができる。
    • 移動する際にIssuer側から再発行を必要としない仕組みが必要

  5. Retrieve Claim（取得）

    • 定時のために保有者側がリポジトリからVCを取得するプロセス。
    • 提示の際にどのVCを使用するか、どの属性を開示するかを保有者自身が選択できる必要がある

  6. Revoke Claim（失効）

    • 発行者が特定のVCを無効化するプロセス。
    • 無効化されたVCは、以後リポジトリや他のシステム機能で利用できなくなり、VCとしての効力を失う。

VCの発行と利用

最後にVCの発行フローと利用フローの例をシークエンス図をもとに解説します。

本記事では、VCの主張対象と保有主体が同一である前提の場合、図中のユーザーは Subject/Holder を兼ねるものとし、エージェントはそのユーザーの代理で通信・署名・保存・提示を行うアプリケーションを指します。

VCの発行フロー

  1. ユーザーがエージェントにVC発行を依頼する
  2. エージェントが発行側（Issuer）に接続し、本人確認を実施
  3. 発行側（Issuer）が本人確認情報を検証
  4. 検証完了後、発行側（Issuer）がVCを生成しユーザーに送信
  5. ユーザーが内容を確認し、リポジトリに保存
  6. リポジトリが保持中のVC一覧を返却

VPの利用フロー

  1. ユーザーがWebサイトやサービス（Verifier）にアクセス
  2. サービス側（Verifier）が年齢確認などの証明を要求
  3. エージェントがリポジトリに対応VCを照会
  4. ユーザーが提示するVCを選択
  5. リポジトリが選択されたVCをVPとして生成しサービス側（Verifier）へ送信
  6. サービス側（Verifier）が署名と内容を検証し、要件を満たすか確認

まとめ

Verifiable Credential（VC）は、発行者が対象者について行った主張（Claim）を暗号署名で担保したデジタル証明であり、Verifiable Presentation（VP）はそのVCから保有者が必要最小限の情報だけを取り出して検証者（Verifier）に提示するためのパッケージです。
紙の証明書の単純な電子化とは異なり、第三者に依存せずに真正性を自動検証でき、過剰な個人情報の開示を避けられる点が本質的な価値と言えます。

今回はVCについての全体像の整理に留めました。次回はW3CのVerifiable Credentials Data Model v2.0のAdvanced Conceptsを深掘りしていこうと思います。

参照：
https://www.w3.org/TR/vc-data-model/

Ava Labs JPテックブログ
Ava Labs JPテックブログPublication

Discussion