💳

EMV 3DS認証の「申告値」問題をSD-JWT Verifiable Credentialで解く——イシュア発行モデルのPoC実装

2026/05/06に公開

 はじめに「チェックアウト時に入力した住所は、本当に正しいのか」——この問いに、今の3-D Secure（3DS）は答えられません。
私たちが普段オンラインショッピングをする際、商品をカートに入れ、住所などを入力後、カード決済をします。決済のタイミングでは、加盟店が保持する、もしくは私たち自身が入力した情報が Access Control Server（ACS）に送信され、3DS認証が実施されます。認証OKであればオーソリがかかり、フリクションレス認証で不十分な場合はチャレンジ認証に進み、NGであれば拒否されることもあります。
ところで、ACSが受け取る住所や電話番号は、加盟店または入力者の「申告値」です。カード会社に保存されている情報と完全一致していれば問題ありませんが、表記ゆれ（特に住所）が起きたり、引っ越しで住所が変わっていたり、カード会社に登録していないショッピング用のメールアドレスを使っていたりすることは珍しくありません。ACSはその値がいつ更新されたか、本当に本人のものであるかを知るすべを持ちません。
EUDI Walletの普及とEMVCoの新しい動きは、この構造を変えるきっかけになり得ます。本記事では、W3C Verifiable Credentials（VC）を3DS認証フローに統合するアーキテクチャを提案し、実際にTypeScriptでPoCを実装した内容を解説します。
対象読者: 3DS・デジタルID・決済セキュリティに関わるエンジニア

 1. EUDI Walletの普及
 eIDAS 2.0と義務化の波2024年5月、EU規則「eIDAS 2.0」が施行されました。この規則は、EU加盟国に対して 2026年末までに欧州デジタルIDウォレット（EUDI Wallet）を市民に提供することを義務付けています。
EUDI Walletは、政府発行のIDドキュメント（運転免許証・パスポート等）や銀行口座情報、医療記録などを、W3C Verifiable Credentials形式でデジタル保管・提示できるウォレットです。プロトコルにはOID4VCI（発行）とOID4VP（提示）が採用されており、SD-JWT-VCまたはISO mDocフォーマットでの属性管理が標準化されています。

 Large Scale Pilots（LSP）の進展2023年から2025年にかけて、4つの大規模パイロット（POTENTIAL・NOBID・EWC・DC4EU）が稼働しました。合計で数百万人規模のユーザーが参加し、行政手続き・医療・旅行・銀行口座開設等のユースケースで実証が行われています。
EWC（European Wallet Consortium）パイロットでは、銀行口座情報をVCとして発行し、別の金融サービスで属性提示するフローが実証されました。これは「銀行がVCを発行し、別の文脈で利用する」というモデルの先行事例です。

 決済への統合eIDAS 2.0と同時期に改訂されたPSD3（第3次決済サービス指令）では、Strong Customer Authentication（SCA）の文脈でEUDI Walletの利用が想定されています。つまり、決済時の本人確認にEUDI Walletが使われる法的基盤が整いつつあります。

 APACへの波及日本では内閣官房が「Trusted Web」イニシアチブを推進しており、政府・民間が連携したデジタルIDの発行・流通の実証が進んでいます。シンガポールのNDI（National Digital Identity）、韓国のMobile IDも同様の方向性を持ちます。
EU先行で始まったこの動きは、APACにも波及しています。ただし、現時点でAPACのIDフレームワークと3DSを接続する技術仕様は存在しません。

 2. EMVCoの動向
 EUDI Wallet統合ホワイトペーパー（2025年6月）EMVCoは2025年6月、「EMV 3-D Secure EUDI Wallet Integration White Paper v1.0」 を公開しました。これは、EUDI Walletで管理されたIDを3DS認証フローに統合するための初の公式文書です。
このホワイトペーパーは、以下の2つの統合フローを定義しています。
Merchant-Captured フロー

