信頼レジストリの2つの実装モデル。階層的委任とリストは、どう選ぶのか？

ZenChAIne·2026年10月2日

DIDVC信頼レジストリTRQP

はじめに

信頼レジストリを作るとき、発行者の名前を並べるだけで足りるのか。それとも、「誰がその発行者を認めたのか」をさらにたどれる仕組みが要るのか。選び方は、その事業で誰に審査や認定を任せるかによって変わる。

前回の記事では、VC（Verifiable Credential、検証可能なデジタル証明書）の署名を確かめることと、発行者の権限を確かめることを分け、信頼レジストリとTRQPの実装例を紹介した。今回はレジストリの中身に進む。元のZenn記事で扱った「階層的委任モデル」と「シンプルなリストモデル」を、具体的な運用まで含めて比べたい。

この記事のポイント

階層的委任は、認定する権限を別の組織へ委ね、その経路を検証する考え方である。
リストによる直接登録は、受け入れる発行者と権限を記録して照合する考え方である。
階層の認定結果をリストとして照会する構成も取れる。二つは併用できる。
どちらも、権限の範囲、有効期間、取消と更新の扱いまで決めて初めて業務で使える。

公開資料の確認日は2026年10月1日。製品説明と公開ソースを参照しており、各製品を動かした比較試験や、本番導入先での評価ではない。

2つのモデルは、何が違うのか？

違いを理解するには、「発行を認める判断がどこで行われるか」を見るとよい。運営者がすべての発行者を直接審査するなら、承認した結果を一覧にできる。認定作業を別の組織へ委ねるなら、その組織にどこまで任せたかも記録する必要がある。

説明用に、架空の業界団体が研修修了証を扱う場面を考える。全国団体、地域団体、研修会社、受講者、修了証を受け取る企業が参加する。実在する資格制度や導入事例を示すものではない。

直接登録する場合：全国団体が研修会社Aを審査し、「安全研修の修了証を発行してよい」とリストに記録する。
階層的に委任する場合：全国団体が地域団体に研修会社を認定する権限を与え、地域団体が研修会社Aに修了証の発行を認める。

どちらでも、研修会社Aが受講者へ修了証を発行する。変わるのは、その会社が発行してよいと判断できる根拠である。

直接登録と階層的委任。前者は全国団体が研修会社を直接承認し、後者は地域団体を介して認定する。

この二分類は説明のための整理であり、すべての信頼レジストリを二つに分ける国際標準ではない。「認定を委任する」という運営上の構造と、「リストに保存する」というデータの形は、別々に選べる。

階層的委任では、何をたどるのか？

階層的委任では、発行者に至る認定の経路を確認する。最初の組織を信頼の起点として受け入れ、その組織から次の組織へ与えた権限が、途中で勝手に広がっていないかを調べる。

この考え方の公開例が、欧州のブロックチェーン基盤EBSIのTrust Chainsと、cheqdのDecentralized Trust Chains（DTC）である。cheqdはデジタルID向けのネットワークやツールを開発しており、DTCではEBSIの考え方を踏まえ、認定を証明書としてたどれる仕組みを説明している。

「証明書を発行する」と「発行者を認定する」

cheqdのDTCでは、認定を表すVCを**Verifiable Accreditation（VA）**と呼ぶ。研修を受けた人の修了証とは用途が違い、VAが示すのは組織に認められた権限である。

先ほどの架空の例を当てはめると、次の流れになる。

全国団体が、制度のルールと信頼の起点を示すRoot Authorizationを公開する。
全国団体が地域団体に、研修会社を認定するためのVAを発行する。
地域団体が研修会社Aに、安全研修の修了証を発行するためのVAを発行する。
研修会社Aが受講者に、通常の修了証VCを発行する。

公式資料では、起点となる組織をrTAO、途中の認定組織をTAO、実際に証明書を発行する組織をTIと呼ぶ。役割を三つ覚えるよりも、「認定を任せる」「発行を認める」「受講した事実を証明する」という三つの行為を区別すると読みやすい。cheqdの設定手順

委任する範囲も検証する

「安全研修の修了証を発行してよい」という認定から、医師免許の発行権限が生まれるわけではない。また、証明書の発行だけを認められた会社が、別の会社を認定してよいことにもならない。

cheqdのTAOから発行者への認定では、証明書の種類やスキーマ、管轄の制限を記述する。別の認定組織へ権限を委ねる場合には、SubTAOへの認定として親の認定や起点への参照も持たせる。

検証する企業は、必要な認定を取得し、署名、有効期間、状態、権限の範囲を確認する。自社が受け入れる起点までたどれることも条件だ。署名が正しい自己宣言を作れたとしても、その組織を信頼の起点として採用する判断まで自動で得られるわけではない。

cheqdでは認定をDIDに関連付けたリソースとして公開する。この実装でブロックチェーンを使うことと、階層的委任という考え方にブロックチェーンが必須であることは別である。委任の構造、署名方式、保存先を分けて読む必要がある。

リストモデルでは、何を記録するのか？

リストモデルでは、受け入れる発行者と、その発行者に認められた権限を直接照合する。運営者自身が研修会社を審査するなら、認定の連鎖を作らず、その判断を登録すればよい。

ただし、DID（組織などを識別するための識別子）だけの名簿では、「どの証明書を発行してよいか」が分からない。説明用の内部データなら、例えば次のように書ける。これはTRQPや特定製品の標準データ形式ではない。

json

{
  "authority": "did:example:training-council",
  "issuer": "did:example:training-company-a",
  "permission": "issue",
  "credentialType": "https://example.org/credentials/SafetyCourse",
  "validFrom": "2026-04-01T00:00:00Z",
  "validUntil": "2027-04-01T00:00:00Z",
  "status": "active"
}

