本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

デジタルアイデンティティの連載で、SSI (Self-Sovereign Identity、自己主権型アイデンティティ) の三者モデルと、W3C が資格情報の何を決めているかを整理しました。どちらでもブロックチェーンには触れていません。一方、SSI を紹介する資料では台帳が併記されることが多く、「SSI にはブロックチェーンが要る」という前提で話が進む場面もあります。

この記事では、その結びつきが仕様のどこにあり、実装では実際に何が使われているのかを確かめます。結論を先に書くと、資格情報の発行・提示・検証という一往復に台帳は現れず、台帳が関わりうるのは「発行者の鍵をどこから引くか」を含む周辺の 4 つの役割です。そしてその 4 つのうち 3 つには、台帳を使わずに埋める道が仕様として用意されています。

「相性がよい」と言われた背景

SSI を 10 の原則としてまとめた Christopher Allen の "The Path to Self-Sovereign Identity" (2016-04-26) は、デジタルアイデンティティの統治 (administrative control) を 4 段階に整理し、第 4 段階として自己主権型を置いています。原則の側には Persistence (永続性)、Portability (可搬性)、Control (制御) が並んでいて、いずれも「単一の運営者に依存しない置き場所」を要求しているように読めます。ここに、当時すでに動いていた公開台帳が当てはめられた、と説明されることが多いようです (この接続の経緯そのものを跡づけた資料には行き当たっていないので、以下は仕様と実装の側から見た整理になります)。

分解すると、要求は 2 つに分かれます。ひとつは「識別子と鍵が、単一の事業者の都合で消えない」こと。もうひとつは「その識別子と鍵の履歴を、第三者が後から検証できる」ことです。台帳はこの 2 つを同時に満たす手段のひとつではありますが、唯一の手段ではありません。この点は仕様の側がはっきり書いています。

一往復に台帳は現れない

まず、資格情報そのものの流れを確認します。発行者 (Issuer) が署名した VC (Verifiable Credential、検証可能な資格情報) を保持者 (Holder) が受け取り、検証者 (Verifier) に VP (Verifiable Presentation、提示物) として渡す。検証者は署名を検証する。失効の確認を組み込まない場合、ここまでに必要なのは署名アルゴリズムと発行者の公開鍵だけです (失効を入れるとどうなるかは後述します)。

VC の一往復に台帳が現れないことを示した図。見出しは「VC の一往復そのものには、台帳は現れない」、副題は「この一往復の中で台帳が関わりうるのは『発行者の鍵をどこから引くか』だけ」。上段に 3 つの箱が横に並ぶ。左が Issuer（発行者、所属や資格を証明する主体）、中央が Holder（保持者＝本人、ウォレット / 鍵を持つプロセス）、右が Verifier（検証者、アクセスを判断するサーバ）。Issuer から Holder へ「VC を発行」、Holder から Verifier へ「VP を提示」の矢印が引かれている。中央に「署名を作る → 署名つきのデータを渡す → 署名を検証する」「ここまでに台帳は 1 度も出てこない」と記されている。下段は破線で囲まれた帯で、Verifiable Data Registry（検証可能データレジストリ）と題され、「W3C の用語では『識別子と鍵の作成・検証を仲介する役割』。特定の技術を指す語ではない」と注記。帯の中に 4 つの箱が並び、did:web（HTTPS の .well-known）、台帳（分散台帳、did:indy / did:ebsi など、これだけ赤枠）、データベース（運営者が管理する名簿）、政府の ID データベース（公的機関が持つ台帳）。Issuer から帯へ下向きの破線矢印で「鍵を公開する」、帯から Verifier へ上向きの破線矢印で「発行者の公開鍵を引く」。最下部に「VC Data Model 2.0 は VDR の例として trusted databases / decentralized databases / government ID databases / distributed ledgers を並べている。台帳はその 1 つで、既定値ではない」とある。

