メインコンテンツまでスキップ

パスワードから携帯可能な証明へ：2025年ビルダー向けWeb3アイデンティティガイド

· 約11分
Dora Noda
Dora Noda
Software Engineer

多くのアプリは依然として、ユーザー名・パスワード・集中型データベースにアイデンティティを紐付けています。このモデルは脆弱（漏洩リスク）、情報漏出（データ転売）、操作性が悪い（何度も KYC が必要）という問題があります。分散型識別子（DID）・検証可能証明書（VC）・アテステーションを中心とした新しいスタックは、ユーザーが自分に関する暗号証明を携帯し、必要な情報だけを開示できる未来を示しています。

本稿では、現状の全体像を整理し、すぐに実装できる実践的な設計図を提示します。

シフト：アカウントから証明書へ​

この新しいアイデンティティスタックの核は、ユーザーデータの取り扱いを根本から変える 2 つの W3C 標準です。

  • 分散型識別子（DIDs）：中央レジストリ（例：DNS）を必要としない、ユーザーが自己管理できる識別子です。DID は永続的な自己所有アドレスとして機能し、署名された「DID ドキュメント」へ解決されます。このドキュメントには公開鍵やサービスエンドポイントが含まれ、分散型認証を実現します。v1.0 標準は 2022 年 7 月 19 日 に W3C 推奨規格となり、エコシステムに大きな節目をもたらしました。
  • 検証可能証明書（VCs）：改ざん検知可能なデジタル形式で、例えば「年齢が 18 歳以上」「大学 X の学位を保有」「KYC が完了」などのクレームを表現します。VC Data Model 2.0 は 2025 年 5 月 15 日 に W3C 推奨規格となり、証明書の発行・検証のモダンな基盤が確立されました。

開発者にとっての変化は？ データベースに個人情報（PII）を保存する代わりに、ユーザーのウォレットが提供する暗号証明を検証します。選択的開示 などのプリミティブにより、必要な情報（例：特定国の居住証明）だけを要求し、元データ全体を見ることはありません。

既存のログイン手段とどう融合するか​

新しい世界は、既存のログイン体験を捨てる必要はありません。むしろ補完します。

  • パスキー / WebAuthn：フィッシング耐性のある認証手段です。パスキーはデバイスや生体認証（Face ID、指紋）に紐付く FIDO 資格情報で、主要ブラウザ・OS が広くサポートしています。パスワードレスでシームレスなログイン体験を提供します。
  • Sign‑In with Ethereum（SIWE / EIP‑4361）：ユーザーがブロックチェーンアドレスの所有権を証明し、アプリセッションに結び付けます。シンプルな nonce ベースの署名メッセージで、Web2 のセッションと Web3 の制御を橋渡しします。

ベストプラクティスは パスキー を日常的なサインインに、SIWE をウォレット連携が必要なクリプトアクションに組み合わせて使用することです。

証明書の発行・検証レール​

証明書を実用化するには、発行と提示の標準化された手段が必要です。OpenID Foundation が提供する 2 つの主要プロトコルがあります。

  • 発行：OpenID for Verifiable Credential Issuance（OID4VCI）
    OAuth 保護された API を通じて、政府機関や KYC プロバイダーなどの発行者からユーザーのデジタルウォレットへ証明書を取得します。柔軟性が高く、複数フォーマットに対応可能です。
  • 提示：OpenID for Verifiable Presentations（OID4VP）
    アプリ側が「証明要求」を行い、ユーザーのウォレットが応答します。従来の OAuth リダイレクトや最新のブラウザ API を介して実装できます。

実装時に目にする主な証明書フォーマット：

  • W3C VC with Data Integrity Suites（JSON‑LD）：BBS+ 暗号と組み合わせて高度な選択的開示が可能。
  • VC‑JOSE‑COSE と SD‑JWT VC（IETF）：JWT／CBOR エコシステム向けで、同様に選択的開示をサポート。

