Technical & Institutional Issues for VC Implementation in Public Sectors

本検証プロジェクト（Sorane: 空音）は、高精度なタイポグラフィとポスト量子暗号（PQC）を組み合わせたデータ基盤について、実装レベルの課題を整理するための試行的な取り組みである。本稿は、公的な証明書等をVCとして発行する際の実務的な論点を、実際のコード（本PoC）を通じて洗い出したメモであり、今後の具体的なシステム要件を検討する上での「技術的な叩き台」として作成したものである。

最新のステータス (2025-12-31): Red Team によるセキュリティ・アセスメント（v1～v7）を経て、パイロット運用に向けたガードレール（v2.4.0）の実装を完了した。詳細は Web/A Security Audit Index および Red Team Evaluation v8 (PoC Approval) を参照のこと。

---

Purpose and Scope of this PoC

本プロジェクトは、特定の完成された製品を目指すものではなく、デジタル証明書の実装において「どこに技術的な壁があるか」を把握するための、実装レベルのサンドボックス（実験場）である。

• 想定する活用シーン:
  • 公開情報のホスト: 公共機関のプレスリリースやオープンデータを改竄不可能な形でホストするOSSとしての最小構成の試行。
  • 機微な証明書の技術検討: 住民票や課税証明書、就業証明書、学生証など、対人（プライバシーを含む）の証明書をデジタル化する際の、技術的なReference（参照コード）としての提示。
• 本プロジェクトの立ち位置:
  • 発行システムそのものを構築するのではなく、IVS異体字の扱いやPQC署名など、共通的に直面する「実装上の難所」をどうクリアするかについての、たたき台となる実装例の提示。
  • 受理者による悪用防止や、デジタル上での文字の真正性など、実務者が技術的な議論を行うためのベースラインを提供するものである。

---

Institutional Governance and Root of Trust

公共機関が発行体となる場合、その「身元」と「権限」をデジタル上でいかに証明し、継続的に管理するかが最大の論点となる。

公認ドキュメントにおける署名の定義

• 論点: 公認ドキュメントに付与する署名は、日本の「電子署名法」における電子署名とどう整理すべきか。
• 本PoCの視点: 本プロジェクトにおけるVCの署名は、自然人の「意思表示」を担保する従来型の電子署名とは性質が異なる。むしろ、組織の真正性を証明する e-Seals (EU) や、Webサイトの信頼性を確保する SSL/TLS証明書、ソフトウェアの出所を保証する コード署名証明書 に近い、システムの自動処理による 「組織の証跡（機関検証）」 と捉えるべきではないか。
• トラスト基盤の親和性: did:web 等を通じて、既存のWebトラストチェーン（WebTrust等）と親和性の高い技術スタックを採用することで、汎用的なブラウザやツールでの検証可能性を多層的に担保する。

信頼の基点 (did:web)

• 論点: 発行体の識別子（ID）をどこに置くか。
• 本PoCでのアプローチ: 既存のインターネット基盤（DNS/TLS）と連動する did:web を採用する。発行体の公式ドメイン直下（/.well-known/did.json）に公開鍵情報を配備することで、WebPKIの信頼性をVCの信頼性に直結させる手法を検証した。
• 公共機関側の検討事項: ドメイン管理部門と情報システム部門の連携、および鍵のライフサイクル管理ルールの策定が必要である。

署名主体の階層構造

• 論点: 各発行体が個別に鍵を運用するか、中央機関が署名を代行するか。
• 本PoCでの構成: 技術的にはどちらも対応可能である。現実的には、事務帰属は個別の機関としつつ、署名基盤はクラウド等の検証済み環境に集約し、発行体は「署名指示」のみを行う 「委託署名モデル」 が、運用コスト・セキュリティの観点から一つの有力な選択肢となる。
• 公共機関側の検討事項: 各主体の権限担保（署名指示の真正性）と、共同運用によるコスト削減のバランスが重要となる。

証明書と署名の有効期限・長期検証