その鍵をどこから引くかを担う役割を、W3C は Verifiable Data Registry (検証可能データレジストリ、以下 VDR) と呼んでいます。VDR は特定の実装を指す語ではなく、役割の名前です。VC Data Model v2.0 (W3C 勧告 2025-05-15) は、エコシステムの登場人物を並べる節で次のように書いています。

Examples of verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often, more than one type of verifiable data registry used in an ecosystem.

— Verifiable Credentials Data Model v2.0, §1.2 Ecosystem Overview

分散台帳は 4 つ挙げられた例のうちの 1 つで、既定値としては書かれていません。識別子の側の仕様も同じ立場です。DID (Decentralized Identifier、分散識別子) の仕様は、冒頭で技術を前提にしないと明言しています。

This specification does not presuppose any particular technology or cryptography to underpin the generation, persistence, resolution, or interpretation of DIDs.

[…] This also enables implementers to design specific types of DIDs to work with the computing infrastructure they trust, such as distributed ledgers, decentralized file systems, distributed databases, and peer-to-peer networks.

— Decentralized Identifiers (DIDs) v1.0 (W3C 勧告 2022-07-19), Introduction

引用は勧告済みの v1.0 からのものです。同じ 2 文は策定中の v1.1 (Candidate Recommendation Snapshot 2026-03-05) にも同一の文言で入っており、この点は版が変わっても動いていません。

その v1.1 の HTML を取得して、script と style を除いたテキストで blockchain という語を数えると 2 件でした。1 件は著者の所属名 (Blockchain Commons) で、残る 1 件は「署名がいつ作られたかを判断する材料の例」としての言及です (2026-08-20 に確認)。名前に "Decentralized" が入っているために台帳を連想しやすいのですが、仕様が要求しているのは「識別子から鍵にたどり着ける経路がある」ことまでです。

台帳に期待された 4 つの役割

では、台帳はどこに置かれると想定されていたのか。役割ごとに分けると 4 つになります。

台帳に期待された 4 つの役割と、実際に使われている埋め方を左右 2 列で対比した図。見出しは「台帳に期待された 4 つの役割と、実際に使われている埋め方」、副題は「①〜③ には台帳を使わない道が用意されている。③ は台帳に置く構成も実在し、④ は台帳が仕事をしている」。4 行あり、各行は左に役割、右に実際の手段が置かれ矢印でつながる。① 発行者の鍵を公開し、更新する → did:web（HTTPS の .well-known に鍵を置く）/ did:webvh（台帳なしで更新履歴を検証可能にする）/ X.509 の証明書チェーン。② 資格情報を有効期限より前に取り消す → Bitstring Status List v1.0、131,072 ビット以上の一覧を CDN などで配る。③ 誰を発行者・参加者として認めるかを決める → EUDI の Trusted List / LoTE、mDL の VICAL、Gaia-X Registry。いずれも署名つきの名簿。ただし Pontus-X の参加者 ERC-721 のように、名簿を台帳に置く構成も実在する。④ 資産・アクセス権・決済を登記する → Ocean の Data NFT（所有権）と Datatoken（アクセス権）。ここは台帳そのものが担っている。④ の行だけ赤枠で示されている。最下部に「④ は『誰であるか』ではなく『何を持っているか』の登記で、identity の層とは別。混ぜると議論が噛み合わなくなる」とある。

以下、1 つずつ見ていきます。図の ① の行に X.509 と did:webvh も並べていますが、前者は③、後者は最後の節でまとめて扱います。

① 発行者の鍵を公開し、更新する

いちばん台帳が想定されてきた場所です。手元で触れた範囲では did:web が使われていました。仕組みとしては素直で、did:web:example.com なら https://example.com/.well-known/did.json を取りに行けば鍵が書いてある、というだけのものです。

手元で組んだ Gaia-X の検証環境でも、適合性証明の発行者は did:web:gx-tls でした (許可リストに載っている本人が、ダウンロードできない に経緯を書いています)。本番側も同じで、Gaia-X Registry の complianceIssuers が返すのは ["did:web:compliance.gaia-x.eu"] の 1 件だけです (Gaia-X Registry には何が入っているのか で実際に叩いています)。ここには台帳が出てきません。

