VC の課題と批判
Verifiable Credentials は有望な技術ですが、課題や批判も存在します。このドキュメントでは、VC の現状の問題点を整理します。
技術的な課題
1. 鍵管理の難しさ
ユーザーが秘密鍵を管理する必要がある:
┌─────────────────────────────────────────────────────────────┐
│ 従来（パスワード認証） │
│ │
│ パスワードを忘れた → 「パスワードリセット」で復旧 │
│ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ VC（秘密鍵） │
│ │
│ 秘密鍵を失くした → VC は使えなくなる │
│ 復旧手段がない（または複雑） │
│ │
│ 秘密鍵が漏洩した → なりすましが可能 │
│ 取り消しが必要 │
│ │
└─────────────────────────────────────────────────────────────┘
問題点:
- 一般ユーザーに「秘密鍵を安全に管理せよ」は現実的か？
- バックアップ方法が複雑（シードフレーズ等）
- スマホを失くしたらどうなる？
現状の対策:
- クラウドバックアップ（Apple/Google）→ でも中央集権的では？
- ソーシャルリカバリー → 複雑で普及していない
- 発行者に再発行を依頼 → 発行者への依存が残る
2. 失効確認の問題
失効確認のジレンマ:
オフライン検証を重視すると:
→ 失効情報を事前にダウンロード
→ 最新の失効情報が反映されない
→ 失効した VC が「有効」と判定されるリスク
リアルタイム失効確認を重視すると:
→ 毎回発行者にアクセス
→ オフラインで使えない
→ プライバシー漏洩（誰がいつ検証したか）
Status List の課題:
| 課題 | 説明 |
|---|---|
| プライバシー | Status List を見れば「失効が増えている」ことがわかる |
| スケーラビリティ | 大量の VC を発行すると Status List が巨大に |
| 更新頻度 | どのくらいの頻度で更新すべきか不明確 |
3. 相互運用性の問題
現状:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ JWT VC │ │ SD-JWT VC │ │ mdoc │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Wallet A │ │ Wallet B │ │ Wallet C │
│ (JWT のみ) │ │(SD-JWT のみ)│ │ (mdoc のみ) │
└─────────────┘ └─────────────┘ └─────────────┘
→ 異なるフォーマット間で互換性がない
→ Wallet ごとに対応フォーマットが違う
→ 検証者も複数フォーマットに対応が必要
問題点:
- W3C VC, SD-JWT VC, mdoc が並立
- どれが「標準」になるか不明
- 移行コストが高い
4. 選択的開示の限界
SD-JWT の選択的開示:
発行時に決まった単位でしか開示できない
例: 住所の開示
発行者が「住所」を1つの Disclosure として発行
→ 「都道府県だけ開示」はできない
発行者が「都道府県」「市区町村」「番地」を分けて発行
→ 事前に分割されていれば可能
→ でも発行者がどう分割するか次第
問題点:
- 発行者が適切に分割していないと細かい開示ができない
- 「21歳以上」のような派生情報は発行時に含める必要がある
- 柔軟性に限界
5. DID の信頼問題
DID は「誰でも作れる」:
did:key:z6Mk... ← これは本当に○○大学？
DID 自体には信頼がない
→ 結局「信頼できる発行者のリスト」が必要
→ 誰がそのリストを管理する？
結局 PKI に戻る問題:
| 方式 | 信頼の根拠 |
|---|---|
| 従来の PKI | ルート CA を信頼 |
| did:web | DNS + ドメイン所有者を信頼 |
| did:ethr | ？（誰を信頼する？） |
→ 「分散型」と言いつつ、信頼のアンカーは必要
運用上の課題
1. 普及の鶏と卵問題
VC が普及しない理由:
発行者: 「検証者が対応していないから発行しても使えない」
検証者: 「発行者が発行していないから対応しても意味がない」
ユーザー: 「使える場所がないから Wallet を入れない」
→ 誰も先に動かない
現状:
- 政府主導（mDL, eIDAS）で強制的に普及させようとしている
- 特定のエコシステム内（大学間、業界内）での限定的な利用
2. ユーザー体験の問題
現状の VC 提示フロー:
1. 検証者が QR コードを表示
2. ユーザーが Wallet アプリを起動
3. QR コードをスキャン
4. 開示する情報を確認
5. 承認ボタンをタップ
6. 検証完了
→ 物理的な免許証を見せるより面倒では？
問題点:
- ステップが多い
- アプリの起動が必要
- オフライン環境での使いにくさ
3. 法的・規制上の課題
| 課題 | 説明 |
|---|---|
| 法的効力 | デジタル署名の法的効力は国によって異なる |
| 責任の所在 | 発行者・Wallet 提供者・検証者の責任分担が不明確 |
| データ保護 | GDPR の「削除権」とブロックチェーンの永続性の矛盾 |
| 国際的な相互運用 | 国ごとに規制が異なる |
4. プライバシーへの懸念
「選択的開示」でも残る問題:
1. 発行者への情報漏洩
- 発行時に全情報を渡す必要がある
- 発行者は誰に何を発行したか知っている
2. 相関分析
- 同じ VC を複数の検証者に提示
- 検証者同士が共謀すると追跡可能
3. メタデータ
- いつ、どこで、誰に提示したかの履歴
- Wallet 提供者が知りうる
Unlinkability の問題:
理想:
検証者 A への提示と検証者 B への提示を紐付けられない
現実（SD-JWT）:
同じ JWT 署名を使い回す
→ 発行者と検証者が共謀すると追跡可能
対策:
- Batch Issuance（複数の VC を発行）
- BBS+ 署名（署名派生が可能）
→ でも複雑で普及していない
批判的な視点
1. 「解決策を探している問題」か？
批判:
「現状のシステム（パスポート、免許証、OAuth）で
十分機能しているのに、なぜ置き換える必要がある？」
反論:
- プライバシー保護（選択的開示）
- 発行者への依存を減らす
- デジタルネイティブな証明
再反論:
- プライバシーを気にするユ ーザーは少数
- 発行者への依存は許容されている
- 既存システムの改善で十分では？
2. 「自己主権」は幻想か？
「自己主権型アイデンティティ」の理想:
ユーザーが自分の ID を完全にコントロール
現実:
- 秘密鍵の管理はクラウド（Apple/Google）に依存
- 発行者がなければ VC は発行されない
- 検証者が受け入れなければ意味がない
- 政府や企業が主導している
批判:
「自己主権」と言いつつ、結局は既存の権力構造が残る
3. 複雑すぎる問題
VC エコシステムの複雑さ:
- W3C VC Data Model 1.1 / 2.0
- JSON-LD, JWT, SD-JWT, mdoc
- DID Core + 数十の DID メソッド
- OID4VCI, OID4VP, SIOP v2
- Status List, Bitstring Status List
- Data Integrity, BBS+, ...
→ 専門家でも全体を把握するのが困難
→ 実装コストが高い
→ 標準化が追いつかない
今後の展望
解決に向けた動き
| 課題 | 対策 |
|---|---|
| 鍵管理 | Passkey/WebAuthn との統合、クラウドバックアップ |
| 相互運用性 | OID4VC による統一的なプロトコル |
| 普及 | 政府主導の mDL, eIDAS 2.0 |
| UX | NFC, Bluetooth での簡易提示 |
| プライバシー | BBS+ 署名、Batch Issuance |
現実的な期待値
短期（1-3年）:
- mDL が一部の国・地域で実用化
- 特定ユースケース（教育、医療）での限定利用
中期（3-5年）:
- eIDAS 2.0 で EU 全体に普及
- Wallet の標準化が進む
長期（5年以上）:
- 物理的な証明書の置き換え
- 国際的な相互運用
※ ただし、どこまで普及するかは不透明
まとめ
VC の課題:
技術面:
- 鍵管理の難しさ
- 失効確認とオフラインのトレードオフ
- 相互運用性（フォーマット乱立）
- 選択的開示の限界
- DID の信頼問題
運用面:
- 普及の鶏と卵問題
- UX の複雑さ
- 法的・規制上の課題
- プライバシーへの懸念（Unlinkability）
批判:
- 既存システムで十分では？
- 「自己主権」は幻想では？
- 複雑すぎる
VC は万能ではない:
→ 適切なユースケースを選ぶ必要がある
→ 課題を理解した上で採用を検討する