• 論点: VCそのものの有効期限と、それを保証するためのデジタル署名の有効期限（およびアルゴリズムの危殆化）をいかに切り分けるか。
• 公示文書への長期署名（LTV）の適用可能性:
  • 自治体の告示やプレスリリース等、数十年単位での真正性担保が必要な「公示情報」については、署名した際の鍵が失効した後や、暗号アルゴリズム（RSA/ECDSA等）が脆弱化した後でも検証可能である必要がある。
• 技術的課題と標準化状況:
  • VCネイティブなLTV標準の欠如: PDFにおけるPAdESのような、長期検証用の証跡をドキュメント内に包含する標準的な仕組みが、現時点のW3C VCコア仕様には明示的に存在しない。
  • 既存規格の転用: IETFで標準化されている Evidence Record Syntax (ERS) 等の証跡フォーマットを、VCのメタデータとしてどう統合するかが課題である。
  • C2PA等の他規格との連携: コンテンツの来歴を管理するC2PA等、より広義のドキュメント真正性規格とVCを組み合わせるアプローチが有望である。
• 本PoCの設計方針:
  • 対人証明書: 有効期間を短く設定し、オンラインでの即時検証（Status List）に頼ることで、署名の長期維持コストを抑制する。
  • 公示文書: 署名作成時に信頼できるタイムスタンプを付与するとともに、本PoCで採用した ポスト量子暗号（PQC） アルゴリズムを適用することで、将来的な量子計算機による解読リスクに対抗し、実質的な検証可能期間の延伸を図っている。

公示文書における永続的識別子（PID/DOI）の活用

• 論点: 自治体の告示や統計データ等の公開情報について、URLの変更等に左右されない永続的な識別（PID）を導入すべきか。
• DOI（Digital Object Identifier）の検討:
  • メリット: リンク切れの防止、引用・参照の確実性向上。学術分野で標準的なDOIを公文書に付与することで、外部のアーカイブシステムとの親和性が高まる。
  • 実装難易度:
    • 制度面: ジャパンリンクセンター（JaLC）等の登録機関への加盟と、適正なメタデータ管理体制の構築が必要となる（コストと事務手続が主）。
    • 技術面: 本SSGのような仕組みにおいて、フロントマターにDOIを保持し、ビルド時に登録機関のAPIと連携してメタデータを自動送信する仕組みを構築することは技術的に容易である。
  • 提案: データの真正性を担保するVCと、データの発見性・永続性を確保するPID（DOI）を組み合わせることで、公的に「二次利用」されるデータの信頼性が飛躍的に向上する。

法的用語と提示形態の定義

• 論点: デジタルデータを「原本」と呼べるか、また印刷物の効力をどう定義するか。
• 本PoCにおける暫定定義: 法令上、現時点で「デジタル原本」という概念は未確定であるため、表示上の文言を 「電子交付された内容の確認画面」 と定義し、誤解を招かない表現を検討した。
• 運用要件:
  • VP（Verifiable Presentation）提示の原則: スマートフォン等での「画面提示」およびその「デジタル検証」のみを法的効力のある「証明」と位置づける。
  • 印刷物無効の徹底: 印刷時には「複写無効」等のウォーターマークを強制し、地紋等のアナログ偽造防止技術に頼らないデジタル完結型の運用を前提とした。

---

Data Authenticity and Machine Readability

データの改竄防止（数学的真正性）だけでなく、その「意味」が正しく解釈される（セマンティックな真正性）必要がある。

国際標準 (W3C VC 2.0) との整合

• 論点: 独自のデータ構造に閉じず、いかにグローバルな検証ツールやウォレットと互換性を持つか。
• 検討方針: W3C VC Data Model v2.0 に準拠し、JSON-LD（意味定義）と CBOR/COSE（効率性）のハイブリッド構成を採用した。
• 公共機関側の検討事項: デジタル庁が推進する「ベースレジストリ」や、自治体システム標準化、各ドメイン（医療、教育等）の標準規格とのマッピングが必要か。

表記的真正性 vs 意味的真正性

• 課題: 年月日の「元号表記」や「全角数字」等の国内慣習と、国際的な機械可読性（ISO 8601等）のコンフリクト。
• 本PoCの対応: 内部データは機械可読な形式（例：2024-01-01）で保持しつつ、「署名対象のVCデータから、法令や様式に基づいた表記を動的に生成するレンダリングエンジン」 を構築した。これにより、表示内容とデジタル署名が1対1で対応する構造を確立した。