企業は、修了証の発行者と種類を取り出し、自社が信頼する全国団体の記録と照合する。有効期間内で、対象の発行権限が有効であることを確かめる。全国団体の名簿に載っているからといって、その会社が発行する証明書を無制限に受け入れる設計にはしない。

なお、VCの種類とcredentialSchemaは同じものではない。どの項目を発行権限の照合に使い、スキーマの版をどう扱うかは参加者間で決める。W3C VC Data Model 2.0のデータスキーマ

公開実装では、AffinidiのCSVを確認できる

前回も紹介したAffinidiのRust製信頼レジストリには、CSVを保存先として使う起動手順とサンプルデータがある。CSVにはentity_id、authority_id、action、resourceなどが並ぶ。主体の名前だけでなく、誰が、どの行為を、どの対象について認めたかを記録している。確認したサンプル

これは、直接記録した権限を共通のAPIで問い合わせる構成を読むのに適した公開例だ。ただし、この製品全体を「単純な名簿だけの製品」と分類する意図ではない。実装は認定主体どうしの承認を扱うRecognitionも備えている。

製品として案内されているAffinidi Radixは、確認時点でEarly Access Programmeの段階である。CSVは開発・テスト向けの選択肢として説明されており、本番の性能や運用実績を今回確認したわけではない。

TRQPを使えば、内部モデルは統一されるのか？

TRQP（Trust Registry Query Protocol）は問い合わせの方法を共通化する。誰を登録するか、どんな審査で認定するか、認定結果を内部でどう保存するかまでは一つに決めない。ToIPの承認済みTRQP v2.0

したがって、階層的な認定を検証する仕組みと、リストを検索する仕組みの両方に、共通の照会窓口を設ける設計は可能だ。ただし、cheqdのDTCがそのままTRQPの同じ窓口を備えると確認したわけではない。既存モデルと照会仕様を接続する場合は、そのための実装が要る。

階層で認定し、リストで答える構成

例えば、地域団体の認定を検証した結果から、「研修会社Aは安全研修の修了証を発行できる」という検索用の一覧を作る構成を考えられる。これは本記事で示す設計例であり、特定製品で動作確認した構成ではない。

その場合、一覧に結果だけを書いて終わりにはできない。どの認定を根拠にしたか、いつ評価したか、上位の認定が取り消されたときにどの行を再評価するかも必要になる。読み取りを簡単にした分、更新の責任を引き受ける設計になる。

Recognitionは、委任の別名ではない

TRQPのRecognitionは、ある主体が別の主体を、ある範囲について権限を認める立場として承認しているかを問い合わせる。別の業界団体を承認することは、その団体を自分の配下へ置くこととは異なる。

また、AがBを、BがCを承認していても、それだけでAがCを承認するとは限らない。どこまで承認関係をたどってよいかは、参加者間のルールとして決める必要がある。階層的委任と制度間の承認を混ぜると、意図した範囲を超えて権限を認めてしまう。

認定を取り消したら、何が変わるのか？

どちらのモデルでも、取消後に何を受け入れるかを決めておかなければならない。特に、発行者の権限を止めることと、すでに発行された個々の修了証を無効にすることを区別したい。

例えば、研修会社Aが来月から事業をやめるとする。以後の発行を認めないとしても、昨年きちんと研修を終えた人の修了証まで無効にするかは別の判断だ。不正な発行が見つかった場合には、特定の修了証だけを無効にする対応も考えられる。

実装時には、少なくとも次の条件を決める。

決めること	階層的委任で確認する点	直接登録するリストで確認する点
認定の取消	上位の認定が無効になったとき、下位の権限をどう再評価するか	誰が対象の登録を停止し、照会結果へ反映するか
判定の時点	発行時と提示時のどちらの権限を要件にするか	過去の認定状況を調べるなら、履歴をどう保持するか
取得できない場合	認定の一部を取得できないときの扱い	リストやAPIが読めないときの扱い
証明書自体の状態	個別VCの有効期間・失効なども確認する	同左。名簿への掲載だけでは完了しない

TRQPには問い合わせの時点を指定する項目があるが、過去の権限を答えるには、回答側にその根拠となる記録が必要だ。「今は登録されていない」という結果だけから、発行当時も無権限だったとは判断できない。

通信障害についても、「確認できなかった」と「権限がない」を業務上は分けて扱いたい。確認できないときに受付を止めるか、保留するか、追加の確認を求めるかは、証明書を受け取る側が決める。

事業で選ぶなら、何から決めるのか？

私は、運営者がすべての発行者を直接審査でき、他組織への認定権限の委任も要らないなら、直接登録するモデルから始めるのがよいと考えている。元記事でも述べた方針だが、「小さく始めれば常に正しい」という意味ではない。

最初から地域や業界ごとに審査を任せる契約なら、その委任を表せる設計が要る。逆に、参加者が増えるだけで認定権限を分ける必要がないなら、件数の増加だけを理由に階層化しなくてもよい。

選定前には、以下の問いに具体的な組織名と担当業務を当てはめたい。

誰が発行者を審査し、その判断に責任を持つのか。
審査を他の組織へ任せる場合、証明書の種類や地域をどこまで限定するのか。
認定の取消を誰が受け付け、照会結果へいつ反映するのか。
他制度の認定主体を受け入れる場合、何を共通のルールとして合意するのか。

デジタル証明書の形式や問い合わせAPIがそろっても、この合意は残る。前回までに書いた「仕様の細分化が普及の負担になる」という問題に加え、信頼レジストリでは、審査基準や責任分担まで他の組織と合わせる必要がある。私は、ここを決めずに接続部分だけを標準化しても、業務で受け入れられる証明書は増えにくいと考えている。

Zenn で読む