DID/VCはなぜ生まれたのか。Webの本人確認からEthereum、国際標準まで【前編】

ZenChAIne·2026年9月18日

DIDVCEthereum

はじめに

転職先から卒業証明書の提出を求められ、大学に発行を依頼する。別の会社との取引では、すでに提出した資格証をもう一度送る。書類をPDFにできても、受け取った相手が発行元や有効性を確かめる手間は残る。

インターネットでは、遠くの相手に情報を届けることは簡単になった。しかし、「誰が、誰について、何を確認したのか」を、別の組織でも確かめられる形で受け渡すには、まだ多くの取り決めが要る。DIDとVCは、その問題に取り組むために育ってきた技術である。

DIDは Decentralized Identifier、分散型識別子 の略で、人や組織などを指すIDの仕組みだ。VCは Verifiable Credential、検証可能な資格情報 の略で、卒業や資格、所属といった情報を、発行元や改ざんの有無を検証できる形で表す。ここでいう資格は、国家資格だけを意味しない。基本仕様を作るW3Cと、関連する手順を整える標準化団体の活動によって、異なるサービスの間でも識別情報や証明を扱うための共通ルールが作られてきた。

以前、ZennではEthereumのID関連の提案を、技術を知る読者に向けて紹介した。Ethereumは、スマートコントラクトと呼ぶプログラムを実行できるブロックチェーンである。本稿はその歴史を含め、DID/VCを初めて読む人にも背景から追えるように書き直したものだ。

前編では、規格を作る団体と、その背景にある自己主権型アイデンティティの思想をたどり、Ethereumでの試みからDID/VCの具体的な仕組みへ進む。仕様と公開資料の確認日は2026年9月17日である。

この記事のポイント

DID/VCが扱うのは、サービスをまたいだ識別や証明の受け渡しである。その背景には、利用者が自分の情報の管理や提示を選べるようにするSSIの思想がある。
W3CはWebの共通仕様を策定する国際的な非営利団体だ。DIDとVCの基本仕様を標準化しているが、発行者の審査や証明内容の保証を一括して行う団体ではない。
Ethereumでは、ID用コントラクト、共有レジストリ、複数アドレスの統合などが試みられた。一方、DID/VC全体はブロックチェーンを必須にしていない。
基本仕様、証明の形式、発行・提示の手順、受け入れルールは、それぞれ別に確かめる必要がある。

W3Cとは何者で、標準化団体は何をしているのか？

W3Cは、World Wide Web Consortiumの略で、Webの共通仕様を策定する国際的な非営利団体である。 1994年にWebの考案者Tim Berners-Leeが設立し、企業、研究者、技術者などが参加している。会員一覧には、Google、Apple、Microsoft、Amazonといった企業に加え、欧州原子核研究機構（CERN）も名を連ねる。ブラウザやWebサービスを開発する企業、研究機関などが、共通の仕様を議論する場である。

W3Cが策定してきたものは、私たちが毎日使うWebに直結している。たとえば、ページの見出しや段落などの構造を表すHTML 4.01、文字の色や配置などの見た目を指定するCSS、障害のある人を含めてWebの情報を利用しやすくするための指針WCAG（Web Content Accessibility Guidelines）がある。異なるブラウザでページを読み、画面読み上げなどを使って情報にアクセスできるWebは、こうした共通仕様と、それを実装する各社のソフトウェアによって支えられている。なお、HTMLの現在の仕様であるHTML Living StandardはWHATWGが維持しており、W3Cは2019年の合意に基づいて協力している。

異なる会社のソフトウェア同士でも同じ情報を扱えるよう、文書の構造や処理方法を共通化する。その活動の一部として、DIDやVCの基本仕様が整えられてきた。W3Cは政府機関でも、世界中の本人確認を引き受ける認証局でもない。

「W3Cに文書がある」と「標準になった」は違う

W3Cでは、草案を公開して検討を進め、所定の手続きを経た仕様をRecommendation、日本語で「勧告」として公開する。一方、Community Groupは提案や実験を進める場であり、その文書すべてが勧告になっているわけではない。

DID/VCの周辺では、Credentials Community Groupも、証明の作成・保管・提示・検証に関する提案を扱ってきた。DID Coreという基本仕様が勧告になっていても、個別のDIDメソッドがすべてW3Cの勧告になったとは言えない。仕様を引用するときには、文書名だけでなく版と策定段階も確認したい。

W3C以外の団体は何をしているのか？

デジタル証明には、データの形だけでなく、発行や提示の手順、署名の方式、端末同士のやり取りも必要だ。そのため、複数の団体が別の部分を担当している。