カード会員がウォレットアプリを操作して属性を提示し、加盟店がそのデータを3DS AReqに含めてACSに送るフロー。
Issuer-Captured フロー

ACS（イシュア）が直接ウォレットと対話して属性を取得し、SCA（強力な顧客認証）の一部として活用するフロー。

 3DS v2.3.1.1の対応3DS v2.3.1.1では、EUDI Walletへの対応を意図した変更が加えられています。

Authentication Method 10（Electronic ID）の追加: threeDSRequestorAuthenticationInfoのthreeDSReqAuthMethodに、デジタルIDウォレットを示す値10が追加されました

threeDSReqAuthDataの最大50,000文字: このフィールドに大きなペイロードを格納できます

 Chapter 5「Next Steps」に残るオープンアイテムホワイトペーパーのChapter 5は、いくつかの課題を残しています。
"how the ACS identifies EUDI Wallet-derived data in the Merchant-Captured flow"
"more precise data might be useful for the ACS" （Section 6.5, Attribute Verification Message Extension）
つまり、「箱（フィールド）は作ったが、中身のフォーマットは未定義」 という状態が認められています。本提案はこのギャップを埋めることを目的としています。

 EMVCoの立場EMVCoはWhite Paperについて「regulatory-agnostic（規制非依存）」の立場を明確にしており、特定のIDフレームワーク向けの実装ガイダンスはスコープ外としています。メンバー構成が欧州・北米中心であることもあり、EUDI Walletへの関心は高い一方、APACへの言及は今回のホワイトペーパーにも一切ありません。APAC版のホワイトペーパーが自発的に出てくる可能性は低く、APAC文脈での実装提案は関係者が自ら発信していく必要があります。

 3. 既存のAReqが抱える問題
 「申告値」という構造的な弱点現行の3DS 2.xでは、加盟店がAReq（認証リクエスト）に住所・電話番号・メールアドレス等の属性を含めてACSに送信します。ACSはこれらの値を参照して不正リスクを判定しますが、根本的な問題があります。
これらの値はすべて加盟店が「申告」する値であり、その真正性の保証がありません。
加盟店が送る住所は、カード会員が過去に登録した値です。引っ越し後も更新されていないかもしれず、そもそもどの時点で確認されたものかも不明です。ACSはこの値を「信じるしかない」状態で判定を行っています。

 問題1：データフレッシュネスの欠如住所の変更が加盟店のDBに反映されるまでのタイムラグは、数週間〜数ヶ月になることがあります。ACSが受け取る住所が実際の居住地と一致しない場合、アドレス一致チェック（AVS）は機能しません。

 問題2：表記ゆれによる一致判定の困難「東京都千代田区丸の内1-1-1」と「Marunouchi 1-1-1, Chiyoda-ku, Tokyo」は同じ住所ですが、文字列一致では同一と判定できません。日本の住所は特にこの問題が深刻で、丁目・番地の表記ブレが多数存在します。

 問題3：GDPRおよびデータ最小化原則との矛盾GDPRのデータ最小化原則は、「目的に必要な最小限の個人データのみを処理する」ことを求めます。しかし現行の3DSでは、加盟店が3DS目的のためだけに住所・電話番号・氏名を自社DBに保持し続ける必要があります。
これは**「本来の目的（3DS認証）のために、目的外のPII保管を強いられる」** という矛盾です。

 問題4：ACSのリスク判定精度低品質なシグナルが大量に流れ込む構造では、ACSのML/ルールエンジンの精度は頭打ちになります。「申告値ベースの大量のシグナル」より「証明値ベースの少数の高品質シグナル」の方が、詐欺判定精度の向上とフリクションレス率の向上を同時に達成できる可能性があります。

 問題5：入力フリクションそのものの存在住所や電話番号の入力は、オートコンプリートがあるとはいえ、そもそも手間がかかります。特にモバイル環境では離脱率に直結します。VCを使えば、ウォレットからのワンタップ提示で入力フォームを省略できる可能性があり、認証の品質向上と購買体験の改善を同時に実現できます。

 4. イシュア発行のVC利用モデルの提案
 コアの発想：「申告値」から「証明値」へ提案の核心は、3DSで送信される属性の「信頼の起点」を変えることです。