商用のサービスでも同様の移行が起きています。Microsoft Entra Verified ID は、Bitcoin 上に構築された Sidetree 系の DID ネットワークである ION を試験的に扱っていましたが、FAQ にはこう書かれています。

Verified ID supported the DID:ION method in preview until December 2023.

— Frequently asked questions - Microsoft Entra Verified ID

同じ FAQ には did:ion から did:web へ移すための手順が節として用意されています。

② 資格情報を有効期限より前に取り消す

失効の確認も、台帳の用途として挙げられてきた場所です。検証者が発行者に直接問い合わせる形にすると、発行者に提示先が伝わってしまう ── 三者モデルが避けようとしていた性質がそこで戻ってきます。

W3C はこれを、台帳ではなくビット列で解いています。Bitstring Status List v1.0 (W3C 勧告 2025-05-15) は、資格情報 1 通を 1 ビットに割り当てた長い一覧を、発行者が 1 本のファイルとして公開する方式です。検証者はその一覧全体を取得し、自分の関心のあるビットだけを読みます。どのビットを見たかは発行者に伝わりません。

This specification uses a minimum list length of 131,072. This size ensures an adequate amount of group privacy in the average case.

— Bitstring Status List v1.0

ただし、発行者が運営する URL から素直に取得すれば、発行者は「誰かが取りに来たこと」自体は知ります。仕様はそこも織り込んでいて、発行者が誰の取得かを追跡できない配り方 (Oblivious HTTP や、発行者が運営していない CDN (Content Delivery Network) 経由など) を発行者側の SHOULD として勧め、検証者側にもキャッシュとプロキシの利用を SHOULD で求めています。131,072 ビットは非圧縮で 16 KB、失効が少ないうちは GZIP で数百バイトまで縮む、と仕様は書いています。

つまり、発行者に提示先を知らせないための手当てが、台帳を持ち出さずに仕様の側へ置かれている形です。なお、ここで確認したのは仕様の記述までで、この方式がどれだけ稼働しているかまでは調べられていません。

③ 誰を発行者・参加者として認めるかを決める

署名が正しいことを確かめても、その署名者に証明を出す資格があるかどうかは出てきません。この「誰を発行者として信じるか」は、連載の 1 本目でも規格の外に残ると書いた部分です。ここに、名簿を台帳に置く構成が提案されてきました。

制度の側で先に動いている EU の文書を見ると、置かれているのは署名つきの名簿でした。EUDI Wallet (European Digital Identity Wallet、EU が加盟国に提供を求めているデジタル身分証アプリ) の作りを定める ARF (Architecture and Reference Framework) の v3.0.0 (2026-07-23 リリース) を手元に落として全文を検索したところ、docs/ 配下の 69 個の Markdown のいずれにも blockchain / distributed ledger / decentralized identifier のいずれの語も現れませんでした。

curl -sL -o arf.tar.gz \
  https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/archive/refs/tags/v3.0.0.tar.gz
tar xzf arf.tar.gz
cd eudi-doc-architecture-and-reference-framework-3.0.0
find docs -name '*.md' | wc -l
grep -ril "blockchain" docs | wc -l
grep -ril "distributed ledger" docs | wc -l
grep -ril "decentrali[sz]ed identifier" docs | wc -l

      69
       0
       0
       0

代わりに置かれているのが、署名つきの名簿の仕組みです。Trusted List は加盟国が通知した事業者の一覧、LoTE (List of Trusted Entities) はそれを欧州委員会側でまとめたもので、そこに載るのはトラストアンカー (公開鍵と識別子の組) です。通知と状態変更の手続きは実施規則 CIR (Commission Implementing Regulation) 2024/2980 に沿う、と ARF 第 6 章に書かれています。

資格情報の形式についても、ARF 第 5 章 (5.4.1) の表は次のようになっています。Mandatory / Optional は ARF の表記そのままです。

形式Wallet Support
ISO/IEC 18013-5 / ISO/IEC 23220-2Mandatory
SD-JWT VCMandatory
W3C VCDM v2.0Optional