団体	これまでに策定した主な規格・仕様	この分野で関係する仕事	読むときの注意点
W3C	HTML 4.01（ページの構造）、CSS（見た目）、WCAG（アクセシビリティの指針）	DIDやVCの基本的なデータモデル	勧告と検討中の文書を区別する
OpenID Foundation	OpenID Connect：別のサービスで行った認証の結果を受け取り、ログインに使うための仕様	ウォレットへの証明発行や、相手への提示の手順	データ形式とは別に、やり取りする手順の対応が要る
IETF	HTTP（Webの通信）やTLS 1.3（HTTPSなどで使う通信の暗号化）	インターネット技術の仕様。証明の一部だけを開示する方式など	RFCになった仕様とInternet-Draftを区別する
DIF	Presentation Exchange：相手に求める証明の条件と、それに応じて提示する証明を表すデータ形式	Decentralized Identity Foundation。識別技術の仕様や参照実装、相互運用の開発	W3Cと同じ組織ではなく、取り組みごとに成果物が異なる
ISO/IEC	ISO/IEC 27001：組織が情報セキュリティを管理する仕組み（ISMS）の要求事項	国際標準化機構と国際電気標準会議。モバイル文書の規格など	Web由来のVCと同じ形式だとは限らない

たとえば、OpenID Foundationの証明発行仕様は、発行者からウォレットへ証明を渡す手順を扱う。DIFは、DIDに関する仕様や開発実装を進める。これらは一つの組織の製品一覧ではなく、組み合わせて使う技術群である。

共通の仕様を作る団体があっても、何を証明したいのか、誰がその情報を管理すべきかは別の問いである。その背景を、私たちが普段使うログインと証明書のやり取りから考えてみたい。

なぜ、ログインできるだけでは足りなかったのか？

ログインで確認できるのは、アカウントを利用するための条件を満たしているかどうかだ。別の組織が認めた資格を示すことや、その識別情報を利用者自身が管理できることは、別の問題である。たとえば研修会社のサイトに入れても、そのアカウントを見た採用企業が「この人は試験に合格した」と判断できるわけではない。

企業が発行するアカウントや、別のサービスのアカウントでログインする仕組みは、今も有用だ。社内システムで従業員を認証するなら、会社がアカウントを管理することには合理性がある。DID/VCが登場したから、こうした方法をすべて置き換えるという話ではない。

困るのは、証明を使う場所が発行元の管理範囲を越えるときだ。研修会社、受講者、採用企業の間で共通の確認方法がなければ、PDFの目視、メールでの問い合わせ、企業ごとの接続開発などが必要になる。

電子署名付きの文書やAPIでも、この問題の一部は解決できる。ただ、受け取るたびに書式や接続方法が違えば、相手が増えるほど個別対応も増える。機械で処理できるデータ構造と、発行元を検証する方法を共有しようというのが、VCの基本的な発想である。W3Cが2019年にVC 1.0を勧告した際の説明も、免許証や学位など、現実の証明をWeb上で扱うことを出発点にしている。

もう一つの問題が、情報を渡しすぎることだ。年齢条件を満たすか確認したいだけなのに、住所を含む身分証の画像まで送る。証明をデジタル化するなら、必要な情報だけを渡せないかという要求も生まれる。

必要な情報だけを渡すには、どの項目を切り分けて発行し、どの暗号方式で提示し、相手が何を要求するのかまで設計する必要がある。VCという形式の採用だけでは、開示の範囲は決まらない。データが扱いやすくなるほど、大量収集も容易になるからだ。

使える場所が増えても、管理する権限は誰にあるのか？

GoogleやAppleなどのアカウントで別のサービスへログインする方法を思い浮かべると、もう一つの問題が見える。サービスごとに認証情報を管理する負担は減るが、元のアカウントを管理するのは提供元である。利用者が別の提供元へ移りたいと思っても、同じ識別情報と、それを使うサービスとの関係を、そのまま移せるとは限らない。

この違いを研修の例に重ねてみよう。仮に受講サイトのアカウントが使えなくなったとしても、その人が研修を修了した事実まで消えたわけではない。修了したという証明を自分で持ち、別の相手に示せるなら、元のサイトへログインできることだけに利用を依存させずに済む。

ここまでには、発行元の外でも資格を証明したいという要求と、識別情報や証明の利用を特定のサービスだけに依存させたくないという要求がある。後者を、情報を管理する権限の問題として考えてきたのが、SSIの議論である。

SSIは、どのような経緯で生まれたのか？