---

Authority and Typography in Presentation

公的文書には、一目でそれが正当なものであると認識させる「信頼のデザイン」が求められる。

正確な字形表示 (IVS)

• 論点: 固有名詞等に含まれる異体字をいかに正しく表示し、情報の真正性（表記の正確性）を担保するか。
• 本PoCの実装技術: Unicode Variation Sequences (IVS) および OpenType Cmap Format 14 をネイティブに処理する。外字（フォント置換）に頼らず、セマンティックな情報を保持したままで公認指定フォント等を用いた高精度レンダリングを実現し、文字化けや字形の不一致を防ぐ手法を検証した。

標準化未済文字（追加文字）の符号化方針

• 論点: 「行政事務標準文字」のうち、Unicodeに未採録の「追加文字」をデジタルデータ（VC）内でいかに扱うか。
• 本PoCでの試行: 外字領域（PUA）に一時的に割り当て、レンダリングに必要なグリフのみをサブセット化したWebFontとしてドキュメント内に動的に埋め込むことで、視覚的な再現性（見読性）を確保した。
• 今後の検討テーマ：メタデータの機読性との両立:
  • PUA維持案: データ（VCのClaims）上もPUAコードで保持する。視覚的には正確だが、第三者のシステムでフォントが欠落した場合に意味が消失するリスクがある。
  • JIS X 0213代替案: 検索や機械処理の利便性を優先し、JIS X 0213の範囲内にある「近似した標準文字」に正規化して保持する。この場合、表示上の真正性（正確な字形）とデータ上の正規化をどのレイヤーで分離・管理するかが課題となる。
  • ハイブリッド案: 原本性としてPUAコードを保持しつつ、検索・連携用の「正規化（代替文字）フィールド」をメタデータとして併設する構成の検討。

デジタル・ドキュメントとしての提示品質

• 論点: 紙のシミュレーション（スキューモーフィズム）に固執すべきか、デジタル最適化を図るべきか。
• 本PoCでの試行:
  1. 画面上: Webの利点を活かし、レスポンシブで検証状態を直感的に確認できるデジタルネイティブなレイアウトを試行。
  2. 印刷時: ブラウザの印刷機能と連動し、自動的に特定サイズ（A4等）の厳格な伝統的レイアウトに切り替わるシステムを検証。
• 重要性: 描画の乱れや不自然なフォントは、検証者に「偽造」や「不備」の疑念を持たせる要因となる。高精細なスタイリングはデジタル証明書の信頼性を構成する重要な要素である。

帳票様式のデジタル定義と保守の迅速化

• 課題: 従来のExcel配布や専用の帳票設計ソフト（SVF等）を用いた様式管理では、制度改正時の改修コストが高く、ベンダー依存（ロックイン）が生じやすい。
• Web技術による帳票再現の可能性:
  • 汎用性: モダンなCSS（Grid/Flexbox/Print CSS）を用いることで、専用ソフトに依存せずとも、従来の紙の様式をミリ単位の精度で再現可能である。
  • 機動性: 制度改正により項目が追加・変更された際、専用ソフトのバージョンアップや再配布を待つことなく、Web標準のコード修正（またはスタイルシートの更新）のみで即座に対応が可能となる。
• 機械可読な様式定義の必要性:
  • 様式のコード化: 帳票のレイアウト定義そのものを、YAMLやJSONのような機械可読なデータ形式として規定することで、人間向けの表示とシステム向けの処理を「共通の定義体」から生成するアーキテクチャへの移行が期待される。
  • 電子交付との共用: VCのメタデータ内に「このデータはこの様式定義を用いて表示すべき」という参照を含めることで、発行システムと検証アプリの間で全く同一の表示品質を保証することが可能となる。
• 今後の検討テーマ: 基幹システム側で保持している既存の設計データから、Webベースの様式定義をいかに自動変換・生成するか、その変換プロセスの信頼性確保が論点となる。

---

Environment and Multi-Device Coordination

