OpenID for Verifiable Credentials 実装から見えた相互運用性確保までの道のり（OAuth/OIDC Numa (Immersion) Workshop 2026）

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

OpenID for Verifiable Credentials
実装から見えた相互運用性確保までの道のり

伊藤忠テクノソリューションズ株式会社
藤田 和成

Transcript

1. OAuth/OIDC Numa (Immersion) Workshop 2026 OpenID for Verifiable Credentials 実装から見えた相互運用性確保までの道のり ー Conformance Testで見えた、仕様・実装・Test Suiteとのギャップ ー 2026.8.25 伊藤忠テクノソリューションズ株式会社 藤田 和成(ふじた かずなり)
2. OAuth/OIDC Numa (Immersion) Workshop 2026 藤田 和成 ふじた かずなり これまで 製品導入・開発プロジェクト CRM、BI／DWHをはじめとするシステムの導入・開発に従事 2012 エンタープライズID分野へ 大手自動車メーカーのグローバルID基盤PJを契機に、ID基盤の提案・構築を担当 2022 Verifiable Credentialsに着目 Microsoft Entra Verified IDを試し、VCの仕組みと活用可能性を検証 2025 VC Knotsの開発に参画 慶應義塾大学との共同研究を通じ、OSS SDK「VC Knots」を開発
3. OAuth/OIDC Numa (Immersion) Workshop 2026 今日、持ち帰ってほしいこと Conformance Testを、合否判定ではなく実装改善の道具として使う 実行のやり方がわかる Suite画面で迷ったら、参照SPECと実行例まで確認する ★ ログから原因を追える 参照仕様・HTTP通信・判定結果を関連付けて読む ◈ 結果を鵜呑みにしない 実装・仕様解釈・Suiteのどこに原因があるかを切り分ける 実装改善のループ ① 参照仕様を確認する 規定とメッセージ例を確認 → ② テストを動かす 対象profileと条件を固定して再現 → ③ ログから実装へ戻す 通信と仕様を確認し実装を修正
4. OAuth/OIDC Numa (Immersion) Workshop 2026 VC Knots とは 共同研究で得た知見を、VC 実装の OSS SDK へ 共同研究 OSS SDK 社会実装 Trust Knots VC Knots 慶應義塾大学 SFC 研究所 × CTC の共同 国際標準対応の主要機能を 研究プロジェクト 部品化した開発者向け SDK 信頼あるインターネ ットの普及 データ流通の信頼性向上に向けたプロト タイプ開発と実証 OSS として公開し、PoC・実証か ら導入検討まで進めやすくする Issuer Wallet Verifier POINT 共同研究の成果を、検証の場から開発者が使える OSS へ
5. OAuth/OIDC Numa (Immersion) Workshop 2026 「仕様準拠」だけでは繋がらない • VC エコシステムは Issuer / Holder / Verifier の多者間モデル。自社 で作るのは一部だけで、相手の実装は選べない • 仕様は OPTIONAL・RECOMMENDED が多い。読み方次第で実装内容 が分かれる • 接続相手と選択した方式やProfileが一致しないと、仕様に準拠した実 装同士でも接続できない場合がある • だからこそ第三者視点の Conformance Test は、同じテスト条件で実 装の挙動を確認する共通の基準になる Issuer 発行者 Holder 保有者 Verifier Verifier 検証者 保持・提示 相互運用性には、仕様準拠に加えて接続相手とのProfileの一致が必要
6. OAuth/OIDC Numa (Immersion) Workshop 2026 CHAPTER 01 01 Conformance Testとは
7. OAuth/OIDC Numa (Immersion) Workshop 2026 Conformance Testとは何か OpenID Foundationが提供する、仕様準拠を実装で検証するためのOSSテストスイート 何をするものか 実装 Issuer / Wallet / Verifier → Conformance Suite 仕様に沿って テストを実行 → 結果 PASS / FAIL 詳細ログ → 適合性確認 仕様に沿っているかを 客観的に確認 公式ページから押さえるポイント OIDF運営のOSS テスト利用は無料 ローカルでも実行可能 CI/CDにも組み込める ソースコードが公開され、改 善・バグ修正への貢献も受け 付けている 実装を試験する利用は無料。 OpenID認定には別途費用が 必要 Dockerに対応し、開発中の 実装を繰り返しテストできる GitHub Actions等から自動 実行し、変更ごとに適合性を 確認 仕様を読むだけではなく、実装を動かして「標準に沿っているか」を確認する仕組み Source: https://openid.net/certification/about-conformance-suite/
8. OAuth/OIDC Numa (Immersion) Workshop 2026 Certification までの流れ 1 テストプラン選択 2 → 環境設定 & 実行 3 → 結果の提出 4 → 費用支払い & 公開 対象仕様とバリアントを選ぶ。認 自実装をテストサーバに向けて全 Certification of Conformance 書 Fee Schedule に沿って支払い。 証には「/HAIP」付きプランが必 テストモジュールを実行(無料) 類+署名付きテスト結果を OIDF openid.net の認証済みリストに公 へ提出 開 須（OpenID4VP,OpenID4VCI 2026-08-21時点）
9. OAuth/OIDC Numa (Immersion) Workshop 2026 Conformance Testを開発プロセスに組み込む 仕様適合性を客観的に示し、相互運用性検証と開発品質の土台にする 実装 Issuer / Wallet Verifier → Conformance Suite OIDFのテストで 仕様要求を確認 → 得られるもの • 自称ではなく、第三者基準に基づく標準準拠の説明材料 • ヘッダー・ペイロード・HTTPシーケンスを含む再現可 能なログ • 失敗箇所と仕様要求を開発タスクへ落とし込む材料 ログ → HTTP / JSON エラー詳細 改善 CI / 修正 再実行 → 接続 Interop 注意点 • テスト通過は対象プロファイルの通過であり、全仕様の 完全保証ではない • Status ListなどVC周辺仕様や業界固有要件は別観点で補 完が必要 • Suite更新・仕様更新に追従する継続運用が前提になる
10. OAuth/OIDC Numa (Immersion) Workshop 2026 Conformance Test通過の意味 標準準拠を客観的に証明し、相互運用性・信頼・本番接続の前提を満たす テストを通すと何が担保されるか VC Knotsにとっての5つの意味 VC Knots実装 標準仕様 Issuer / Wallet / Verifier OID4VCI / OID4VP ↓ 1 第三者が認める標準準拠 2 相互運用性の担保 3 本番接続の入場券 4 開発品質の向上 5 OSSとしての信頼形成 Conformance Test 第三者基準で仕様準拠を検証する “動く仕様書” ↓ 準拠認定 接続前提 品質改善 仕様準拠漏れを早期発見し、改善ループへ 自社の主張ではなく、外部基準で客観的に示す 他社Wallet / Issuer / Verifierと本当につながる 準拠必須化の流れで、接続可否の前提になる 仕様漏れを機械的に検出し、改善タスクに落とす 信頼できるOSSとして、対外発信の説得力になる 信頼できる・つながるVCライブラリであることの土台
11. OAuth/OIDC Numa (Immersion) Workshop 2026 CHAPTER 02 02 Conformance Testで見えた 実装との差分 既存実装との差分を特定する
12. OAuth/OIDC Numa (Immersion) Workshop 2026 テスト前の Issuer 実装と OpenID4VCI 仕様 OpenID4VCI 仕様本体だけを読むと、多くの項目が OPTIONAL / Conditional 当初の実装 GRANT TYPE TRIGGER FLOW SHAPE Pre-Authorized Code Flow Issuer-initiated Cross-Device Flow urn:ietf:params:oauth: grant-type:pre-authorized_code Issuer 側から提示する通信をきっかけに、通信を開始 QR コードで Wallet に渡す前提 主な仕様要件 項目 仕様上の要件 補足 Client authentication OPTIONAL Pre-Authorized Code Grantの場合にOPTIONAL Sender Constrained access token(DPoP / mTLS) RECOMMENDED DPoPを推奨 Nonce Endpoint Conditional MUST c_nonce を使う場合のみ Proof of Possession Conditional MUST メタデータで宣言した場合のみ Credential Format 選択可 jwt_vc_json / sd_jwt_vc / mso_mdoc 等 長時間有効なAccess Tokenの場合必須 「最低限動作する」仕様で実装 — この構成が Conformance Test でどう評価されるかを、次から見ていく
13. OAuth/OIDC Numa (Immersion) Workshop 2026 Conformance Testを開いてみたら… certification.openid.net — Issuerテストプラン作成画面。各項目から方式を選択する CREATE TEST PLAN — OID4VCI Issuer Configuration Specification OID4VCI Test Plan OpenID4VCI 1.0 Final: Test an issuer (alpha) FAPI Profile vci Client Authentication Type private_key_jwt / mTLS / client_attestation 今回の組み合わせ private_key_jwt ＋ DPoP クライアント認証 × 送信者制約 Sender Constraining DPoP / mTLS （表のオレンジの2行） Credential Format sd_jwt_vc OID4VCI §13.2は FAPI 2.0 Security Authorization Code Flow Variant issuer_initiated Profileへの準拠を推奨。 ほかに mTLS / client_attestation も選 Grant Type pre_authorization_code テスト条件の選択によって、足りない実装と確認すべき内容が見えてくる 択できる
14. OAuth/OIDC Numa (Immersion) Workshop 2026 選択した2方式をIssuer側へ追加実装 Suite Walletから届くclient_assertionとDPoP Proofを、Issuer側で検証する 01 CLIENT AUTHENTICATION 02 SENDER CONSTRAINING private_key_jwt DPoP FAPI 2.0 の選択肢:mTLS / private_key_jwt FAPI 2.0 の選択肢:mTLS / DPoP Suite Wallet → client_assertion JWT を署名して Token Request へ Suite Wallet → DPoP Proof JWT を各リクエストへ付与 VC Knots Issuer 側の処理 VC Knots Issuer 側の処理 • Token Endpointでclient_assertionを受信 • 署名、htm、htu、iat、jtiを検証 • クライアント公開鍵で署名を検証 • 必要時にuse_dpop_nonceとDPoP-Nonceを返す • 必須クレームと有効期限を検証 • Suite Walletのnonce付き再送を検証 • 不正なassertionはOAuthエラーで拒否 • アクセストークンを送信者の鍵へ拘束
15. OAuth/OIDC Numa (Immersion) Workshop 2026 教訓：実装前にテスト条件の内容を確認 仕様・テスト条件と既存実装の差分を整理し、追加工数を見積る 1 SPECを読む 採用するFlowとCredential Format を決める 2 テスト条件を確認 Client AuthenticationとSender Constrainingの選択肢を確認する "最低限で動く" と ”テストを通す" は別物 MVPは仕様最低限 → 認定準備で FAPI2 を積み増す、が現実的な順序 仕様理解と認定用の追加要件は、別プロジェクトとして工数を切る PHASE 1 3 差分を洗い出す 実装済み／追加実装を分けて工数化 する 積み増し PHASE 2 MVP 認定準備 仕様最低限で動くもの FAPI2 を積み増し Pre-Auth + Cross-Device Conformance Test PASS
16. OAuth/OIDC Numa (Immersion) Workshop 2026 CHAPTER 03 03 実際のテストから
17. OAuth/OIDC Numa (Immersion) Workshop 2026 Conformance Testの始め方は、仕様書の中に書いてあった Exported Values の endpoint に、§4.1.2 の credential_offer 値渡しして実行 1 SUITE 2 SPEC §4.1.2 3 EXECUTE Suiteは実行待ち SPECで値渡し例を確認 curlでOfferを送る endpointは出たが、次の操作が分から なかった。 §4.1.2に、Offerを値として渡すGET 例が記載されていた。 SPECの例に沿って、作成したOfferを 値渡しして実行した。 SPECの値渡し例に沿って、Credential Offerの実行を開始できた Suite画面だけで迷ったときは、仕様書の「実行例」まで読む
18. OAuth/OIDC Numa (Immersion) Workshop 2026 実際に走らせたConformance Test結果 OID4VCI Issuer happy flow: private_key_jwt + DPoP + sd-jwt-vc FINISHED PASSED シーケンスの中身が見える ・HTTP request / responseのヘッダーとボディ ・DPoP proof、client assertion、Credential requestのペイロード AIとの相性がよい ・JSON形式でエクスポートし、AIエージェントに渡せる ・失敗箇所と仕様ポインタがあるため、修正依頼が具体化する ただし、OpenID以外は補完が必要 ・Status ListなどVC周辺仕様は、このFlowだけでは十分 ・運用要件は別テスト・レビューで確認する 価値は、修正に使えるログが残ること 通信のヘッダー・ペイロード・仕様参照まで追えるため、人もAIも原因を特定しやすい。VC Knotsではこのログを実装改善に活用している。
19. OAuth/OIDC Numa (Immersion) Workshop 2026 Happy Flowのシーケンス Wallet (Conformance Suite) Issuer (自社実装) PASSEDを支える証跡 • Request / Response単位で4段階を追える ① Metadata：Issuer / ASの情報を取得 • SUCCESS 97／FAILURE 0／WARNING 0で PASSED ② Token：DPoP challenge → 再送 → Access Token • Requirement IDから仕様の根拠へ戻れる • HTML／JSONと署名ファイルで保存できる ③ Nonce：c_nonceを取得 ④ Credential：challenge → 再送 → SD-JWT VC ⑤ SD-JWT VCを検証（署名・Key Binding）
20. OAuth/OIDC Numa (Immersion) Workshop 2026 取得できるログファイル 中身は同じ。読む相手に合わせて形式を使い分ける HTML FILE HTML：人が読む 画面で時系列でRequest / Response / requirementを確 認することができる JSON FILE JSON：AI・機械が使う 構造化されており、そのままAIに渡して解析できる 目的に合わせて形式を使い分ける
21. OAuth/OIDC Numa (Immersion) Workshop 2026 Conformance Test結果の見方① 仕様の根拠は灰色タグ、通信内容は REQUEST / RESPONSE から読む 1 灰色タグ 2 青色ラベル 参照している仕様を確認 実際のHTTP通信を確認 表示例 OID4VCI-1FINAL-12.2.3 RFC8414-3.1 タグはリンクになっており、処理が確認している 仕様の該当箇所へ移動できる。 REQUEST 送信したURI・メソッド・ヘッダー・ボディ RESPONSE 受信したステータス・ヘッダー・ボディ 「More」を開くと、送受信データの詳細を確認できる。 灰色タグで「根拠」を確認し、青色ラベルで「実際の通信」を確認する
22. OAuth/OIDC Numa (Immersion) Workshop 2026 Conformance Test結果の見方② HTTPステータスだけではなく、期待値と実際のエラーコードを比較する 1 赤いFAILURE 2 値を比較 失敗した検査を開く 期待値と実際値を照合 proofs を省略したCredential Requestに対し、 「More」を開いて error と expected_error を確認する。 HTTP 400 Bad Request 期待 invalid_proof 実際 invalid_credential_request エラーstatuがあっていても error コードが期待と異なるた め FAILURE となる。 HTTP 400でも、期待したエラーコードと違えば FAILURE になる
23. OAuth/OIDC Numa (Immersion) Workshop 2026 PASSは結論、ログが根拠 選択したprofileと各項目の値によって、確認する仕様要件が決まる SPEC 仕様書 OID4VCI 1.0 選択した profile / 各項目の値 ◆ 正常系 発行フローが所定のシーケンスで完了する か → OFFICIAL CHECKPOINT OpenID Foundation Conformance Suite HTTP / JOSE / OAuth / VC を検査 ◆ 異常系 不正な入力に、規定の status / error を返 すか PASS → Issuer 実装 結果と証跡をログで確認 ◆ 証跡 Request / Response / Requirements / 判定を残す PASSはすべてのVC要件を保証するものではない。選択した条件に対するRequest / Response / Requirements が根拠になる
24. OAuth/OIDC Numa (Immersion) Workshop 2026 Isuserが返したDPoP-Nonceが、次のリクエストで戻ってこなかった Wallet役のSuiteは、DPoP-Nonceを次のDPoP Proofで使わなかった ISSUER 実装 / OID4VCI §7.2 MAY 準拠 MEASURED / NONCE ENDPOINT RESPONSE Nonce Endpoint 応答で、body の c_nonce と header の dpop- dpop-nonce: 0a76d7a944ca41d88528b3233146b9c4 nonce を同時に返す。 {"c_nonce":"71893d36023b4895a7c1f93db92d7974"} CONFORMANCE TEST (alpha) / Nonce EP 検証 Nonce EPのDPoP-Nonceは使われず、RFC 9449 のchallenge / retryで処理 ✓ HTTP status Nonce EP が dpop-nonce を返す ✓ Content-Type ✓ Cache-Control Suite は Nonce EP の DPoP-Nonce を利用しない ✓ body の c_nonce 抽出 ✗ header の dpop-nonce 抽出 Credential EP で 401 use_dpop_nonce 401応答で受け取ったDPoP-Nonceを使って再送し、200 PASS SPEC / OID4VCI §7.2 準拠は達成 仕様準拠でも未検証 Issuer MAY provide a DPoP nonce in an HTTP header. Wallet uses it at the Credential Endpoint. — この利用経路が未検証 Issuer は §7.2 MAY どおり header で dpop-nonce を返し ている テストは PASS するが、header 利用経路は確認されない → Issue #1927 を起票
25. OAuth/OIDC Numa (Immersion) Workshop 2026 DPoP-Nonce利用経路：SPECの想定と実際 Wallet (Conformance Suite) Issuer (VC Knots) Credential Endpointで challenge /retry なし SPEC想定 / OID4VCI §7.2 ① POST /nonce ② 200 OK：c_nonce + DPoP-Nonce ③ Credential Request：Nonce EPのDPoP-NonceをDPoP Proofに利用 ④ 200 OK：Credential 実際 / Conformance Suite RFC 9449 challenge / retry ① POST /nonce ② 200 OK：c_nonce + DPoP-Nonce ③ Credential Request：Nonce EPのDPoP-Nonceを利用しない ④ 401 Unauthorized：use_dpop_nonce + 新しいDPoP-Nonce ⑤ Credential Request（再送）：401応答のDPoP-NonceをDPoP Proofに利用 ⑥ 200 OK：Credential → PASS
26. OAuth/OIDC Numa (Immersion) Workshop 2026 現在 : Issue #1927 は継続、修正 MR はクローズ Nonce Endpoint の DPoP-Nonce 利用を、VCI 固有ではなく共通処理として見直す方向へ ISSUE #1927 / IN PROGRESS MR !2162 / CLOSED(未マージ) NEXT / 共通化を検討 Nonce Endpoint の経路が未テス ト 修正 MR はクローズ 汎用 DPoP 処理として再設計 • Suite は DPoP-Nonce header を利用し ない • 「use DPoP-Nonce from nonce endpoint response at credential • VCI 固有ではなく FAPI2 / eKYC も含む広い範囲 で解決する必要がある • Credential Endpoint で不要な challenge / retry が発生 • 担当は OIDF の Thomas Darimont(スイ ート側メンテナ) endpoint」 • header を Credential Endpoint の DPoP proof へ利用する提案 • パイプライン失敗後、master へ未マージ のままクローズ • token / PAR / userinfo / nonce / credential な ど呼び出し全般を共通クラスへ • client がDPoP-Nonceを使わなかった場合も、 IssuerがDPoP-Nonceを指定して再試行を促せる ことをテスト 現在地:個別修正ではなく、汎用 DPoP 処理として再設計する方向で議論が継続中 テストの結果を実装に活かし、テストで見つけた仕様とSuiteのずれを、Suiteの改善につなげる
27. OAuth/OIDC Numa (Immersion) Workshop 2026 Issue 起票から修正提案へ Conformance Testで見つけた問題を報告し、修正案が作られた 1 ISSUE #1927 2 MERGE REQUEST !2162 問題を報告 修正方針を議論中 → Nonce EndpointのDPoP-Nonce headerが Suiteで利用されないことを起票 Credential EndpointのDPoP proofへ 利用する変更を提案 テストで見つけた問題が、Suite改善の議論につながった
28. OAuth/OIDC Numa (Immersion) Workshop 2026 実際のテストで分かったこと Conformance Testを流すと、実装とSuiteの両方に改善点が見えた 1 TEST CONDITIONS 不足実装が明確に private_key_jwt / DPoP 選択した条件が追加実装の範囲を決 めた まとめ 2 IMPLEMENTATION ログで実装を補強 HTTP通信から不足箇所を特定 RFC 9449のchallenge / retryを追 加 3 SUITE FEEDBACK Suite改善へ貢献 仕様どおりでも未検証の経路を発見 Issue #1927を報告し、改善議論へ 実装を直し、Suiteへ返す。この往復が相互運用性を前へ進める 条件を選ぶ → ログで直す → 仕様との差異をSuite改善へつなげる
29. OAuth/OIDC Numa (Immersion) Workshop 2026 今日、持ち帰ってほしいこと Conformance Testを、合否判定ではなく実装改善の道具として使う 実行のやり方がわかる Suite画面で迷ったら、参照SPECと実行例まで確認する ★ ログから原因を追える 参照仕様・HTTP通信・判定結果を関連付けて読む ◈ 結果を鵜呑みにしない 実装・仕様解釈・Suiteのどこに原因があるかを切り分ける 実装改善のループ ① 参照仕様を確認する 規定とメッセージ例を確認 → ② テストを動かす 対象profileと条件を固定して再現 → ③ ログから実装へ戻す 通信と仕様を確認し実装を修正
30. OAuth/OIDC Numa (Immersion) Workshop 2026 今後取り組みたいこと Conformance Testを「都度実行」から、開発プロセスの一部へ組み込む 再現できる環境・自動実行・ログ起点の改善を、ひとつの継続的なループにする。 1 LOCAL REPRODUCTION ローカルで再現 DockerでSuiteと対象実装の条件を 固定 失敗ケースを手元で繰り返し検証 目指す姿 2 CI / CD AUTOMATION 変更ごとに自動実行 PR／主要ブランチ更新時に起動 仕様準拠のデグレを変更単位で検知 3 FEEDBACK LOOP ログを改善へ戻す テストが失敗したら、ログとHTTP通信 から原因を特定 実装を修正し、同じテストで改善を確 認 一度きりの適合確認ではなく、変更のたびに自動実行して仕様準拠を継続的 に確認する ローカル再現 → 自動実行 → 原因特定 → 修正・再検証を、日常の開発サイクルへ組み込む。
31. OAuth/OIDC Numa (Immersion) Workshop 2026 VC Knots でConformance Testを試してみてください OSS として公開しています まずは触って、体感してください。 ★ スターで活動を見つけやすく ✎ Issue / PR / 議論でフィードバック PoC や学習の出発点に SCAN TO OPEN github.com/trustknots/vcknots • 技術書典21：11/23オフライン参加予定