SSIはSelf-Sovereign Identity、日本語では自己主権型アイデンティティと呼ぶ。利用者が自分の識別情報や証明の管理に関与し、どこへ何を提示するかを選べるようにする考え方だ。一つの規格の名前ではなく、複数の技術や運用で実現を目指す設計思想である。

その背景には、企業やサービスの提供元にIDの管理権限が集中し、利用者が自分の情報を持ち出したり、別の場所で使い続けたりしにくいことへの問題意識がある。提供元が管理するアカウントを使うだけでなく、利用者自身が識別情報や証明を持ち運べるようにしたい。SSIは、こうした中央集権型のID管理を問い直す議論から育ってきた。

サービスごとのアカウントから、認証の共有へ

初めにあるのは、各サービスが利用者を登録し、そのアカウントを管理する方式だ。複数のサービスを使う人にはアカウントが増え、それぞれの提供元が利用や停止の条件を決める。そこで、ある組織での認証結果を別のサービスでも受け入れる、フェデレーションと呼ぶ連携方式が広がった。

Christopher Allenは2016年の「The Path to Self-Sovereign Identity」で、集中管理、組織間の連携、利用者中心の設計、SSIという流れからIDの歴史を振り返っている。この整理では、使えるサービスを増やしても、管理権限が提供元に残るという問題が続く。なお、これは議論の流れを理解するための整理であり、古い方式が順に使われなくなったという意味ではない。

2000年代に議論された、利用者の同意と選択

2005年にKim Cameronが発表した「The Laws of Identity」では、利用者の制御と同意、必要最小限の情報開示、複数の運営者や技術の共存などを原則として挙げている。一社のIDを全員に使わせれば解決するという前提を置かず、異なる用途や組織の条件を認めた上で、共通の仕組みを考えようとした議論だ。

この時期に進んだ利用者中心のIDの取り組みには、OpenIDもある。OpenID Authentication 2.0の仕様は、持ち運びができる利用者中心のデジタルIDを目的に掲げ、利用者が認証の提供元を選べるようにしている。GoogleやAppleのような巨大な事業者だけがIDを提供できる、という発想から始まった仕様ではない。

とはいえ、提供元を選べることと、選んだ提供元に依存せず使い続けられることは違う。認証を毎回その提供元に依頼する構成なら、提供元が利用できなくなったときの影響は残る。利用者の同意を取るだけでなく、利用を継続するために何を自分で保持できるのか、という問いが出てくる。

SSIとして整理された、利用者による制御

Allenは2016年の文章で、それ以前の議論を踏まえ、利用者による制御、持ち運び、相互運用、同意、必要最小限の開示などの原則を整理した。2016年をSSIが突然発明された年とするよりも、積み重なってきた要求を言葉にした節目と捉える方が実態に近い。

たとえば大学が学位を発行し、卒業生がその証明を受け取り、必要な相手に示す。SSIの考え方では、発行元の外へ持ち出せることや、提示する情報を本人が選べることを重視する。「自分で管理する」からといって、学位や資格を自分で認定してよいという意味ではない。発行する権限と、保管・提示する自由を分けるところに意味がある。

DIFのFAQも、SSIの原則には技術だけでなく、人の価値観や社会の仕組みに関する要求が含まれると説明している。秘密鍵を利用者に渡すだけで、すべての要求を満たせるわけではない。端末の紛失、代理人による管理、法的な本人確認なども扱い、利用者の管理と事業者の責任を具体的に決める必要がある。

なぜ、SSIとブロックチェーンは結び付いたのか？

SSIとブロックチェーンには、特定の運営者だけに依存せず、利用者が鍵を使って操作できるという思想上の接点がある。さらに、鍵や管理権限の変更を共有の履歴として残せることが、IDを実装する上でも役立つ。この二つが、両者を一緒に語る理由になる。

自分で鍵を持ち、サービスを越えて利用する

パブリックなブロックチェーンでは、利用者が自分で鍵を作り、対応するアカウントから操作を要求できる。アカウントを利用者に発行する一社を置かず、同じアカウントを複数の対応アプリケーションで使う構成も取れる。この性質は、識別情報を一つのサービスの外でも使いたいというSSIの要求と相性がよい。

Ethereumには、スマートコントラクトと呼ぶプログラムを動かす仕組みもある。鍵で操作できることに加えて、誰に権限を与え、どの条件なら変更できるかをプログラムで扱える。Ethereumの分散型IDの解説でも、鍵による制御と、識別子や証明を扱う仕組みを説明している。

共有する履歴を、誰が書き換えられるのか？