実務的な事務手続きはPCで行われ、証明書の格納やマイナンバーカードの読み取りはスマートフォンで行われるという、デバイス間の乖離をいかに埋めるかが焦点となる。

ブラウザ完結と独自ソフトウェア依存の回避

• 論点: 複雑な事務手続きを行うPC環境において、専用ソフトウェア（インストーラー形式のアプリ等）の導入を最小限に抑え、いかにブラウザ標準機能のみでUXを完結させるか。
• 本PoCの視点: Webでのドキュメント提示を基本とし、OSやブラウザが提供する標準機能（WebAuthn等）を最大限活用することで、特定の実行環境への依存を低減するアプローチを重視している。

特定プラットフォームや寡占ソフトウェアへの依存回避

• 論点: 特定のベンダーが支配するソフトウェアやエコシステムに依存せず、オープンな標準をいかに維持するか。
• PDF（AATL）との比較:
  • PDF署名（AATL準拠）は実績があるが、その厳密な検証にはAdobe Acrobat等の特定の寡占的ソフトウェアが必要となるケースが多い。
  • 対して、WebTrustモデル（TLS/DNS）に基づく技術スタックは、複数の主要ブラウザが共通のセキュリティモデルで実装しており、特定のビューアに縛られにくい。
• ウォレットの相互運用性:
  • 特定の「専用ウォレットアプリ」でしか検証・保存できない状況は、将来的なベンダーロックインを招く。
  • W3C VCやOpenID4VCI/VP等の国際標準を採用することで、ユーザーが自身の好むウォレットを自由に選択できる「マルチベンダー環境」を確保することが重要である。
• 相互運用性確保が困難な理由と課題:
  • 「信頼の三角形」の不完全性: 技術的な「データ形式」の標準化（W3C VC等）は進んでいるが、どの発行体が「正当な権限を持つか」を定義する Trust Registry（信頼レジストリ） の仕様やリストの運用が国やドメインごとに乱立しており、これらを集約・横断的に参照する仕組みが不足している。
  • 実装プロファイルの乖離: 同じOID4VPを採用していても、欧州のEUDIプロファイルと他の地域の実装では、必須項目の解釈や暗号スイートの選択に細かな差異が生じ、結果的に「つながりにくい」事象が発生しやすい。
  • ハードウェア依存の壁: マイナンバーカード等のICチップ読み取りや、Secure Enclave（安全な領域）への鍵生成など、OS固有のハードウェア制御APIが統一されていないため、同じ仕様のウォレットでもデバイスによって動作が異なる。

スマホ（ウォレット）とPCの連携

• 論点: スマホ内のマイナンバーカード読み取り機能やウォレット機能と、PC上の事務ブラウザをどうシームレスに連携させるか。
• 検討テーマ:
  • CTAP: PCとスマホをBluetoothやUSB等で接続し、スマホを外部認証器として利用する標準規格の活用。
  • Passkeys / WebAuthn: 同一のiCloud/Googleアカウント等で同期されたPasskeyを活用し、デバイスを跨いだ認証・署名プロセスを簡略化する手法。
  • Cross-Device Flow: QRコード等を介したOIDC4VP（OpenID for Verifiable Presentations）等のプロトコルによる、PCブラウザからスマホウォレットへのセーフなリクエストとレスポンスの受け渡し。

サーバー型ウォレットの提供主体とエコシステム

• 論点: ウォレット（特にクラウド/サーバー型）の提供主体をいかに分散化し、情報が特定の事業者に集中管理されない環境を実現するか。
• 「靴ひも問題」と公共の役割:
  • ウォレットの普及は、発行される証明書の数（需要）と、それを受理する窓口（供給）の鶏と卵の関係にある。民間主導のみでは、初期のインセンティブ設計が難しく「靴ひも（bootstrap）問題」が生じやすい。
  • 公的機関が 「オープンな技術仕様」、「参照実装（Reference Implementation）」、および 「適合性テスト（Conformance Test）」 を提供し、品質を担保する仕組みが必要である。