相互運用性は急速に向上しています。OpenID4VC High Assurance プロファイルなどが技術選択肢を絞り込み、ベンダー間統合をシンプルにしています。

DID メソッド：適切なアドレススキームの選択​

DID は単なる識別子であり、DID メソッド が信頼の根拠を定義します。代表的なものをいくつか紹介します。

  • did:web：所有するドメインを基盤にした DID。デプロイが非常に簡単で、既存のウェブインフラを信頼アンカーとして活用したい企業・組織に最適です。
  • did:pkh：ブロックチェーンアドレス（例：Ethereum アドレス）から直接派生する DID。ユーザーがすでに暗号ウォレットを持っている場合に、オンチェーン資産とアイデンティティを結び付けるのに有用です。

経験則：最低でも did:web（組織向け）と did:pkh（個人ユーザー向け）の 2 つをサポートし、標準 DID リゾルバライブラリで検索を行いましょう。新規メソッドを追加検討する際は、公式レジストリでセキュリティ・永続性・ガバナンスを確認してください。

組み込み可能な便利ブロック​

コア標準に加えて、以下のツールがアイデンティティスタックを強化します。

  • ENS（Ethereum Name Service）：yourname.eth のような人間可読名をブロックチェーンアドレスや DID にマッピングします。ユーザー体験向上、入力ミス削減、シンプルなプロフィール層の提供に役立ちます。
  • アテステーション：オンチェーン・オフチェーン問わず「何かについての検証可能な事実」を記録できる柔軟な仕組みです。例として Ethereum Attestation Service（EAS） があり、個人情報を公開台帳に残すことなく、レピュテーションや信頼グラフを構築できます。

規制の追い風​

規制は障壁ではなく加速装置です。最も重要なのは EU デジタルアイデンティティフレームワーク（eIDAS 2.0） で、2024 年 5 月 20 日 に EU 規則 2024/1183 として正式採択されました。全 EU 加盟国は無料の EU デジタルアイデンティティウォレット（EUDI） を提供することが義務付けられ、実装規則は 2025 年 5 月 7 日 に公表されています。これは公共・民間サービス双方でウォレットベースの証明書採用を促進する強力なシグナルです。

EU 以外でも、EUDI ウォレットとそのプロトコルはグローバルなユーザー期待とウォレット普及を形作るでしょう。

2025 年実装実績のデザインパターン​

  • パスワードレス第一、ウォレットはオプション：デフォルトは パスキー。安全でシンプル、ユーザーに馴染みがあります。暗号関連アクション（NFT 発行、支払い受領など）が必要なときだけ SIWE を導入。
  • 証明書を求め、書類は求めない：従来の書類アップロードを VC 証明要求（OID4VP） に置き換えます。運転免許証の代わりに「年齢が 18 歳以上」の証明や「居住国が X」の証明を要求。BBS+ や SD‑JWT など選択的開示に対応した証明書を受け入れます。
  • サーバーに PII を残さない：ユーザーが何かを証明したら、アテステーション または短命な検証結果だけを記録し、元の証明書は保存しません。オンチェーンアテステーションは「ユーザー Y が発行者 Z により D 日付で KYC を通過した」ことを監査可能にします。
  • 組織は did:web で発行者になる：企業・大学などは自ドメインを利用した did:web で証明書を発行し、既存のウェブガバナンス下で鍵管理が可能です。
  • ENS は名前として、アイデンティティではない：ENS はハンドルやプロフィールポインタとして活用し、実際の権威は証明書・アテステーションに委ねます。

スタータアーキテクチャ​