IDの制御に使う鍵が変わったとき、検証する側には、どの変更が正当かを確かめる手掛かりが要る。ブロックチェーンでは、ネットワークのルールに従った変更を記録し、複数の参加者が履歴を検証できる。単一の事業者が管理するデータベースだけを参照する構成とは、変更を認める仕組みが異なる。

ここで、証明への電子署名と、ブロックチェーンの履歴は役割を分けて考えたい。電子署名は、受け取ったデータが署名後に書き換えられていないかを検証するために使う。ブロックチェーンは、記録の順序や状態の変更について合意し、確定した履歴を書き換えにくくするために使える。「改ざん不能」という一言でまとめると、この違いを見落とす。

もちろん、元から誤った内容を記録した場合に、その内容が真実へ変わるわけではない。利用するネットワークの性質や鍵の管理によっても安全性は変わる。何を証明し、どの情報を台帳で共有したいのかを決めた上で使う技術である。

共通に使えることと、同じIDを使い回すこと

サービスを越えて通用するアイデンティティを持つことは、全サービスへ同じ識別子を渡すこととは限らない。同じ識別子が広く公開されれば、仕事、買い物、コミュニティでの活動を結び付けられることがある。DID Coreのプライバシーに関する説明も、この関連付けのリスクを扱っている。

利用者が相手や用途ごとに識別子を使い分けながら、必要な証明を共通の方法で提示できる構成も考えられる。SSIが求める利用者の制御には、見せる相手と情報を選ぶことも含まれる。公開台帳の使いやすさと、利用者の活動を結び付けやすくなることは、一緒に検討したい。

利用者が識別情報や証明を持ち運び、自分で利用を選べるようにする。この考え方を具体化しようと、EthereumではスマートコントラクトでIDや証明を管理する試みが進んだ。DID/VCも、特定のサービスに依存せず識別情報や証明を使うという思想の流れを汲み、異なるシステムの間で使える共通仕様として整えられてきた。

ブロックチェーンとの思想や技術面の親和性は高いが、DID/VCの利用に必須ではない。Ethereum上の試みをいくつか見てから、DID/VCが何を共通化したのかを考えてみよう。

Ethereumでは、SSIをどう実現しようとしたのか？

Ethereumでは、鍵や操作権限を自分で管理し、他者から受け取った証明を使うために、スマートコントラクトをどう設計するかが検討された。代表的な提案を、ID用コントラクト、共有レジストリ、複数アドレスの管理という三つの観点から紹介する。

提案に付いているERCは、Ethereum Request for Commentsの略で、アプリケーション向けの規約などを提案する仕組みである。

ERC-725とERC-735：自分用のコントラクトで管理する

2017年のERC-725初期案は、利用者ごとのID用コントラクトで鍵や操作権限を管理するものだった。ERC-735は、そこへ発行者が署名したクレームを追加・削除する仕組みを提案した。クレームとは「このアドレスの利用者は研修を修了した」といった主張であり、ハッシュや外部のデータを参照するURIも扱う。

自分のIDを操作する権限と、他者が自分について発行した証明を、コントラクトで管理しようとした例である。なお、現在のERC-725は汎用の実行機能ERC725Xとデータ保存機能ERC725Yで構成されており、初期案から設計が変わっている。

ERC-780とERC-1056：共有レジストリを使う

利用者ごとにコントラクトを持つ構成に対し、共通の記録先を使う提案もある。ERC-780は、発行者と対象アドレスを関連付け、クレームに対応する値を共有レジストリへ記録するものだった。値は公開のbytes32であり、ハッシュを使う場合も個人情報を推測されないかを検討する必要がある。

2018年のERC-1056は、Ethereumアドレスを識別の起点にし、共通のEthereumDIDRegistryで管理者や委任先などを更新する。利用者ごとのコントラクト作成は不要で、初期の識別子を作るだけなら登録トランザクションも要らない。管理者の変更などをチェーンに記録するときには、処理手数料のガス代がかかる。

ERC-1484：複数のアドレスを関連付ける

ERC-1484は、Ethereum Identification Numberという識別番号に複数のアドレスを関連付ける提案だった。用途や端末ごとに増えたアドレスをまとめて扱える一方、公開された関連付けから利用者の活動を追いやすくなるという課題もある。

ERC-1056とERC-1484の仕様文書は、確認時点ではStagnantという状態にある。採用を検討する場合は、提案文書の状態に加えて、使おうとする実装の保守状況も確認したい。

