EUDIWの枠組みを出発点に民間エコシステムの在り方を考える（OAuth/OIDC Numa (Immersion) Workshop 2026）

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

EUDIWの枠組みを出発点に民間エコシステムの在り方を考える
引き算で導くプロファイル

ソフトバンク株式会社
小松 隆行

株式会社Maximax
小西 優貴

Transcript

1. OAuth/OIDC Numa (Immersion) Workshop 2026 EUDIWの枠組みを出発点に民間エコシステムの在り方を考える 引き算 − で導くプロファイル 2026年 8月 25日 ソフトバンク株式会社 小松 隆行 / 株式会社Maximax 小西 優貴
2. 本日の流れ ①小松 IDフェデレーションモデルでの民間ビジネスにうっすら抱いている課題感 IHVモデルなら解決することはできるのではないか？という思いつき ②小西 ロールモデルとしてEUDIWにおけるトラストの解説 ③小松 ②を受けて実際どうなのか？民間ユースケースベースでの机上検証の話 2
3. IHVモデルを民間ビジネスに活かせないか？ ▪ 現在地：グループ企業内のコンシューマID連携ビジネス 顧客基盤が複数並立する中で、これまで経済的なシナジーを生む源泉となってきた ”IdP-RP型フェデレーション“ ID連携モデル ▪ ID連携ビジネスで直面してきた課題 接続先が増えるたびに個別開発を実施。契約、セキュリティ、顧客への個別情報提供同意等、企業間の個別調整コストが累積 ▪ IHVモデルへの着目 ユーザー自身がWalletを介してIDデータを保持して自律提示する仕組みを取れば 何百社規模になったとしても参加・離脱できるスケール可能な接続形態が作れるのではないか？？？ IdP/RP IdP/RP IdP/RP IdP/RP 3
4. IdP-RP型フェデレーション（ID連携モデル）とウォレット型フェデレーション（IHVモデル）の比較 IdP-RP型フェデレーション（ID連携モデル） ウォレット型フェデレーション（IHVモデル） ユーザー中心性 属性の提示・同意選択の形式がID連携企業単位でばらつきやすく ユーザーが自身のデータの共有内容や取り扱いを一貫して把握しにくい 属性の提示・同意選択の形式をウォレットに集約しやすく、ユーザーが「何を提示する か」を理解して選べる一貫した体験を構成しやすいのでは？という期待 アクセシビリティ 画面・手順が連携単位でばらつきやすく、代替手段やサポート導線が個別化する ウォレット中心の体験となるため、代替手段やサポートを含む体験を全体として整備で きれば、一貫性を確保しやすいのでは？という期待 相互運用性 OIDC等の標準により一定の共通化は可能だが、 プロファイルが揃わないと、連携単位で差分が残る 共通ルール／共通検証方式／共通データ形式に寄せやすく、 接続の型を揃えやすいのでは？という期待 プライバシー IdP・RP側に属性が集まりやすく、取得・保持範囲が企業目線で拡大しがち 必要最小限の取得・保持に寄せやすいのでは？という期待 セキュリティ セキュリティ要件・監査観点がID連携単位で個別対応になる 全体統制が効きにくい（※） 要件や運用を共通ルールとして定義しやすいのでは？という期待 （ただし、共通整備が不足するとリスクが顕在化しそう） ガバナンス 責任分界・監査・障害対応／変更対応が連携単位で個別化する（※） 役割に沿って整理しやすく、参加要件・遵守・監査等を共通ルールとして整備しやすい のでは？という期待 データ利活用 （企業目線） IdP・RP側にデータを集約しやすく、統合分析・施策に接続しやすい データ収集は原則最小限取得に寄るためRP側に集約しにくい 利活用はユースケース単位で個別の同意設計が必要 拡張性 仕様・契約・運用調整が連携単位で発生しやすく、調整が累積しやすい 調整を共通ルール／共通検証方式に集約しやすく、追加参加を同じ型で処理しやす いのでは？という期待 初期 既存連携の延長で開始しやすく、初期負荷は相対的に小さい 方式・運用（TF/参加要件等）の立上げ整備が必要で初期負荷が高い想定 運用 ID連携箇所の増加で個別調整・運用が累積しやすく、高止まりしてしまう 共通仕様化できれば、追加参加の費用を下げやすそう??? コスト （※）トラストフレームワークによる統制が初期から必要 4
5. 身も蓋もない結論（仮） 要は最初期から「大局観」をもってアーキテクチャを組めているか？ 5
6. IHV型モデル メリット 【エコシステム形状】 Issuer/Verifierが疎結合 スケールしやすそう！ - Issuer/Verifier（発行元/受け入れ先）が複数増えても共通化した提示・検証の仕組みでスケールする - Verifierが検証時にIssuerの可用性に依存しない - 複数VCの組合せ提示による束ね提示が可能 【法務観点】個人情報の第三者提供が不要（？） - Idp-RP事業者間のAPI送信は「個人情報の第三者提供（or 共同利用）」に該当し、明示的同意や記録作成義務が発生する - IHVモデルは Issuerから本人への「交付」と、本人からVerifierへの「提示」となるため「第三者提供」のバイパスになりうる 【顧客視点：プライバシー】ユーザ中心性の遵守 - ウォレットから直接データが提示されるため、Issuer側は利用状況を検知できず、行動履歴がIdP側に中央集約されるリスクを排除 - 必要項目のみ／条件充足の事実のみ（例：20歳以上）を提示する運用がUX上可視化されるため、企業側への強制力が働く 6
7. IHV型モデル デメリット 【企業視点：データ利活用】ビジネス上の制限 - UX上、プライバシー保護・データ最小化が担保されるような力学が企業側に働くため、 事業者（Verifier）側での属性データの恒常的な集約・一元管理が困難 - 匿名加工を施した顧客分析、ターゲティング等への活用といったユースケースごとに個別の例外設計が必要となる。 【初期コスト】共通インフラ立ち上げコストの重さ - スケーラビリティ・インフラ正常性を担保するための制度・運用・技術を規定する「トラストフレームワーク」策定が不可欠 ガバナンス主体の設立、アクター登録・ステータス管理、検証基盤構築等の多大な初期投資が必要 【運用】例外処理（紛失・リカバリ等）カスタマーサポートの複雑化 - ユーザーのデバイスに資産（秘密鍵・VC）を持たせるため、紛失、盗難、機種変更時の確実な無効化 本人確認のやり直し、回復・再発行手順等、企業による顧客サポートの運用が複雑化する 7
8. プロトコルの技術規格を統一するだけではビジネスは成立しない ビジネスを成立させるためには技術・ルール・運用・監査の成立が必要 結局必要不可欠な「トラストフレームワーク」という枠組… とはいえ（まだ希望は捨ててはいない） → IHVモデルの先行事例であるEUDIWを勉強することでショートカットできるのではないか? 8
9. 本日の流れ ①小松 IDフェデレーションモデルでの民間ビジネスにうっすら抱いている課題感 IHVモデルなら解決することはできるのではないか？という思いつき ②小西 ロールモデルとしてEUDIWにおけるトラストの解説 ③小松 ②を受けて実際どうなのか？民間ユースケースベースでの机上検証の話 9
10. EUDIWとは・・・ EUの全27加盟国で統一された基準・制度の 中でVC(特にID)とDIWを普及する取り組み 電子署名もありますが今回は割愛 10
11. 統一された基準や制度？ IHVモデルは一見、複雑ではない Wallet Provider ウォレット提供者 提供 発行 Issuer VCの発行者 管理 Holder VCの保持者 VC VP Issuer sign Holder sign 提示 Holderの署名 Issuerの署名 VCの検証者（RP） をそれぞれ検証して受け入れ Verifier 11
12. 統一された基準や制度？ しかし、実運用を考えると、セキュリティ・プライバシー面のリスクや脅威が無数に出てくる Wallet Providerは 信頼できる？ Wallet Provider ウォレット提供者 プロトコルは安全？ 対応状況は？ ウォレットのHW／SWは安全？信頼でき る？ 提供 プロトコルは安全？ 対応状況は？ Issuer信頼できる？ Verifierは信頼できる？ 発行 Issuer VCの内容信頼できる？ 発行手続き信頼できる？ 提示 Holderの署名 Issuerの署名 VCの検証者（RP） をそれぞれ検証して受け入れ Holder VCの発行者 VC 管理 Verifier VCの保持者 他のアクターがきちんと 機械処理できる形式？ Issuer sign Issuerの署名信頼できる？ VP Holder sign 正しいHolderであると信頼できる？ 他のアクターがきちんと 機械処理できる形式？ Holderの署名信頼できる？ 12
13. 統一された基準や制度？ ARF（Architecture Reference Framework）における技術仕様・トラストフレームワークの策定 13
14. 統一された基準や制度？ ARFは、これらリスク等に高いレベルで、同じ基準で対応できるようにするための中心的取組の一つ ETSI標準 eIDAS 1.0 EUDIW関連の上乗せ CEN標準 OIDF IETF W3C ISO/IEC eIDAS 2.0 CENELE C標準 技術詳細を規定 様々な下位法 欧州標準 法的枠組み 国際標準・仕様 整合性維持 指定・参照 ARF 参照実装 指定・参照 技術仕様 定義 指定・参照 指定・参照 Recommendation 2021/946 Toolbox ※ARF = Architecture Reference Framework。 14
15. 具体的論点の紹介：VCをやり取りするプロトコル OID4VCI/VP仕様をベースにHAIPを必須化＋独自仕様で要件をさらに具体化・高度化 ETSI TS 119 472シリーズ HAIP OID4VCI OID4VP ISO 18013-5も。 15
16. 具体的論点の紹介：VCをやり取りするプロトコル OID4VCI（発行） プレーン（OID4VCI 1.0） HAIP 1.0 ETSI TS 119 472 PKCE 推奨 必須（S256） ＝（HAIP のまま） PAR 推奨 必須 WIA を添付 DPoP 推奨 必須 ＝（HAIP のまま） クライアント認証 認証しない選択も可（pre-authorized では明示的に 任意）。方式は IANA レジストリから自由に選択 認証は必須。方式は Wallet Attestation （OID4VCI Appendix E）を推奨 WIA に確定（Wallet Provider が署名したウォレットアプリの完 全性証明） Issuer の身元と登録内容 署名付きメタデータの仕組みはあるが使用は任意。信頼確 立の手段はスコープ外 エコシステムが TLS を超える Issuer 認証を求める なら必須 無条件に必須。署名は access certificate、届出内容も同梱 グラント 認可コードと pre-authorized の2つ、選択は自由 認可コードを必須（pre-authorized には言及な し＝任意のまま） ウォレットは両方、Provider は一方以上（HAIP より緩い）。 PID の pre-authorized は対面のみ Credential Format 形式ごとのプロファイル、選択は自由 SD-JWT VC か mdoc の少なくとも一方 x509_attr・vc+jwt・vc+sd-jwt を追加（扱う場合） SD-JWT VC の Issuer 鍵解決 JWT VC Issuer Metadata（iss の well-known か ら鍵を取得。任意）と x5c（証明書を同梱）の2方式 x5c に一本化 適格 EAA は x5u + x5t#S256 を必須で追加（x5c は 472-1 上は推奨） Embedded Disclosure Policy – – 新設。RP が満たすべき条件を Issuer Metadata で渡す 16
17. 具体的論点の紹介：VCをやり取りするプロトコル OID4VP（提示） プレーン（OID4VP 1.0） HAIP 1.0 ETSI TS 119 472-2 RP の識別と認証 RP の名乗り方が7種。型によって鍵の入手経路が 違い、署名できない型もある x509_hash に一本化（証明書とチェーンを x5c で運ぶ）。証明書プロファイルはスコー プ外 x509_hash を無条件。証明書は access certificate（事 前登録の上で発行される証明書） RP の登録情報 – – registration certificate （事前登録の上で発行される証 明書）を verifier_info に載せる 要求の署名 任意（平文パラメータで渡せる） JAR で署名を必須 Request Object は JWS 署名つき JWT 要求の渡し方 値渡しと参照渡しのどちらでも request_uri（参照渡し）を必須 値渡し禁止、request_uri_method も必須 応答モード OID4VP が定義するのは5種。既定はブラウザ経由 。直接 POST と DC API にそれぞれ暗号化版あり 暗号化版の2つのみ ブラウザ経由は× direct_post.jwt を明示指定 セッション固定への対処 一回限りの秘密（Response Code）を戻り URL （redirect_uri） に載せ、応答取得時にそれを要 求する方式を提示。採用は任意 左記の戻り URL を必須化し、戻らない場合 や別セッションで戻った場合は提示を拒否 提示を受理したら必ず redirect_uri を返す（HAIP は same-device の場合のみ） Credential Format 形式ごとのプロファイル、選択は自由 SD-JWT VC か mdoc の少なくとも一方 許容 format 値を5種に固定（X509-AC の提示プロファ イルは未完） 提示はリダイレクト方式を前提に記載。Digital Credentials API方式もある。 17
18. 具体的論点の紹介：DIWをインストールするハードウェアの要件 署名操作が確実に本人によるものであることを保証できなければならない＝鍵管理性能の高さがポイント WSCD (Wallet Secure Cryptographic Device) Keystore ⚫ HSM、スマートカード、eSIMなどのレベル ⚫ iPhoneのSEなど ⚫ Common CriteriaのAVA_VAN.5 ⚫ PID（身分証明書）など高い保証が必要なVCの 法的要件には届かないが、それ以外のVCなら OK ⚫ 一般的スマホで対応できるか？ ⚫ 全ユーザにそれ期待できるか？ ⚫ ドイツ政府は代わりにクラウドHSMを運用 必須 任意 18
19. 具体的論点の紹介： Issuer、Verifierの信頼性保証 どうDIW/VCの世界で信頼を仕組み化するか＝事前登録制度と証明書、Trusted List 証明書が正しいか確認し、Issuer・Verifierを信頼 Issuer 証明書 VCの発行者 届出 DIWと通信時に見せる 証明書 Holder VCの保持者 国の機関 証明書 Verifier VCの検証者（RP） 届出 DIWと通信時に見せる 証明書 ↑の証明書の発行者の正当性と検証用情報が確認できるリスト（Trusted List） 他にも、Wallet Providerが加盟国経由で届出＋リスト掲載が必要だったりと色々あり。 19
20. 具体的論点の紹介： Issuer、Verifierの信頼性保証 法的に適格（Qualified）なIssuerであるためには、第三者評価を伴う認証取得＋定期監査が必要 評価機関 認定 認定機関 審査・監査 Issuer VCの発行者 届出・確認・登録 Holder VC VCの保持者 VC Issuerの署名＋適格性を検証 Verifier VCの検証者（RP） Issuerの署名＋適格性を検証 国の機関 適格Issuerの現在の状態（＋Issuer署名検証用の情報）が記載されたリスト（Trusted List） 20
21. 具体的論点の紹介：VCの中身の設計や運用をどうするか なんでもかんでも詰めることはできないし、ポンと一枚発行しておしまい、ではない 含める属性情報の最小化 選択的開示の対象属性 Holder Binding要否/強度 提示可能回数の制限有無 有効期限の長さ 失効管理はどうするか ・・・ 21
22. 具体的論点の紹介：VCの中身の設計や運用をどうするか Attestation Rulebook（VC自体の設計書のようなもの）を見てみる PID（ARFのAnnex） ドイツのPID（ドラフト） ジムの会員VC （Mirko Mollik作のサンプル） これが見やすいと思います 22
23. 具体的論点の紹介：VCの中身の設計や運用をどうするか みれない方向けに内容のイメージ 23
24. 具体的論点の紹介：VCの中身の設計や運用をどうするか PIDを「お手本」と見た時、民間の個別のユースケースではどのような設計・運用にすべきか？ PID ジムの会員 マストの属性 姓／名／生年月日／出生地／国籍／顔写真 ジム名／会員ID／会員種別 選択的開示 できない属性 SD-JWT-VCの仕様上不可能なものだけ 例えば、valid_from/untilは不可 Holder Binding 必要。WSCDのレベル。 必要。WSCDでなくてよい。 有効期限 提示回数制限/ バッチ発行 ルールブック 紙の証明書自体は数年。VC自体は数日～数週間など。 ドイツ：証明書は10年、VCは60日→自動入れ替え（2年） 使い捨て＋バッチ発行（複数枚発行）前提 ドイツ：使い捨て×SD-JWT/mdoc各5枚発行→自動補充（2 年） 1年 一枚のVCを期限まで制限なしで使い回す？ ポリシー PID ドイツのPID ジムの会員VC 24
25. 具体的論点の紹介：VCの中身の設計や運用をどうするか 特に、プライバシーリスクがユースケースにどう降りかかるかが設計・運用を左右 PID ジムの会員 マストの属性 姓／名／生年月日／出生地／国籍／顔写真 ジム名／会員ID／会員種別 氏名はいらない？ ない方がよい？ 選択的開示 できない属性 SD-JWT-VCの仕様上不可能なものだけ 例えば、valid_from/untilは不可 valid_fromは要る？ Holder Binding 必要。WSCDのレベル。 必要。WSCDでなくてよい。 そもそもバインディング要る？ 有効期限 提示回数制限/ バッチ発行 ルールブック 紙の証明書自体は数年。VC自体は数日～数週間など。 ドイツ：証明書は10年、VCは60日→自動入れ替え（2年） 使い捨て＋バッチ発行（複数枚発行）前提 ドイツ：使い捨て×SD-JWT/mdoc各5枚発行→自動補充（2 年） 1年 1年間でこのVCを何回・どれくらいの数のRPに提示する？ 一枚のVCを期限まで制限なしで使い回す？ 1年間で（以下略） ポリシー PID ドイツのPID ジムの会員VC 25
26. 本日の流れ ①小松 IDフェデレーションモデルでの民間ビジネスにうっすら抱いている課題感 IHVモデルなら解決することはできるのではないか？という思いつき ②小西 ロールモデルとしてEUDIWにおけるトラストの解説 ③小松 ②を受けて実際どうなのか？民間ユースケースベースでの机上検証の話 26
27. Idp-RPユースケースをIHV型に置き換えてみる 架空のIdp-RPユースケースをIHV型に置き換える “RP発行の特別なクーポンを取得する条件として、Idp（Issuer）①②の会員であることを提示する” ID連携 IdP① RP IdP② Issuer ① 会員VC サービス利用 クーポン発行 Issuer ② Wallet (RP) 会員VP Verifier (RP) サービス利用 クーポン発行 27
28. Idp-RPユースケースをIHV型に置き換えてみる EUDIWの紹介で取り上げられた論点 • 統一された基準や制度 • VCをやり取りするプロトコル • DIWをインストールするハードウェアの要件 • Issuer、Verifierの信頼性保証 • VCの中身の設計や運用をどうするか 28
29. 統一された基準や制度（案） 29
30. 統一された基準や制度（案） Center of Excellence （CoE）のような横断組織をエコシステム内に準備できるか？が肝になる 中立・横断的な組織が存在しないと運用が ままならない No. 役割（ロール） 概要（主たる責任） 1 Wallet User VCを管理、保持、提示する。 ユーザー 本ユースケースにおける担い手 2 Wallet Provider ユーザーにウォレット・ソリューションを提供する。 RP 3 デバイス製造者 ハードウェア、OS等の基盤となるプラットフォームを提供する。 スマホベンダー 4 Issuer ユーザーにVCを発行する。 Idp①、Idp② 5 6 RP Center of Excellence （CoE） 7 Verifier（Relying Party） ウォレット・ユニットに属性の提示を要求し、受領する。 トラスト検証基盤 エコシステム内の信頼できるエンティティのステータスやトラストアンカー （公開鍵等）のリストを維持、管理、利用可能にする。 登録機関 Issuer、Verifier、Wallet Providerのエコシステムへの登録を管理する。 8 アクセス証明書局 IssuerとVerifierに認証用のアクセス証明書を発行する。 Center of Excellence （CoE） 9 登録証明書プロバイダ IssuerとVerifierに登録内容の詳細を伝達するための登録証明書を発行する。 Center of Excellence （CoE） 10 適合性評価機関 Center of Excellence （CoE） 11 監督機関 Wallet Providerが提供するウォレット・ソリューションの技術・運用面での要件充足を審査 する。 エコシステム全体を監督し、適切に機能していることを確かにする。 12 VCスキームプロバイダ 各VCのルールブックとスキーマを定義・利用可能にする。 ※スキームプロバイダが定義するVCは単一に限らず複数のVCスキーマを定義・管理しうる Center of Excellence （CoE） Center of Excellence （CoE） Center of Excellence （CoE） EUDIWでは、CoEのようにガバナンス面の役割を包括的に担う一つの組織等は存在せず、 各加盟国内で様々な組織・機関に分散している 30
31. VCをやり取りするプロトコル HAIP （OpenID4VC High Assurance Interoperability Profile）どこまで引き算するか？ （ユースケース次第と言ってはそれまでだが..） 引き算の例 OID4VCI（発行） 検討事項 クライアント認証 EUDIW（HAIP） Wallet Attestationを推奨 民間ユースケース PKCE＋DPoPができれば Credential Format SD-JWT VC か mdoc の少なくとも一方 エコシステムのユースケースに合わせて対応（今回の例ではSD-JWT VC) 検討事項 提示リクエストへの署名 EUDIW（HAIP） JAR で署名を必須 民間ユースケース 今回のクーポンレベルならredirect_uriでvp_token渡し一択から 要求の渡し方 request_uri（参照渡し）を必須 値渡し Credential Format SD-JWT VC か mdoc の少なくとも一方 エコシステムのユースケースに合わせて対応（今回の例ではSD-JWT VC) OID4VP（提示） 31
32. DIWをインストールするハードウェアの要件 ユースケース次第：スマホプラットフォーム提供の鍵管理機構の利用で十分そう （必要十分なセキュリティ＋ユーザ利便性） 32
33. Issuer、Verifierの信頼性保証 民間ユースケースの初期Phでは簡略化できる箇所、将来の拡張に向けての余地は必要 PJのステコミが代替 個別の登録業務が できればよい トラストリストを関係者 に共有できていればよい 33
34. VCの中身の設計や運用をどうするか 本ユースケースにおいては IdP①②の会員有無（boolean）、有効期間、Issuer識別子の提示がミニマムで必要そう この点に関してはEUDIWだろうと日本の民間ユースケースだろうと、同質の検討が必要に見える 34
35. Idp-RPユースケースをIHV型に置き換えてみた結果 やはり最初期から「大局観」をもってアーキテクチャを組めているか？ どこまでのエコシステムを本気で見据えるか？次第 思いつきで始めるくらいなら大人しくID Federationしておきましょう（自分への戒め） 35
36. Thank You! ありがとうございました 36