対面提示に使われる ISO/IEC 18013-5 の mDL (mobile driving licence、モバイル運転免許証) も、トラストの土台は X.509 です。公開されている実装解説によれば、各発行当局が自分の IACA (Issuing Authority Certificate Authority) を自己署名のルート証明書として持ち、そこから Document Signer Certificate を発行して mDL に署名します。多数の発行当局をまたぐ場合は、同規格の Annex C が定める VICAL (Verified Issuer Certificate Authority List) という署名つきの一覧を検証者が参照します (規格本体は有償のため、ここは AWS や MATTR が公開している解説に依拠した記述です)。

Gaia-X も同じ形で、Gaia-X Registry が返すのは「窓口となるホスト名の一覧」と「記述が満たすべき形」で、これも名簿です。

ここまでは台帳が出てきませんが、③を台帳で埋める構成も実在します。手元で触っている Pontus-X がそれで、参加者としてオンボードされたアドレスには Identity Issuer NFT という ERC-721 (Ethereum Request for Comments 721、代替不可能なトークンの標準) が発行され、テストトークンの配布口はその保有数を見て可否を判定していました (Pontus-X の参加者一覧を API で調べる に、コントラクトを特定するまでの手順を書いています)。エコシステム独自の名簿が、署名つきのファイルではなくチェーン上のコントラクトとして動いている形です。

つまり③は、署名つきの名簿と台帳の両方が実際に使われている層です。もっとも、名簿を誰かが運営する点はどちらでも変わりません。後述する EBSI (European Blockchain Services Infrastructure、EU の共同運用型の台帳) のように台帳を使う構成でも、ノードの運用者とガバナンス規則を定める主体は残ります。運営主体が要るかどうかは、台帳の有無だけで決まる差ではないように見えます。

④ 資産・アクセス権・決済を登記する

4 つ目は、台帳が正面から使われている層です。手元で触っているデータスペースがそれにあたります。

Ocean Protocol のスタックでは、データ資産の所有権を Data NFT (ERC-721) が、アクセス権を Datatoken (ERC-20、代替可能なトークンの標準) が表します。資産の識別子 did:op:... も台帳と結びついていて、公式ドキュメントによれば Data NFT のコントラクトアドレス (チェックサム形式) と chainId を連結した文字列の SHA-256 として計算されます。

ここで注意したいのは、④が扱っているのは「誰であるか」ではなく「何を持っているか」だという点です。同じ Pontus-X の中でも、③で見た参加者の名簿と、参加者の資格を証明する Gaia-X の適合性証明 (did:web で署名された VC-JWT) と、この④の資産登記は、それぞれ別の層にあります。1 つのシステムに全部入っているために「SSI をブロックチェーンで実装している」と読めてしまいますが、分けて見たほうが噛み合います。

台帳を選ぶと付いてくる条件

台帳を選ぶ場合、識別子や鍵が個人データに当たるかどうかが実務上の論点になります。EDPB (European Data Protection Board、欧州データ保護会議) は Guidelines 02/2025 でこの点を整理していて、公開協議を経た v2.0 が 2026-07-07 に採択されています (協議前の v1.1 は 2025-04-08)。

まず、識別子そのものの扱いです。

If the user is a natural person and those public keys can be used to identify the individuals by means reasonably likely to be used, for example in case of a data breach, then those identifiers qualify as personal data.

— Guidelines 02/2025 on processing of personal data through blockchain technologies (Version 2.0, Adopted on 07 July 2026), para. 26

ハッシュにしても GDPR (General Data Protection Regulation、EU 一般データ保護規則) の適用から外れない、とも書かれています。

Although this may be referred to as "off chain" storage, it is important to recall that the GDPR will still apply to that processing activity and that the hash will also be considered personal data, as will any other identifiers that might exist.

— 同 para. 52

そして、削除できないことは免責にならない、という一文があります。

The EDPB emphasises that technical impossibility cannot be invoked to justify non-compliance with GDPR requirements.