鍵や権限を誰が管理するか、他者から受け取った証明をどこで使えるかは、Ethereumの外でも必要になる設計である。DIDとVCは、識別情報や証明を異なるシステムで扱うために、どのような共通ルールを定めているのだろうか。

DIDとVCは、その課題をどう扱うのか？

DIDは対象を指すための仕組みであり、VCは対象について発行者が述べた内容を検証可能にするための仕組みだ。この二つを、架空の研修会社が修了証を発行する場面で考えてみる。

修了証には「発行する・持つ・確かめる」の三者がいる

研修会社は、受講記録と合格条件を確認して修了証を発行する。受講者はそれを受け取り、転職先などに提示する。受け取った企業は、証明の署名や有効性を確かめ、自社の採用判断に使えるかを決める。

VCの基本モデルでは、これらを発行者、保有者、検証者と呼ぶ。英語の資料にはIssuer、Holder、Verifierという名前で登場する。保有者が証明の対象者と同じとは限らず、組織が機器の証明を管理するような使い方もある。VC Data Model 2.0は、この役割分担を定めている。

役割	研修の修了証の例	技術以外に決めること
発行者	研修会社	何を確認したら「修了」と認めるか
保有者	修了証を受け取る受講者	保存先、提示の同意、紛失時の手続き
検証者	修了証を受け取る企業	どの発行者・研修を受け入れるか

電子署名を使う場合、発行者は秘密に保つ鍵でデータに署名し、検証者は対応する公開鍵で署名を確かめる。途中で内容が書き換えられていれば検証は通らない。ただ、検証に使った鍵が、受け入れるべき研修会社のものかどうかも確認する必要がある。

署名が正しくても、架空の研修会社が勝手に発行した証明を採用する必要はない。署名の検証で確かめられることと、発行者の審査能力や証明内容への信頼は、分けて考えるべきだ。暗号技術が得意なのは改ざんや鍵との対応の検証であって、試験監督の仕事ではない。

DIDは「この対象」を指し、鍵などの情報を参照する

DIDは、説明用の例ではdid:example:123という形を取る。didに続く部分が「DIDメソッド」の名前であり、その方式で識別子をどう作り、どう読み出し、どう更新するかを決める。このexampleは構文を示すためのもので、実サービスのIDではない。

DIDを解決する処理では、DID Documentと呼ぶ文書などを得る。そこには、認証や署名の検証に使う情報、サービスの接続先などを記述できる。これは対象の履歴書を丸ごと公開するための文書ではない。DID Core 1.0は、共通の構文とデータモデルを定め、具体的な保存先や更新方法を各メソッドに委ねている。

ここでは、DIDが指す対象と、DIDを制御する主体も区別する。会社が管理する機器にDIDを付けるなら、対象は機器でも、鍵や文書を管理するのは会社かもしれない。鍵を操作できることだけで、その人の実名や、対象についての資格が確定するわけではない。

DIDとVCは、必ずセットなのか？

必須の組み合わせではない。VCの仕様では、識別子にDIDを使うことができるが、DIDの使用自体は要件ではない。逆に、DIDで対象を識別していても、その対象にVCを発行しているとは限らない。

DID/VCにブロックチェーンは必要なのか？

DID/VCはブロックチェーンと一緒に語られることが多いが、利用にブロックチェーンは必須ではない。 SSIが求める利用者による制御と、鍵や履歴を共有して検証する技術との親和性が高いことが、両者の結び付きの背景にある。思想や実装上の相性と、規格の必須要件は区別する必要がある。

DID Coreは、識別子を管理する基盤を一つのブロックチェーンに固定していない。たとえばdid:webのように、WebのドメインとHTTPSを使う方式もある。また、VC Data Model 2.0は、DIDの使用自体を必須にしていない。証明の発行や検証にも、必ずチェーン上の取引が伴うわけではない。

たとえば、研修会社が管理するWebサイトから公開鍵の情報を取得し、受講者が提示した修了証の署名を企業が検証する構成なら、ブロックチェーンを使わずに組み立てられる。ドメインや鍵を維持する責任は残るが、署名による改ざん検知を行うために、証明をチェーンに保存する必要はない。

DIDを作り、公開鍵などの情報を参照する具体的な方式を、DIDメソッドと呼ぶ。方式によって、情報の取得先や変更の手順、管理するものが変わる。複数の組織が共有する管理権限の履歴などをチェーンで扱いたいなら、それに対応するメソッドを選ぶ理由になる。「VCを導入するので、まず利用者に暗号資産を買ってもらう」という順番にはならない。誰が何を管理し、相手がどう確かめるのかに応じて基盤を選ぶ。