現行
提案


属性の送り手
加盟店
カード会員のウォレット

信頼の根拠
申告（自己申告）
暗号署名（イシュア証明）

属性の鮮度
不明
VCの発行日・有効期限で明示

開示の粒度
フルPII
Selective Disclosure（必要最小限）


 threeDSReqAuthDataをVP TokenのキャリアにするEMV 3DS v2.3.1.1のthreeDSReqAuthDataフィールドは、Authentication Method 10（Electronic ID）と組み合わせて、最大50,000文字のペイロードを格納できます。
このフィールドに、OID4VP形式のVP Token（Verifiable Presentation）を格納することを提案します。具体的には、threeDSRequestorAuthenticationInfo オブジェクト内の threeDSReqAuthData に以下のJSON構造を格納します。
{
  "version": "1.0",
  "vcFormat": "dc+sd-jwt",
  "vpToken": "<header>.<payload>.<sig>~<disclosure>~<kb-jwt>",
  "presentationSubmission": {
    "id": "3ds-pres-sub-xxxx",
    "definition_id": "3ds-address-verification-v1",
    "descriptor_map": [
      { "id": "postal-code", "format": "dc+sd-jwt", "path": "$" }
    ]
  }
}

vpToken: OID4VP形式のVP Token本体。SD-JWT-VC・Selective Disclosure・KB-JWTが~区切りで連結されます

presentationSubmission: どのクレームをどのフォーマットで提示しているかを示すメタ情報（DIF Presentation Exchange仕様）
VP Tokenには、イシュアがES256で署名したSD-JWT-VCが含まれています。ACSはこの署名を検証することで、属性の真正性を暗号的に確認できます。

 Selective Disclosure：必要最小限の開示SD-JWT-VCのSelective Disclosure機能により、カード会員は必要な属性だけを開示できます。
住所確認であれば郵便番号だけ、年齢確認であれば「18歳以上」のBoolean値だけを開示し、氏名・生年月日・住所の詳細は送信しません。これはGDPRのデータ最小化原則と直接整合します。

 自己完結型の信頼モデル提案の最も重要な実装上の特性は、イシュアがVCを発行し、同じイシュアがACSを運営するという構造です。
イシュア ─── VC発行 ──→ カード会員のウォレット
  │
  └── ACSを運営 ──→ 署名検証（自社の公開鍵を使う）
ACSは「自分が発行したVCを自分の公開鍵で検証する」だけです。外部のTrust Registryや複雑なPKIインフラが不要で、今すぐPoCを始められる最大の理由がここにあります。また、カード番号からイシュアは特定可能であるため、実運用でもイシュア発行モデルは十分な実用性が見込まれます。

 3層フォールバック設計既存の3DSとの後方互換性を保ちながら段階的に展開できます。


レイヤー
条件
認証方式


Layer 1
SPC対応ブラウザ＋ウォレットあり
SPC + VP Token

Layer 2
ウォレットあり
既存3DS + VP Token

Layer 3
ウォレットなし
既存3DS（フォールバック）

VPトークンの利用はオプションであり、既存フローは維持されます。

 イシュアのメリット
ACSのリスク判定精度向上: 暗号的に検証された属性により、不正検知の精度が上がる

フリクションレス率の向上: 高品質シグナルにより、不要なチャレンジを減らせる

加盟店のPII保管負荷の軽減: 加盟店はVP TokenをパススルーするだけでよくPIIを保管不要

 5. PoCの解説
 リポジトリhttps://github.com/nakada-yuya-vc/3ds-vc-mvp