— 同 para. 50

そのうえで、消去権を扱う節にはこう書かれています。

Considering the difficulty of achieving this in practice, the EDPB recommends looking at other tools if the strong integrity property of blockchains is not needed.

— 同 para. 103

Annex A の推奨の 1 番目は、ブロックチェーンに載るデータに個人データが含まれるか、含まれるなら「なぜブロックチェーンがその処理にとって必要かつ比例的な手段なのか (rationale は何か、代替案は何だったか)」を文書化するよう求めています。台帳を選ぶ場合、選ばなかった選択肢もあわせて書き残すことが要る、という構図です。

台帳の「不変性」がどこまでの主張なのかについては、別の記事「Trust, but verify」で、NIST (National Institute of Standards and Technology、米国国立標準技術研究所) の定義や確定までの待ち時間の話として扱いました。あわせて読むと、台帳を選ぶ側の条件が見えやすくなると思います。

did:web が前提にしていることと、その間にある選択肢

ここまでの流れだけ見ると did:web で足りるように読めますが、この方式にはいくつか前提があります。DIF (Decentralized Identity Foundation) が策定している did:webvh の仕様は、did:web との差を次のように説明しています。

it is not inherently decentralized as it relies on DNS domain names, which require centralized registries. Furthermore, it lacks a cryptographically verifiable, tamper-resistant, and persistently stored DID document.

— The did:webvh DID Method — did:web + Verifiable History (v1.0 Editors Draft)

具体的には 2 つです。ひとつは、発行者のドメインが失効したり別の主体に渡ったりすると、鍵の取得先がそのまま影響を受けること。もうひとつは、鍵がいつどう更新されたかの履歴が残らないので、過去のある時点でその鍵が正当だったかを後から確かめられないことです。学位証明のように発行者より長生きしうる資格情報では、ここが効いてきます。

did:webvh は、この 2 点を台帳なしで埋めようとしている方式です。DID ドキュメントの更新を genesis から deactivation まで検証可能な連鎖として残し、識別子自体を最初のログ項目から導く自己証明的な形にし (SCID、Self-Certifying Identifier)、鍵の事前ローテーションと、DID の移設 (portability) を任意の仕組みとして用意しています。位置づけは仕様の説明に明示されています。

[…] a verifiable history, akin to what is available with ledger-based DIDs, but without relying on a ledger.

— 同上

つまり選択肢は「台帳か、素の did:web か」の二択ではありません。ここは判断の分岐が増えている部分です。

台帳側の現況を、観測できる範囲で

SSI と台帳を結びつけてきた実装の側がいまどうなっているかも、公表されている事実の範囲で並べておきます。評価ではなく、確認できたことだけです。ここで挙げるのは、SSI の文脈でよく名前が挙がってきた実装に絞っています。

  • Sovrin Foundation は、MainNet の停止を 2025-03-31 までに行う見込みであることを公表し (停止見込みの告知)、その後 2025-05-21 に米ユタ州によって解散されました。MainNet は読み取り専用のアーカイブとして残り、Trinsic が Caretaker を務めると発表されています (解散の告知)。
  • Hyperledger Aries のプロジェクト用リポジトリ (hyperledger-aries/aries) は GitHub 上でアーカイブ済みで、最終 push は 2025-01-08 です。一方、Aries の系譜にあるエージェント実装の ACA-Py (openwallet-foundation/acapy) と Credo (openwallet-foundation/credo-ts) は OpenWallet Foundation の下で開発が続いており、いずれも 2026-08-19 に push がありました。
  • Sidetree 系の decentralized-identity/ion は、アーカイブされてはいないものの最終 push が 2023-08-25、decentralized-identity/sidetree が 2024-12-12 です。同じ DIF の decentralized-identity/didwebvh は 2026-08-11 に push があります。

いずれも 2026-08-20 に GitHub API と各サイトで確認した値です (日付は API が返す UTC のもの)。リポジトリの更新頻度は利用状況そのものではないので、ここから「使われていない」と読むのは行きすぎですが、開発の重心がどこにあるかの目安にはなると思います。