• マルチプロバイダー環境の実現:
  • 公的機関がインフラの共通基準を整備した上で、複数の主体（公的機関・民間事業者等）が相互運用可能なウォレットを提供できる環境が望ましい。
  • これにより、ユーザーが信頼できる提供者を選択できるようになり、単一のプラットフォームによるデータの占有や独占を防ぐことが期待される。

---

Compatibility with AI Agents and Autonomous Negotiation

• 論点: 人間の介在なしに、AIエージェントが自律的に証明書を提示・検証できるか。
• AIエージェントによる自動提示:
  • 委任: 本人がAIエージェントに対し、特定の条件下で特定のVCを提示する権限を安全に委任する仕組み（Delegation証跡の付与等）が必要である。
  • 信頼のグラフ解析: エージェントが、提示されたVCの発行体が信頼できるものであるかを、DIDドキュメントや信頼リストを辿って自律的に判断する「信頼のグラフ解析」の実装が鍵となる。
• 課題: エージェントが誤って必要以上の情報を開示してしまう「過剰開示」のリスクや、提示先が正当なエージェントであるかを判定する「エージェント間の相互認証」が技術的な課題として残っている。

マルチ認証情報による提示の生成と標準化状況

• 論点: 複数の異なる発行体から得た複数のVCを組み合わせ、一つの証明（VP）として提示する際の標準化はどこまで進んでいるか。
• 標準化の進捗状況（2025年時点）:
  • 完了（勧告済み）: W3C VCデータモデル v2.0、およびOAuth 2.0ベースの提示プロトコルである OID4VP は主要な仕様が確定しており、商用環境での実装が可能となっている。
  • 実用化フェーズ: 複数のVCから特定の項目だけを抽出して提示する Presentation Exchange や、情報の要求方法を定める DCQL（デジタル資格情報照会言語）により、複数のVCを跨いだ複雑な証明の生成が技術的に標準化された。
• 残された課題: 異なるデータフォーマット（JSON-LD、SD-JWT、mdoc等）の間での「クロスフォーマットな検証ロジック」の共通化や、大規模な失効確認（Status List）の動的な同期手法については、依然としてパフォーマンスとプライバシーのトレードオフに関する検討が続いている。

---

Security and Privacy

必要最小限のデータのみを提示するという、デジタルならではのプライバシー保護機能である。

ホルダーバインディングと識別子の課題

• 論点: 本人宛の非公開証明書（住民票、税証明等）において、発行されたVCと「提示者が本人であること（ホルダーバインディング）」をいかに検証可能にするか。
• 背景と課題:
  • 既存手法の限界: 新型コロナワクチン接種証明書等では基本4情報（氏名・住所・生年月日・性別）が用いられたが、非公開を前提とする証明書では、これら情報の提示そのものがプライバシーの懸念となる場合がある。
  • 識別子の制約: 公的個人認証（JPKI）のシリアル番号等は、その使途が法律で厳格に規定されており、安易にVCの識別子として埋め込むことは困難である。
  • 悪用防止の必要性: 受理した第三者が、当該バインディング情報を別の用途に悪用（リプレイ攻撃等）することを防ぐ仕組みが不可欠である。
• 今後の検討方向:
  • PPID: 提示先ごとに異なる一時的な識別子を生成し、名寄せを防ぎつつ本人性を担保する手法の検討。
  • ZKP: 識別子そのものを開示せず、特定の秘密鍵を保持していることのみを証明するゼロ知識証明の活用。
  • カード代替電磁的記録との連携: マイナンバーカード等のICチップ内の情報（代替電磁的記録）と、発行されたVCをいかに法令に抵触せず、かつ機密性を保ったまま紐付けるかについての、実装レベルの論点整理が求められる。

選択的開示

• 論点: 資格証明や身元確認の際、必要な項目（例：年齢のみ）に限定して提示できるか。
• 技術スタック: SD-JWT または SD-CWT の採用を検討。
• 制度的課題: 既存の事務規定等に基づく「証明事項」の解釈と、デジタル上での「項目選択」をいかに整合させるかが重要な検討テーマとなる。

VPの提示・検証方法と検証者インターフェースの要件

