Digital Credentials API × OpenID4VP ブラウザ完結型本人確認の実装知見（OAuth/OIDC Numa (Immersion) Workshop 2026）

2026/08/25 開催
OAuth/OIDC Numa (Immersion) Workshop 2026 発表資料

Digital Credentials API × OpenID4VP
ブラウザ完結型本人確認の実装知見
Android PoCで見えた可能性と課題

株式会社KDDIテクノロジー
佐々木 慎之介

Transcript

1. Digital Credentials API × OpenID4VP ブラウザ完結型本人確認の実装知見 — Android PoC で見えた可能性と課題 — 概要：W3C Digital Credentials API（DC-API）と OpenID for Verifiable Presentations（OpenID4VP）を組み合わせ、 Android 上で「ブラウザから一度も離脱せずに本人確認を完了する」フローを PoC 実装した。本発表では、SD-JWT 形式の資格 情報を Credential Manager に登録し、ブラウザ経由で Verifiable Presentation を生成・暗号化・検証するフローの実装詳細 と、得られた技術的知見を共有する。メタデータのみ登録＋動的 VP 生成という実装パターンの有効性、JWE 暗号化によるデータ 保護設計、iOS のドキュメントタイプ制約による課題などを報告する。 佐々木慎之介 / 株式会社KDDIテクノロジー 開発1部 OAuth/OIDC Numa (Immersion) Workshop 2026 — 2026年8月25日 1/6
2. 背景：ブラウザ認証における UX の断絶 現在、ブラウザから認証が必要な操作を行う際は Custom スキーマや App Links / Universal Links で認証アプリを起動する方式が一般的だが、いずれも「ブラウザ→ アプリ→ブラウザ」のコンテキストスイッチにより UX が断絶する。DC-API を活用すれば、OS の同意 UI をブラウザ上にオーバーレイ表示し、ユーザーがブラウザか ら離脱せずに認証を完了できる。 現状の課題 • ブラウザ→アプリ→ブラウザのコンテキストスイッチでユーザーが文脈を見失 従来方式との比較 観点 Custom スキー マ App Links等 DC-API ブラウザ完結 ❌ ❌ ✅ UX の断絶 あり あり なし フィッシング耐 性 ❌ なし △ ドメイン検証 ✅ オリジン検証 PC→スマホ う • Custom スキーマはフィッシングに悪用可能（任意のアプリが同じスキーマを 登録できる） • App Links / Universal Links はフィッシング耐性があるが、アプリ切替によ る UX 断絶は同様に発生する 個別実装 個別実装 QR+BLE 標準 未インストール 時 エラー/無反応 Web フォールバッ ク 選択肢に非表示 • PC→スマホ連携は標準化されておらず個別実装が必要 第三者連携 個別 API 個別 API OpenID4VP 標 準 DC-API による改善 暗号化 実装依存 実装依存 プロトコルで規 定 • アプリ未インストール時にエラーや無反応（Custom スキーマ）、またはWeb にフォールバック（App Links） • ブラウザから一度も離脱しない（OS の同意 UI がオーバーレイ表示） • オリジン検証によるフィッシング対策 • 未インストール時は選択肢に表示されないだけ（明確な UX） • PC→スマホは QR + BLE で標準対応（パスキーと同じインフラ） 2/6
3. PoC アーキテクチャ：OpenID4VP + SD-JWT on Android Android Credential Manager Holder API を用いてアプリをクレデンシャルプロバイダーとして登録し、ブラウザからの OpenID4VP リクエストに対して SD-JWT VP を動的生成・JWE 暗号化して返却するフローを実装した。Verifier サーバは AWS Lambda 上で復号→署名検証→nonce 照合→クレーム抽出を行う。 フロー概要 ① ブラウザ credentials.get() → ② Android OS マッチング+同意UI プロトコル構成 → ③ Holder アプリ 生体認証+VP生成+JWE暗号化 → ④ ブラウザ 暗号化VP取得 → ⑤ Verifier 復号+署名検証 検証環境 項目 採用技術 コンポーネント 技術 提示プロトコル OpenID4VP (openid4vp-v1-unsigned) Holder アプリ Kotlin / Android 14+ 資格情報形式 SD-JWT (dc+sd-jwt) Verifier サーバ Java 21 / Spring Boot 3.3.5 クエリ言語 DCQL インフラ AWS Lambda + API Gateway 暗号化 ECDH-ES+A256KW + A256GCM フロントエンド S3 + CloudFront (HTTPS) 署名 ES256 (ECDSA P-256) ブラウザ Chrome 148+ / Edge 設計判断：メタデータのみ OS に登録し、SD-JWT VP はリクエスト時に動的生成する方式を採用。ストレージに資格情報を保持せず、端末盗難時のデータ漏洩リスクを 軽減しつつ常に最新情報を提示可能とした。 3/6
4. セキュリティ実装：データ保護設計 VP には個人情報（電話番号等）が含まれるため、ブラウザの JavaScript に内容が露出しないよう Verifier の一時公開鍵で JWE 暗号化して返却する。Device Binding（KB-JWT）、nonce によるリプレイ防止、選択的開示によるデータ最小化を組み合わせた多層的なセキュリティ設計を実装した。 実装したセキュリティ対策 信頼チェーン（4層構造） 🔒 JWE 暗号化 VP をブラウザに露出させない 🔑 一時鍵使い捨て 毎回 EC P-256 鍵ペア生成 🛡️ nonce ワンタイム 5分TTL+使用後即削除 📱 Device Binding KB-JWT でデバイス所持証明 ② Holder 署名（Key Binding JWT） 👤 選択的開示 要求属性のみ提示 → 提示者が発行された端末であると証明 ⚡ JWK 鍵検証 Invalid Curve Attack 対策 🧹 メモリゼロ化 中間鍵を使用後破棄 ✅ Verifier 認証 client_id 許可リスト ① Issuer 署名（SD-JWT 本体） → 資格情報が正当な発行者によるものと証明 ③ nonce 照合 → 今回のリクエストへの応答であると証明 ④ JWE 暗号化 → Verifier のみが VP 内容を閲覧可能 暗号化フロー ECDH鍵合 意 → HKDF KEK導 出 → AES Wrap CEK → AES-GCM 暗号 化 4/6
5. PoC から得られた知見と課題 同一デバイスフロー（Android Chrome → アプリ）およびクロスデバイスフロー（PC Chrome → QR+BLE → Android）双方で、資格情報登録から VP 生成・暗号 化・復号・署名検証・クレーム抽出まで全フローの動作を確認した。一方、iOS の制約やエラーハンドリングの難しさなど本番適用に向けた課題も明らかになった。 ✅ 全検証シナリオで動作確認 ⚠️ iOS の制約（最大のブロッカー） メタデータ登録、DC-API マッチング、生体認証、VP 生成、JWE 暗号化、サーバ側 Apple は DC-API で扱えるドキュメントタイプを mdoc 4 種（mDL、マイナンバー 復号・署名検証・nonce 照合・クレーム抽出の全ステップが正常動作。クロスデバイ カード等）に限定。独自の SD-JWT 資格情報は登録不可。Android 先行＋iOS スフロー（PC→QR→BLE→Android）も成功。 フォールバックが現実的。 ✅ メタデータのみ登録＋動的生成方式の有効性 ⚠️ エラーのプライバシー保護設計 資格情報を保存せず、DC-API 呼び出し時に電話番号を取得し SD-JWT VP を動的生 Chrome は「キャンセル」と「資格情報なし」を同じ NotAllowedError で返す 成する方式で問題なく動作。ストレージ初期化リスクを回避し常に最新データを提示 （ウォレット有無を漏らさない設計）。ユーザーへの適切なガイダンスに工夫が必 可能。 要。 PoC → 本番化に向けた主要課題 課題 PoC 本番で必要な対応 VC 発行者 アプリが自己署名で動的発行 Issuer サーバ + JWKS エンドポイント リクエスト真正性 openid4vp-v1-unsigned openid4vp-v1-signed へ移行 セッション管理 Lambda インメモリ（コールドスタートで消失） DynamoDB 等で外部化 署名検証 アルゴリズム確認のみ（ES256） JWKS から公開鍵取得し暗号的検証 5/6
6. まとめ DC-API + OpenID4VP + SD-JWT の組み合わせにより、Android 上でブラウザ完結型の本人確認が実現可能であることを PoC で実証した。Custom スキーマ方式の 課題（UX 断絶、フィッシングリスク、クロスデバイス非対応）に対し DC-API が有効な解決策を提供することを、実装コードとアーキテクチャを交えて示す。 本発表の要点 • DC-API + OpenID4VP + SD-JWT により Android でブラウザ完結型本人 確認が実現可能 • Custom スキーマ方式比で UX 改善（コンテキストスイッチ解消）と セキュ リティ向上（オリジン検証、JWE 暗号化、選択的開示）を両立 • メタデータのみ登録＋動的 VP 生成の実装パターンがセキュリティと運用性の プラットフォーム別 実現性 プラットフォーム 実現性 備考 Android (Chrome) ✅ 可能 全シナリオ対応 PC → Android ✅ 可能 QR+BLE クロスデバイス iOS (Safari) ⚠️ 制約 mdoc 4種のみ 第三者連携 ✅ 可能 OpenID4VP+JWKS 両面で有効 • iOS は独自 SD-JWT 資格情報に非対応 → Android 先行戦略が現実的 • 7カテゴリ・30以上のユースケースで想定リスクと対策を検証済み 関連仕様 • W3C Digital Credentials API (Working Draft) • OpenID for Verifiable Presentations 1.0 想定する聴講者へのメリット • DC-API を自社サービスへ適用する際の技術的判断材料 • OpenID4VP + SD-JWT の実装時に遭遇する具体的な課題と解決策 • IETF SD-JWT VC (draft-ietf-oauth-sd-jwt-vc) • Android Credential Manager Holder API • RFC 7516 (JWE) / RFC 7518 (JWA) • Android / iOS のプラットフォーム差異への対応戦略 6/6