台帳を使う側も残っています。上で③の例に挙げた Pontus-X がそうですし、EU の EBSI は、公式サイトの記述では「参加する EU 加盟国のために Europeum-EDIC が運用する共有デジタルインフラ」で、各ノードを独立した組織が運用し、ノード運用者はガバナンス規則に従うことが条件とされています。本番運用にあたる Business Launch は 2026 年に予定と掲示されています (EBSI About us)。ここでの台帳は、加盟国のいずれか 1 か国が名簿を握る形を避けるための共同運用、という位置づけに読めます。

どういう順で決めるか

以上を踏まえると、判断の順番は次のようになりそうです。役割の丸数字と混ざらないよう、こちらは A から E で書きます。

  • A. 資格情報の形と署名を先に決めます。ここに台帳の選択は入ってきません
  • B. 発行者の鍵の取得先を決めます (役割①)。まず did:web を置き、発行者より資格情報が長生きするなら did:webvh を検討します
  • C. 失効が要るなら Bitstring Status List を入れます (役割②)。ここでも台帳は要りません
  • D. 名簿を誰がどう持つかを決めます (役割③)。名簿の運営を関係者が受け入れられるなら署名つきの名簿で足ります。受け入れられない場合に、共同運用の台帳が候補の 1 つに入ります (VICAL のように、複数の名簿が相互に署名し合う形もあります)
  • E. 資産の所有権やアクセス権、決済を扱うなら、それは identity とは別の設計として扱います (役割④)

D で台帳に行き着く要件は実際にありえます。国をまたぐ資格の相互承認のように、どこか 1 か国の機関が名簿を握る形が合意できない場合がそれです。逆にいえば、そこに至らない要件であれば A から C は台帳なしで組める、というのがここまで見た範囲での整理です。

整理

  • W3C の仕様は、識別子と鍵の置き場所 (Verifiable Data Registry) の例として分散台帳を挙げていますが、trusted databases や government ID databases と並記していて、既定値としては書いていません。DID の仕様は技術を前提にしないと明言しています。
  • 発行・提示・検証の一往復には台帳が現れません。台帳が関わりうるのは、鍵の公開・失効・名簿・資産登記という周辺の役割です。
  • 鍵の公開は、手元で触れた範囲では did:web でした。Entra Verified ID は did:ion の対応をプレビューとして 2023 年 12 月までとし、Gaia-X の適合性証明の発行者も did:web の 1 件です。
  • 失効は Bitstring Status List v1.0 が、最小 131,072 ビットの一覧を配る方式で扱っています。発行者に提示先を知らせないための手当てが、台帳なしで仕様の側に置かれています。
  • 名簿は、EUDI Wallet が Trusted List / LoTE、mDL が VICAL、Gaia-X が Registry と、いずれも署名つきの一覧です。ARF v3.0.0 の docs/ 配下 69 ファイルに blockchain / distributed ledger / decentralized identifier の語は出てきませんでした。一方で Pontus-X のように、名簿をチェーン上の ERC-721 として持つ構成も実在します。
  • 資産の所有権・アクセス権・決済の登記は、台帳が実際に担っています。ただしこれは「誰であるか」ではなく「何を持っているか」で、identity の層とは分けたほうが議論が噛み合います。
  • 台帳を選ぶ場合、EDPB のガイドラインは公開鍵やハッシュも個人データにあたりうるとし、技術的不可能性は免責にならないと書いています。強い integrity が必要でないなら他の道具を見ることを勧め、選んだ理由と代替案の文書化を推奨の 1 番目に置いています。
  • did:web が前提にしていること (ドメインへの依存と履歴の不在) は、台帳を持ち出さずに did:webvh で埋める方向の仕様が動いています。選択肢は二択ではありません。
  • 「SSI にはブロックチェーンが要る」は、「SSI の三者モデル自体は署名で閉じており、台帳は鍵と名簿の置き場所の選択肢の 1 つです」と言い換えると、必要な場面と不要な場面の両方が見えます。

出典