• 論点: 検証者がVPを受理する際、対面・非対面の各シーンでどのようなインターフェース（UI/UXおよびAPI）を用意すべきか。
• 提示手法の分類:
  • 対面（モバイル間）: QRコードの提示、またはNFC/Bluetooth近接通信を用いたオフライン提示。
  • 非対面（Web）: ブラウザのリダイレクトを用いた「同一デバイス内連携」や、PC画面上のQRコードをスマホでスキャンする「クロスデバイス連携」。
• 検証者側に求められるインターフェース要件:
  • 要求定義の提示: Presentation Definition等を用いて、必要な情報のサブセット（例：氏名と生年月日のみ）を動的にリクエストする機能。
  • 検証エンジンの実装: 提示されたVPの署名（PQC含む）、発行体の信頼性（Trust List照合）、失効状態、および提示者と証明書の紐付け（ホルダーバインディング）を自動でバックエンド検証する。
  • UI/UX: 検証結果を「合格/不合格」だけでなく、信頼の根拠（どの自治体がいつ発行したか等）を人間が理解可能な形でグラフィカルに表示するビューア。
• 実務上の課題:
  • オフライン時の信頼担保: ネットワークが不安定な対面現場において、最新の失効リストを取得できない場合の「信頼の鮮度」をどう許容するか。
  • 検証側のなりすまし防止: 悪意のある検証者が偽の検証リクエスト（VPR）を送り、個人情報を不正に取得するリスク。検証者自身のDIDによる「検証者認証」の仕組みが必要となる。

暗号アルゴリズムの選定と現行ガバナンスとの親和性

• 論点: JPKI（公的個人認証）やGPKI（政府認証基盤）で標準的なアルゴリズムをVCにそのまま利用できるか、また次世代アルゴリズムへの移行の妥当性は何か。
• アルゴリズム特性の比較:
  • RSA-2048 (現行基準): 既存の政府・公共システムで広く採用されている。
    • 実装可能性: W3C VC標準（RsaSignature2018等）でサポートされており、技術的な実装は可能である。
    • 相互運用性の課題: 署名サイズが大きいため（256bytes）、オフライン提示用のQRコードが高密度になりすぎ、安価なカメラ等での読み取り精度が低下する懸念がある。また、欧州のEUDI Wallet等の最新の国際フレームワークではECDSAが優先されており、グローバルな相互運用性において「レガシー対応」が必要になる可能性がある。
  • ECDSA P-384 (高セキュリティ要件): RSAに比べ署名サイズが劇的に小さく、より高いセキュリティ強度を確保できる。GoogleウォレットやAppleウォレットなど、主要なモバイルプラットフォームでの親和性が極めて高い。
  • Ed25519 (本PoC採用): 高速かつ実装がシンプルで、サイドチャネル攻撃への耐性も高い。VC/DIDのエコシステムで事実上のデファクトとして推奨されている。
• 本PoCの選定理由と現行PKIとの関係:
  • 互換性: 現行のJPKI/GPKIのアルゴリズムをそのままVCに載せることは可能だが、モバイルファーストなUX（QRスキャンのしやすさ、オフライン検証等）を追求する場合、RSAよりもECC（楕円曲線暗号）系が適している。
  • 優位性: 今回採用した Ed25519 + ML-DSA のハイブリッド構成は、現在の軽量・高速な処理性能を維持しつつ、将来的な量子計算機への耐性（PQC）を先取りする「将来志向」の設計となっている。現行基準を維持しつつも、長期間の真正性担保が必要な公文書については、PQCへの段階的移行を検討すべきである。

ポスト量子暗号

• 課題: 量子コンピュータの台頭による、将来的な署名の偽造リスク。
• 本PoCの実装: 公認ドキュメントの長期的な真正性を担保するため、既存の楕円曲線暗号 (Ed25519) と次世代格子暗号 (ML-DSA-44) を組み合わせた ハイブリッド署名 を採用し、その実用性を検証した。

---

Sorane (空音) Project - Summary of Issues for Public Institutions - 2025-12-22 本ドキュメントは、本PoCを通じて得られた知見に基づき、公共機関によるデータ電子交付の社会実装に向けた検討項目を整理したメモである。