そのVCの発行者を、なぜ信頼できるのか？信頼レジストリとTRQPの仕組みと実装例
はじめに
「私は医師です」と書かれたデジタル証明書を見せられたら、そのまま信用してよいのだろうか。 電子署名を確認できても、誰がその証明書を発行し、なぜその発行者に医師の資格を証明する権限があるのかは、もう一段調べる必要がある。 署名のある自称医師の証明書では、診察をお願いする気にはなれない。
これまでのDID/VC入門では、利用者が自分のIDや証明を管理し、別のサービスへ持ち運ぶ仕組みを紹介した。 今回は、受け取る側に残る「その発行者を、何の根拠で認めるのか」という問題だ。 Zennで書いた信頼レジストリの解説をもとに、2026年9月29日に確認した仕様と実装元の公開資料を加えている。
この記事のポイント
- 信頼レジストリでは、組織などに認められた権限と、その権限を認める主体の情報を参照する。
- TRQPは、その情報を共通の形式で問い合わせるプロトコルであり、参加者の審査や証明書の発行そのものは別に行う。
- 対応製品と公開実装は存在する。早期アクセスの製品、学歴証明のデモ、接続用の仕様を分けて紹介する。
- 共通のAPIだけでは、別の国や業界の資格を同じ意味で受け入れられない。審査基準や責任の合意も必要になる。
署名が正しければ、証明書も信用できるのか？
電子署名の検証と、発行者を業務上受け入れる判断は別の処理だ。 たとえば学歴証明なら、署名を検証したうえで、その署名鍵がどの大学に対応するのか、その大学が対象の学位を授与できる機関なのかを確かめる。 形式の整った証明書を作ることと、大学として認可されることには違いがある。
VC（Verifiable Credential） は、発行者や証明する内容などを記述し、改ざんなどを検証できるデジタル証明の仕組みだ。 DID（Decentralized Identifier） は、その発行者などを識別するために使える識別子で、採用する方式に応じて公開鍵などを参照できる。 DIDを持っているだけで、資格の認定機関として認められるわけではない。
W3CのVC Data Model 2.0の信頼モデルでも、発行者を信頼するかは検証者側の判断として扱われる。 W3CはWebの技術仕様を策定する標準化団体だが、世界中の大学や資格認定機関を審査してくれる団体ではない。 データ形式の標準化と、発行権限の確認には、それぞれ仕組みが要る。
| 確かめたいこと | 学歴証明での例 | 確認する情報 |
|---|---|---|
| 署名と改ざん | 発行後に学位名が書き換わっていないか | 発行者との対応を確認した鍵と、証明形式に従う署名 |
| 発行権限 | その大学が対象の学位を授与できるか | 認可する主体が管理する権限情報 |
| 個別の証明の状態 | この卒業証明が取り消されていないか | 採用方式に応じた失効や停止の情報 |
| 業務上の受け入れ | 自社の採用要件を満たす資格か | 採用企業の判断基準 |
信頼レジストリが主に扱うのは、この表の発行権限に関わる情報である。 照会結果が肯定でも、証明の内容が事実か、本人による提示か、期限内かといった確認は残る。
信頼レジストリには何を登録するのか？
信頼レジストリ（Trust Registry） には、誰が誰に、何についての権限を認めているかを記録する。 資格証明を使う場合は、「この認定団体が、この大学に、この種類の証明を発行する権限を認めている」という情報が一例になる。 発行者だけでなく、証明を検証する事業者などの権限も対象にできる。
権限を決める主体を、TRQPではAuthorityと呼ぶ。 政府に限らず、業界団体、企業、大学なども、参加者が合意した範囲でその役割を持ち得る。 参加条件、審査方法、権限を取り消す条件などを定める文書群が、ガバナンスフレームワークだ。
学歴証明の例なら、認定主体が大学を審査し、レジストリの運営者が審査結果を登録する。 採用企業のシステムは、その登録情報を参照して、大学に発行権限があるかを確認する。 審査する組織とサーバーを運用する組織は、同じでも別でもよい。TRQPの役割定義
ここで登録するのは、たとえば大学の発行権限であって、卒業生全員の氏名や成績を集める必要はない。 本人が提示した証明と、発行者の権限情報を分けて扱えば、権限を調べるだけの問い合わせに成績や氏名を送らずに済む。 ただし、問い合わせの記録から利用先や関心が推測される可能性はあるため、照会内容とログの保存範囲は設計時に検討する。
自己主権と認定機関は矛盾しないのか？
利用者が自分の証明を管理することと、その資格を誰が認めるかは、違う問題である。 SSI（自己主権型アイデンティティ） の考え方に沿って、卒業生が証明を自分のウォレットに持てても、学位の授与については大学の権限に依存する。 自分で保管できるからといって、自分に医学博士号を授与できるわけではない。
信頼レジストリも、一つの公的機関が運営する構成、業界ごとの構成、複数の制度が接続する構成を取り得る。 導入しただけで中央の管理者が消えるという話ではない。 「個人の情報を一か所に集めること」と「特定の資格について認定主体を決めること」を分けて考えると、SSIとの関係を理解しやすい。
TRQPは何を共通化するのか？
国や業界ごとに信頼レジストリがあっても、問い合わせ方がばらばらでは、接続するたびに専用の処理が増える。 TRQP（Trust Registry Query Protocol） は、その問い合わせと回答の形式を共通化するためのプロトコルだ。 既存の認定制度や内部のデータベースを丸ごと統一するものではない。
策定するTrust Over IP（ToIP） は、Linux Foundation Decentralized Trustの傘下で、デジタルな信頼関係を支える技術とガバナンスの仕様を開発するプロジェクトである。 ToIPの公式な成果物一覧では、TRQP v2.0は2026年4月15日リリースとして掲載され、承認済み仕様を参照できる。 本稿はそのv2.0を基準とする。
| 時期 | TRQPに関する出来事 |
|---|---|
| 2021年夏 | ToIP内でTrust Registry Task Forceが発足。健康証明を国や地域を越えて検証する需要が背景にあった |
| 2024年4月 | v2.0の実装者向けドラフトを公開 |
| 2026年4月 | v2.0をToIPの承認済み成果物としてリリース |
前二項はToIPの2024年の発表に基づく。 信頼情報を管理する制度にはTRQP以前からさまざまな系統があり、この年表は信頼レジストリ全体の起源を示すものではない。
発行権限と、別の認定主体の承認
v2.0の中心には二種類の問い合わせがある。 Authorizationは、ある主体が対象の組織などに権限を認めているかを調べる。 Recognitionは、ある主体が別の主体を、対象の範囲について権限を認める立場として承認しているかを調べる。
学歴証明なら、「認定団体Aは大学Bに学位証明の発行を認めているか」が前者である。 「こちらの制度は、外国の認定団体Aを、その範囲を管轄する主体として認めているか」が後者になる。 Recognitionは相手を配下に置くという意味ではなく、制度をまたいだ承認関係を扱い、一方向の場合もある。
技術者向けには、次の架空の例で読むと分かりやすい。 承認済み仕様に沿った説明用のリクエストであり、実在する大学のデータではない。
POST /authorization
Content-Type: application/json
{
"authority_id": "https://example.org/authorities/education",
"entity_id": "did:example:university",
"action": "issue",
"resource": "https://example.org/credentials/DegreeCredential"
}指定した認定主体のもとで、その大学に対象の証明を発行する権限があるか、という問い合わせだ。
issueや証明の種類の意味は、参加者が合意したルールに従う。
同じ項目名を使っていても、「学位」と「研修の受講修了」が混ざっていれば、相手の回答をそのまま利用できない。照会のスキーマ
「信頼のためのDNS」という比喩の範囲
DNSは、ドメイン名に対応するIPアドレスなどを問い合わせる仕組みだ。 TRQPが「DNS for Trust」と呼ばれるのは、信頼に関わる情報にも共通の照会方法を用意するという類似からである。 それだけで世界共通の認定機関や、すべてのレジストリを探せる仕組みが完成するわけではない。
TRQPは読み取り専用で、登録の審査や情報の更新は対象外だ。 内部の記録が通常のデータベースでも、既存の信頼リストでも、ブロックチェーンでも、必要な回答へ変換する構成を取れる。 この変換を行う仕組みをTRQP bridgeと呼ぶが、個々の変換方法はTRQP本体の仕様の範囲外である。ToIPの概要説明
TRQPを実装している例はあるのか？
TRQP対応の製品とオープンソース実装は、すでに公開されている。 ただし、ソフトウェアの公開、デモの構築、顧客の業務での運用は別々に確かめたい。 以下は公開資料で確認した状況であり、筆者が各ソフトウェアを実行して適合性を試験した結果ではない。
Affinidi Radix：製品としての信頼レジストリ
AffinidiのRadixの説明には、TRQP v2.0を実装し、発行者などの権限と、統治主体間の承認を照会できると記載されている。 製品の案内はEarly Access Programme、つまり早期アクセスの段階だ。 基になるRust製の実装も公開され、自分で運用する構成を検討できる。
同製品では、CSVファイルやDynamoDBなどに権限情報を保存する選択肢が説明されている。 照会用の共通APIと、その背後の保存方法が分かれていることが、製品構成からも分かる。 これを紹介する際は、性能に関する製品の説明を、実際の導入先で測った効果に読み替えないようにしたい。
Affinidiの学歴証明デモ：二段階の確認が見える
同社の教育分野の参照実装は、香港、マカオ、シンガポールを想定し、大学の証明を学生が持ち、別の地域の企業が確認する流れを示す。 説明には地域や大学の名称が登場するが、リポジトリはデモと学習用のプロトタイプであると明記している。 各政府や大学による本番採用の発表として読む資料ではない。
デモの企業側は、相手の地域の統治主体が自分たちの仕組みから承認されているかをRecognitionで確認する。 続いて、大学が対象の証明を発行する権限をAuthorizationで調べる。 電子署名が成立するかだけでなく、別の制度の発行者を受け入れる根拠を問い合わせているわけだ。
この参照実装は、信頼レジストリの用途を説明する教材として使いやすい。 「外国の証明書でもデータを読み込める」と「その発行者の権限を確認できる」の間に、どの処理が必要かを具体的に追えるからだ。
OpenWallet Foundation LabsのTRS：照会側を共通化する実装
TRS（Trust Resolving System）は、OpenWallet Foundation Labsで公開されているTypeScript製のプロジェクトである。 TRQPを使い、複数の信頼の仕組みに対する問い合わせを共通の窓口で扱う構成を示している。 公開リポジトリには、Hopaeの開発者がメンテナーとして記載されている。
READMEでは、OpenID Federation、X.509の証明書、EBSIのTrust Chainsなどを対象として挙げている。 一方で、分散したサーバー基盤の展開は計画として説明されている。 ここではOSSの設計と実装が存在する例として紹介し、列挙された接続先すべてで運用実績があるとは扱わない。
Ayra：複数の実装をつなぐための取り決め
Ayra TRQP Profileは、Ayra Trust Networkに参加する実装向けに、TRQPの使い方を具体化した仕様だ。
プロファイルとは、一般的な仕様に対し、参加者が共通して使う条件や追加のルールを決めたものである。
確認時点の版はv0.6.0-draftだった。
AyraはAuthorizationとRecognitionの両方のAPIを要求し、識別子やエラー応答などの条件も定めている。 これはRadixのような製品そのものとは違うが、異なる製品がつながるために何を合わせるかを読む資料になる。 プロファイルが公開されたことだけでは、ネットワーク全体の本番稼働までは確認できない。
| 取り組み | 記事で確認できること | 区別しておきたい点 |
|---|---|---|
| Affinidi Radix | TRQP対応製品の説明と公開実装 | 製品案内は早期アクセス |
| Affinidiの教育証明 | 国境を越えた権限確認の参照実装 | 政府や大学の本番導入事例ではなくデモ |
| OpenWallet Foundation Labs TRS | TRQPを使う照会システムのOSS | 分散サーバー基盤は計画として記載 |
| Ayra | ネットワーク参加者向けの接続条件 | プロファイルはドラフト。製品の運用実績とは別 |
共通のAPIがあれば、相互運用できるのか？
TRQPで問い合わせの形を合わせても、回答を業務でどう受け入れるかは参加者が決める。 たとえば、ある団体が「研修修了証」と呼ぶものを、別の団体が「国家資格と同等」と解釈したら、通信に成功しても認定の意味が食い違う。 APIの接続確認と、資格の意味の合意を並行して進める必要がある。
どのレジストリを信じるか
最初に問い合わせる認定主体は、受け取る側が決める。 証明を見せた相手が指定したサーバーから「この発行者は正当です」と返ってきただけでは、自己申告が一段増えただけになってしまう。 既に信頼すると決めた主体のガバナンス文書や識別子から、正当な照会先を確認する設計が要る。
TLSなどで接続先を認証し、応答が問い合わせた組織、資格、用途に対応しているかも確認する。 HTTPの成功応答を得たことと、その証明を採用してよいことを同じ条件にしない。 認可情報が取得できなかった場合は、不許可が確認された場合と区別して、保留や再確認などの扱いを決めておく。
いつの権限を確認するか
今日、大学がある証明を発行できるかという問いと、数年前に発行した時点で権限を持っていたかという問いは違う。 TRQPには時刻を指定する条件があるが、過去の照会に答えられる記録を保持する運用も必要だ。 大学の認可が失われた後に過去の卒業証明をどう扱うかは、資格制度と受け入れ先のルールで決める。
個別の証明書が取り消されているかも別に確認する。 権限の照会が成功したことを、証明書の失効確認の代わりにはできない。 証明の検証方式との関係は、DID/VCの技術仕様編でも説明した。
証明を持ち運ぶ思想と、制度をつなぐ作業
私は、DID/VCの普及を難しくしている理由の一つに、利用者がデータを持ち運ぶという思想と、細かく分かれた実装仕様の間の隔たりがあると考えている。 発行と提示の形式を合わせても、受け入れ先が発行者を認められなければ、持ち運んだ証明を仕事で使えない。 信頼レジストリの接続は、その次に必要になる作業だ。
TRQPには、問い合わせのためだけに個別の接続処理を作る負担を減らせる余地がある。 ただし、審査の基準、権限の意味、取り消し時の責任までAPIが決めてくれるわけではない。 実証で確認するなら、正当な発行者が通るだけでなく、権限のない発行者、対象外の資格、照会先が応答しない場合も扱い、業務の担当者と受け入れ条件を確かめたい。
よくある質問
ブロックチェーンは必要か？
必須ではない。 TRQPは内部の記録方式を指定しておらず、通常のデータベースなどを使った実装もある。
W3C VCを使うならTRQPも必須か？
必須ではない。 受け入れる発行者をあらかじめ設定するなど、別の方法で判断する構成も取れる。 複数の制度やレジストリと接続するときに、共通の照会方法を検討する理由が生まれる。
本番で広く使われているといえるか？
対応製品と公開実装の存在は確認できる。 今回調べた資料だけでは、具体的な導入機関と継続的な運用実績を伴う事例を十分に確認できなかったため、普及の規模までは評価しない。
まとめ
信頼レジストリは、デジタル証明の発行者に認められた権限を、受け取る側が調べるために使える。 TRQPは、その照会を共通化する方法の一つで、製品や参照実装を調べられる段階まで進んでいる。
導入を考えるときは、誰がどの証明を認め、その判断を誰が更新するかを書き出すところから始めたい。 ZenChAIneのDID/VC連載で扱ってきた「自分の証明を持ち運ぶ」という考え方を業務へつなぐには、受け取る側が確認できる権限情報と、受け入れ条件まで設計する必要がある。