TypeScript（pnpm workspaces）で実装しており、pnpm demoの1コマンドでE2Eフロー全体を実行できます。

 アーキテクチャ
 パッケージ構成packages/
├── shared/   # 型定義（AReq/ARes・VP Token・VCペイロード）
├── issuer/   # Mock Issuer（SD-JWT-VC発行）
├── wallet/   # Mock Wallet（VP Token生成）
├── acs/      # Mock ACS（VP Token検証・ARes返却）
└── demo/     # E2Eデモスクリプト

 Step 1：Issuerが SD-JWT-VC を発行IssuerはES256鍵ペアを生成し、以下のクレームを持つSD-JWT-VCを発行します。

family_name, given_name（選択的開示）

birthdate（選択的開示）

address.postal_code, address.locality 等（選択的開示）

age_equal_or_over.18（選択的開示）

vct, iss, iat, exp, sub（常時開示）

 Step 2：Walletが VP Token を生成WalletはSD-JWT-VCから、郵便番号のみを開示したVP Tokenを生成します。Key Binding JWT（KB-JWT）には3DSトランザクションIDをnonceとして埋め込み、リプレイ攻撃を防ぎます。
生成されたVP Token（dc+sd-jwt形式）:
eyJ...header...eyJ...payload...sig~disclosure_postal_code~kb-jwt

 Step 3：MerchantがAReqを構築VP TokenをthreeDSReqAuthDataフィールドに格納します。
VP Token payload size: 1,671 chars（上限50,000文字の3.3%）
50,000文字制限に対して3.3%という余裕で収まることが確認できました。

 Step 4：ACSが VP Token を検証ACSは以下を順番に検証します。

Issuer署名の検証: VCに埋め込まれたIssuerの公開鍵でES256署名を検証

有効期限の確認: expクレームで有効期限を確認

KB-JWTの検証: ホルダー（ウォレット）の署名とnonceを確認

開示クレームの確認: 郵便番号が開示されていることを確認
検証成功時のARes:
{
  "messageType": "ARes",
  "transStatus": "Y",
  "vcVerificationResult": {
    "verified": true,
    "vcIssuer": "https://issuer.example.jp",
    "verifiedClaims": ["address"],
    "vcExpiresAt": 1780000000,
    "verificationTimestamp": "20260506120000"
  }
}

 このPoCが証明したこと

検証項目
結果


VP TokenがthreeDSReqAuthDataに収まる
✅ 1,671文字（上限の3.3%）

ACSがVC署名を検証できる
✅ ES256検証成功

Selective Disclosureが機能する
✅ 郵便番号のみ開示・他は非開示

KB-JWTによるリプレイ攻撃対策
✅ nonceにトランザクションIDを使用


 6. 課題PoCの実装を通じて、本格展開に向けて解決が必要な課題が明確になりました。

 課題1：Directory Server経由のVP Token中継現行の3DSでは、AReqはMerchant → Directory Server（DS） → ACSという経路で転送されます。PoCではDSをスキップしていますが、実際にはDSがVP Tokenを含むthreeDSReqAuthDataを透過的に中継する仕様の検討が必要です。

 課題2：クロスイシュア信頼（Trust Registry）本PoCの「イシュア = ACS」モデルは、ACSが自分の発行したVCを検証する場合にのみ機能します。異なる発行機関が発行したVCをACSで検証するためには、発行者の公開鍵を管理するTrust Registry（例：EBSIのTrusted Issuers Registry、X.509 PKIの拡張）が必要です。

 課題3：ブラウザ文脈でのウォレット起動チェックアウトページはiframe内で動作することが多く、iframeのsandbox制約によりUniversal App Link（UAL）からウォレットアプリを起動できない問題があります。EMVCoのWhite PaperもChapter 5でこの問題を未解決として挙げています。OID4VP redirect方式や、ブラウザ内ウォレットAPI（Digital Credentials API）による解決が候補となります。

 課題4：APACフレームワークへの展開本PoCはEUDI Walletを念頭に置いていますが、日本のTrusted Web・シンガポールNDI・韓国Mobile IDも同じOID4VPプロトコルを採用する方向にあります。threeDSReqAuthDataへの格納フォーマットをフレームワーク非依存に設計することで、APAC各国のIDフレームワークへの展開が可能になります。現時点でEMVCoのWhite PaperはEU以外への言及が一切なく、APAC文脈での実装提案は空白地帯です。

 課題5：EMVCo仕様への取り込み経路本提案はEMVCoの仕様変更を必要としますが、EMVCo自身はregulatory-agnosticの立場を取っています。W3C・OpenID Foundationでの技術議論の蓄積と、Principal MemberであるJCBやVisaなどを通じたEMVCoへのフィードバックが、現実的な取り込み経路です。

 おわりに「申告値から証明値へ」——この転換が実現すれば、3DSのリスク判定は根本的に変わります。ACSが受け取る属性の信頼性が上がれば、フリクションレス率の向上と不正検知精度の向上を同時に達成できます。