現代的な証明書ベースのアイデンティティシステムの設計例です。

  • 認証
    • デフォルトログイン：パスキー（FIDO/WebAuthn）。
    • 暗号連携セッション：Sign‑In with Ethereum（SIWE）でウォレット操作を認可。
  • 証明書
    • 発行：選定した発行者（KYC プロバイダー、大学等）の OID4VCI エンドポイントと統合。
    • 提示：Web またはネイティブアプリから OID4VP 証明要求を発行。W3C VC（BBS+）と SD‑JWT VC の両方を受け入れ可能に。
  • 解決・信頼
    • DID リゾルバ：did:web と did:pkh をサポートするライブラリを使用。信頼できる発行者 DID のホワイトリストを維持し、なりすましを防止。
  • アテステーション・レピュテーション
    • 永続記録：検証が必要なときは、ハッシュ・発行者 DID・タイムスタンプを含む アテステーション をミントし、元データは保存しない。
  • ストレージ・プライバシー
    • 最小化：サーバー側に保存する PII を極力削減。保存データはすべて暗号化し、TTL ポリシーを設定。エフェメラルな証明やゼロ知識・選択的開示を積極活用。

UX の学び​

  • 見えないウォレット：多くのユーザーにとって最適なウォレットは「意識しない」ものです。日常のサインインは パスキー でシームレスに処理し、ウォレット操作は必要時にだけコンテキストで提示します。
  • 段階的開示：一度に全情報を求めない。ユーザーの直近のゴールを解除する最小限の証明だけを要求し、選択的開示で余分なデータは取得しません。
  • キーリカバリは必須：単一デバイスキーに依存するとリスクが高まります。再発行やデバイス間ポータビリティを初期設計から組み込みましょう。SD‑JWT VC やクレームベースのホルダーバインディングがこの課題に対処します。
  • 人間可読ハンドルの活用：長い十六進アドレスより ENS 名の方が直感的でエラーが減ります。UX 向上に寄与しますが、真正性は裏側の証明書に委ねます。

次四半期に出荷すべき機能：実践的ロードマップ​

  • Week 1‑2
    • メインのサインインフローに パスキー を導入。
    • すべての暗号ネイティブアクションを SIWE チェックで保護。
  • Week 3‑6
    • OID4VP を用いたシンプルな「年齢または地域」ゲートをパイロット。
    • VC 2.0 の選択的開示対応（BBS+ または SD‑JWT）を受け入れ。
    • 「検証合格」イベントは アテステーション として記録し、PII はログに残さない。
  • Week 7‑10
    • パートナー発行者（例：KYC プロバイダー）を did:web でオンボードし、DID ホワイトリストを実装。
    • ユーザープロフィールに ENS 名 連携機能を追加し、アドレス入力の UX を改善。
  • Week 11‑12
    • 証明提示・失効フローの脅威モデルを実施。証明書期限切れや非信頼発行者などの失敗ケースをテレメトリで可視化。
    • プライバシーポリシー を明文化し、取得項目・保持期間・監査方法をユーザーに提示。

注視すべき急速変化領域​

  • EU EUDI ウォレット展開：実装・適合テストが進むにつれ、世界中の UX と検証機能に大きな影響を与えるでしょう。
  • OpenID4VC プロファイル：新しいプロファイルとテストスイートにより、発行者・ウォレット・検証者間の相互運用性が日々向上中です。
  • 選択的開示暗号スイート：BBS+ と SD‑JWT 用のライブラリや開発者向けガイドが成熟し、実装ハードルが下がっています。

構築指針​

  • 証明して保存しない：生の PII を保存するより、クレームを検証することをデフォルトに。
  • デフォルトで相互運用：複数の証明書フォーマットと DID メソッドを初期段階からサポートし、将来の拡張性を確保。
  • 最小限・開示：必要最小限のクレームだけを要求し、ユーザーに何をチェックし、なぜ必要かを明示。
  • リカバリは当たり前：デバイス紛失や発行者ローテーションに備え、堅牢なキーリカバリフローを設計。

FinTech、ソーシャル、クリエイタープラットフォームのいずれであっても、証明書ファーストのアイデンティティはもはや未来の概念ではなく、リスク低減・オンボーディング高速化・グローバル相互運用への最短ルートです。

Share on Twitter