PoCのコードはMITライセンスで公開しています。同じ問題意識を持つ方、特に日本のイシュアや3DSサービス事業者の方からのフィードバックを歓迎します。
👉 https://github.com/nakada-yuya-vc/3ds-vc-mvp
本記事の内容はEMVCo・W3C等の公式見解を代表するものではありません。

	現行	提案
属性の送り手	加盟店	カード会員のウォレット
信頼の根拠	申告（自己申告）	暗号署名（イシュア証明）
属性の鮮度	不明	VCの発行日・有効期限で明示
開示の粒度	フルPII	Selective Disclosure（必要最小限）

レイヤー	条件	認証方式
Layer 1	SPC対応ブラウザ＋ウォレットあり	SPC + VP Token
Layer 2	ウォレットあり	既存3DS + VP Token
Layer 3	ウォレットなし	既存3DS（フォールバック）

検証項目	結果
VP TokenがthreeDSReqAuthDataに収まる	✅ 1,671文字（上限の3.3%）
ACSがVC署名を検証できる	✅ ES256検証成功
Selective Disclosureが機能する	✅ 郵便番号のみ開示・他は非開示
KB-JWTによるリプレイ攻撃対策	✅ nonceにトランザクションIDを使用

はじめに

1. EUDI Walletの普及

eIDAS 2.0と義務化の波

Large Scale Pilots（LSP）の進展

決済への統合

APACへの波及

2. EMVCoの動向

EUDI Wallet統合ホワイトペーパー（2025年6月）

3DS v2.3.1.1の対応

Chapter 5「Next Steps」に残るオープンアイテム

EMVCoの立場

3. 既存のAReqが抱える問題

「申告値」という構造的な弱点

問題1：データフレッシュネスの欠如

問題2：表記ゆれによる一致判定の困難

問題3：GDPRおよびデータ最小化原則との矛盾

問題4：ACSのリスク判定精度

問題5：入力フリクションそのものの存在

4. イシュア発行のVC利用モデルの提案

コアの発想：「申告値」から「証明値」へ

threeDSReqAuthDataをVP Tokenのキャリアにする

Selective Disclosure：必要最小限の開示

自己完結型の信頼モデル

3層フォールバック設計

イシュアのメリット

5. PoCの解説

リポジトリ

アーキテクチャ

パッケージ構成

Step 1：Issuerが SD-JWT-VC を発行

Step 2：Walletが VP Token を生成

Step 3：MerchantがAReqを構築

Step 4：ACSが VP Token を検証

このPoCが証明したこと

6. 課題

課題1：Directory Server経由のVP Token中継

課題2：クロスイシュア信頼（Trust Registry）

課題3：ブラウザ文脈でのウォレット起動

課題4：APACフレームワークへの展開

課題5：EMVCo仕様への取り込み経路

おわりに

Discussion

`threeDSReqAuthData`をVP Tokenのキャリアにする