--- url: 'https://www.corbado.com/ja/blog/digital-credentials-payments-strategy' title: 'デジタル認証情報と決済：Apple WalletとGoogle Walletの戦略比較' description: 'デジタル認証情報が決済に与える影響と、発行事業者がApple PayやGoogle Walletと効果的に競争するための戦略を学びます。' lang: 'ja' author: 'Vincent Delitz' date: '2025-07-25T07:00:08.271Z' lastModified: '2026-09-16T06:02:32.733Z' keywords: 'デジタル認証情報, 決済, デジタルウォレット' category: 'Passkeys Strategy' --- # デジタル認証情報と決済：Apple WalletとGoogle Walletの戦略比較 ### 概要：発行事業者向け戦略的プレイブック | フェーズ | コア戦略 | 主なアクション | | :-------------- | :-------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. 現在** | 📱 **アプリを推進し、パスキーをマスターする** | ネイティブアプリの導入を徹底的に推進します。Apple PayやPayPalに匹敵するワンクリックの決済体験のためにパスキーを使用します。 | | **2. 近い将来** | 🆔 **VCは決済ではなく本人確認に利用する** | KYCやアカウント復旧など、高い保証レベルが求められるタスクにデジタル認証情報を統合します。検証可能な決済認証情報については、監視はしますが、導入を急ぎません。 | | **3. 将来** | ⚖️ **VCと進化するパスキーを比較評価する** | あらゆるVC決済フローを最高の体験と比較検討します。義務付けられた場合、または明らかに優れた価値を提供する場合にのみ決済に採用します。インバンドのデバイスシグナルのようなパスキーの機能強化に注目します。 | ## 1. はじめに デジタル決済は常に変化しています。私たちは、より速く、より安全で、より使いやすいものを求めています。同時に、検証可能な認証情報（VC）やモバイルID文書（[mdoc](https://www.corbado.com/glossary/mdoc)）のようなデジタルIDツールも進化しており、人々が自分自身を証明するための新しい方法を提供しています。そこで大きな疑問となるのが、これらの新しいデジタルIDは、デジタル決済を大幅に改善したり、簡素化したりできるのか、ということです。 この記事では、デジタル認証情報（ISO mdocsや[OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc)を使用して送信されるVCを含む）が決済の世界とどのように関連しているかを見ていきます。以下の内容をカバーします： - 現在のスマートフォンのウォレット（[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos) [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)、Google [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)）が、決済カードとID情報をどのように扱っているか。 - なぜ[ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5)/7 mdocsのような現在のデジタルID標準が、直接的な決済ツールとしてあまり適していないのか。 - [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc)のようなプロトコルが、将来の決済方法でどのような役割を果たす可能性があるか。 - 他の（サードパーティの）ウォレットアプリが決済機能をどのように扱う可能性があるか。 - 検証可能な認証情報を決済システムで利用しようとする際の主な問題点と将来の可能性。 このテキストは、決済に特化することで、デジタル認証情報とパスキーに関する私たちの他の議論を補完するものです。 ## 2. 現在の状況を理解する：IDスタックと決済スタック デジタル認証情報が決済にどのように利用できるかを見るために、まず今日の主要なモバイルプラットフォームとその組み込みウォレット（[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos) [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)、Google Wallet）が、ID情報と決済処理をどのように分離しているかを理解する必要があります。 ### 2.1 ネイティブプラットフォームウォレット：IDと決済の分離されたサイロ ネイティブプラットフォームのウォレットは、ユーザーにとって洗練されたハブとなっていますが、通常、ID認証情報と決済手段の間には明確な区別があります： - **ID認証情報（例：mDL）：** - **Apple Wallet:** 主にISO/IEC 18013-5準拠のモバイル運転免許証（[mDL](https://www.corbado.com/blog/mobile-drivers-license)）と州発行のIDをサポートしています。[WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26)で[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)が確認したように、[Safari](https://www.corbado.com/ja/blog/digital-credentials-api) 26（[iOS 26](https://www.corbado.com/blog/ios-26-passkeys)に搭載）は、オンラインでの提示のために[W3C](https://www.corbado.com/ja/blog/digital-credentials-api) [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) APIをサポートし、`org.iso.mdoc`プロトコルに限定して焦点を当てます。これは決済のためではなく、ID属性（例：氏名、年齢、住所）を検証するためのものです。 - **Google Wallet & Android Credential Manager:** [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)もISO 18013-5に基づく[mDL](https://www.corbado.com/blog/mobile-drivers-license)をサポートしています。基盤となる[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Credential Managerは、より柔軟なフレームワークを提供します。[Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) APIの実装はプロトコルに依存しませんが、[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)はトランスポートメカニズムとして[OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)を使用するデフォルトの実装を提供します。 - **決済手段（例：クレジットカード/デビットカード）：** - [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay)（Apple Wallet内）と[Google Pay](https://www.corbado.com/blog/how-to-use-google-pay)（Google Wallet内）は、確立され、高度に規制された決済技術を利用しています。これらは主にEMV（Europay、[Mastercard](https://www.corbado.com/blog/mastercard-passkeys)、[Visa](https://www.corbado.com/blog/visa-passkeys)）標準に基づいており、トークン化（取引のために実際のカード番号を置き換えるデバイス[PAN](https://www.corbado.com/glossary/pan)またはDPAN）、決済トークンを保存するためのセキュアエレメントまたはハードウェア支援セキュリティ、取引セキュリティのための動的クリプトグラムなどが含まれます。 - これらの決済システムは、既存の決済ネットワーク（[Visa](https://www.corbado.com/blog/visa-passkeys)、[Mastercard](https://www.corbado.com/blog/mastercard-passkeys)、Amexなど）やアクワイアリングバンクと直接やり取りします。 **重要なポイント：** ネイティブプラットフォームウォレットは現在、ID認証情報と決済カードで別々の「スタック」または技術で運用されています。[mdoc](https://www.corbado.com/glossary/mdoc)はID属性を証明するために提示され、トークン化されたカードは支払いを行うために提示されます。これらのネイティブエコシステム内で[mdoc](https://www.corbado.com/glossary/mdoc)を決済手段として直接使用することはありません。 ### 2.2 なぜISO 18013-5 mdocは決済手段ではないのか ISO/IEC 18013-5標準は、[mDL](https://www.corbado.com/blog/mobile-drivers-license)やその他のモバイルID（mdoc）のデータ構造を定義しています。ID検証には優れていますが、その設計は決済手段としての直接的な使用には不向きです： | 特徴 | ISO 18013-5が指定するもの（ID mdoc向け） | なぜこれが決済にとって問題なのか | | :--------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **主な範囲** | モバイル運転免許証およびその他のID文書。 | カードネットワークは決済固有のデータ要素とクリプトグラムを必要とします。 | | **データモデル** | 固定されたID関連のデータ要素（例：顔写真、氏名、生年月日）。拡張可能だが、「ID」の名前空間にキー付けされている。 | カードのPAN、トークン化されたDPAN、CVM、動的クリプトグラムは、これらのID要素にうまくマッピングできません。 | | **脅威モデルとセキュリティ** | 保有者提示（「有人」）検証。ID属性の選択的開示を伴うオフラインの「タップして検証」。mdocからの安全なデータ取得。 | 決済には、オンライン承認、動的クリプトグラム生成（EMVスタイル）、金融取引に特化した不正防止、資金源へのリンクのための堅牢なメカニズムが必要です。mdocのセキュリティはIDの完全性のためのものであり、金融取引処理のためのものではありません。 | | **標準の認識** | ISO 18013-5は、対面でのID確認に限定されることを明示しています。ISO/IEC 18013-7およびISO/IEC 23220は、mdocのオンライン提示メカニズム（例：Digital Credentials APIを介したウェブベースのID検証）を規定していますが、これらは依然として\_リモートでのID検証\_に焦点を当てており、決済レールには焦点を当てていません。 | 決済、特にオンライン決済は、mdoc標準自体の範囲外です。 | たとえmdocが理論的にカスタムデータフィールドを追加して[PAN](https://www.corbado.com/glossary/pan)や決済トークンを保持できたとしても（ISO 18013-5はカスタム名前空間を許可しているため）、mdoc標準自体は以下を定義していません： - 動的な決済クリプトグラムを生成または処理する方法。 - 決済ネットワークとのオンライン承認を実行する方法。 - 決済取引に特有の必要なセキュリティメカニズム（IDデータの完全性を超えるもの）。 したがって、現在、[ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) mdocを直接的な決済手段として使用する方法はありません。 ### 2.3 ステップアップ認証：決済ではなくID証明のためのmdocの使用 mdocは決済ツールではありませんが、「ステップアップ認証」フローで役割を果たすことができます。これは、高リスクなアクションに対してユーザーのIDを明示的に検証する必要がある場合です。これは、決済を実行するために使用するのとは異なります。フローは通常次のようになります： 1. **一次認証：** ユーザーは、パスキーのような低摩擦の方法でサービスにログインします。 2. **ステップアップのトリガー：** 高保証のアクション（例：高額な銀行振込、個人情報の更新）に対して、サービスは明示的なIDチェックを要求します。 3. **mdocの提示：** サービスはユーザーのmdoc（例：運転免許証）の提示を要求します。ユーザーはウォレットから必要な属性を提示します。 4. **検証：** サービスは、信頼できる情報源または以前に登録されたIDに対してmdocデータを暗号学的に検証します。 このモデルでは、mdocは特定の高リスクな瞬間に、強力でフィッシング耐性のあるID証明を提供します。しかし、その後の金融取引は依然として確立された決済レールを使用します。mdocは\_人物\_を検証するのであり、\_決済方法\_を検証するのではありません。 ## 3. 潜在的な決済シナリオにおけるOpenID4VCの役割 mdocs自体は決済手段ではありませんが、OpenID for [Verifiable Credentials](https://www.corbado.com/blog/eudi-wallet-2026-deadline-rollout-eic-2026)（[OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc) – 提示のための[OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)と発行のための[OpenID4VCI](https://www.corbado.com/glossary/openid4vci)を含む）のようなプロトコルは、より柔軟なトランスポート層を提供します。 **OpenID4VCの主な特徴：** - **プロトコルであり、ペイロードではない：** OID4VCはVCを要求し提示する方法を定義しますが、VCペイロード自体の形式についてはほとんど関知しません。mdoc、[W3C](https://www.corbado.com/ja/blog/digital-credentials-api)標準VC（例：JWTまたは[SD-JWT](https://www.corbado.com/ja/glossary/sentakuteki-kaiji)形式）、またはその他のカスタム認証情報タイプを転送できます。 - **ユースケースの広さ：** この柔軟性により、[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)（Credential Manager経由）のようなプラットフォームは、共通のメカニズムを通じてさまざまな種類の認証情報のリクエストをサポートできます。 - **決済VCの将来的な互換性：** 決済業界が検証可能な「決済トークン」または「決済承認」認証情報形式を標準化した場合、OID4VCは理論的にユーザーのウォレットとマーチャント/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk)の間でそのような認証情報を転送できます。 **しかし、OID4VC自体は決済ソリューションではありません：** - OID4VCの役割は、認証情報の交換を容易にすることです。決済認証情報の内容、セキュリティ機能、または決済処理システムとのやり取り方法を定義するものではありません。 - OID4VCが決済に役立つためには、まず広く採用され、安全で、標準化された\_検証可能な決済認証情報形式\_が決済エコシステム（発行者、アクワイアラー、ネットワーク）によって開発され、サポートされる必要があります。これは現在存在しません。 ## 4. サードパーティウォレットと決済 ネイティブプラットフォームウォレットを超えて、サードパーティウォレット（例：EUDI Wallet、銀行提供のウォレット、専門業界のウォレット）の成長するエコシステムが出現しています。これらのウォレットは、特に決済の文脈において、高速で低摩擦の認証と高保証の属性検証との間の根本的な違いを乗り越える必要があります。 新たなコンセンサスとして、パスキーは決済サービスへのコアな\_[認証](https://www.corbado.com/ja/blog/webauthn-client-capabilities)\_に理想的であるとされています。なぜなら、パスキーはフィッシング耐性があり、シームレスなユーザー体験のために設計されているからです。重要な決済確認ステップにデジタル認証情報の提示を挿入すると、大幅な摩擦が生じ、コンバージョン率を損なう可能性があります。したがって、デジタル認証情報の主な役割は、取引自体ではなく、決済機能を可能にする一回限りの高保証のオンボーディングと[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding)フェーズにあります。これらのウォレットは、特にデジタルID機能と組み合わせて、決済にどのようにアプローチするのでしょうか？ ### 4.1 現在の決済のためのインタラクションモデル サードパーティウォレットが支払いを承認するためには、マーチャントのアプリやウェブサイトから呼び出される方法が必要です。これにはいくつかの確立されたインタラクションモデルがあり、それぞれプラットフォームの統合レベルとユーザー体験が異なります： - **アプリ間ディープリンク：** これは、マーチャントのアプリケーション（ネイティブまたはウェブ）がカスタムURLスキーム（例：`eudi-wallet://...`）を使用してユーザーをサードパーティのウォレットアプリにリダイレクトする普遍的な方法です。取引の詳細はURLのパラメータとして渡されます。ユーザーがウォレットアプリで支払いを確認した後、別のディープリンクを使用してマーチャントアプリにリダイレクトされます。これは[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)とAndroidの両方で機能しますが、アプリ間の目に見えるコンテキストスイッチを伴います。 - **ネイティブウォレット選択：** ネイティブウォレット選択では、アプリケーションは登録されているすべての決済ハンドラまたはウォレットを表示する汎用システムサービスを呼び出すことができます。ユーザーはシステムが提供するUIから好みのウォレットを選択できます。これは単純なディープリンクよりも統合された感覚を提供します（Digital Credential API）。 - **シンプルなQRコードベースの決済：** このモデルは、デスクトップからモバイルへのフローに最適です。マーチャントのウェブサイトは、取引詳細またはURLを含むQRコードを表示します。ユーザーはモバイルウォレットアプリでこのコードをスキャンし、その後、電話で独立して確認を処理します。ウォレットのバックエンドは、承認をマーチャントのシステムに通信します。 - **標準化されたクロスデバイスフロー（FIDO CTAP）：** QRコード方式の進化形で、[FIDO](https://www.corbado.com/ja/blog/visa-passkey)のClient to [Authenticator](https://www.corbado.com/glossary/authenticator) Protocol（[CTAP](https://www.corbado.com/ja/glossary/ctap)）のようなプロトコルを使用して、デスクトップブラウザ（クライアント）とモバイルウォレット（オーセンティケーターとして機能）の間に直接的で安全な暗号化されたチャネルを作成します。これは、ブラウザと電話が直接通信するため、単純なQRコードよりも安全であり、Googleがパスキーとデジタル認証情報の両方で強力にサポートしているモデルです。 - **直接的なバックエンド統合：** 一部のクローズドループシステムでは、サードパーティのウォレットアプリが、決済サービスプロバイダー（[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk)）または金融機関のバックエンドと直接やり取りして、多くの場合、独自のAPIを使用して支払いを処理することがあります。 これらのモデルは、決済確認を開始するための「トランスポート層」を提供し、その中で（EUDI Walletで詳述されているような）暗号化フローが行われます。 ### 4.2 ブラウザ統合：IDが優先、決済は別 [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26)での発表により、ブラウザがデジタル認証情報をどのように扱うかについての状況がより明確になり、ID検証と決済処理の分離が固まりました。プラットフォームは、サードパーティのウォレットが[W3C](https://www.corbado.com/ja/blog/digital-credentials-api) Digital Credentials APIを介してブラウザとやり取りして\_ID検証\_を行うことを可能にしていますが、そのアプローチは異なっています： - **Appleのスタンス（WWDC25で確認）：** Appleは、[Safari](https://www.corbado.com/ja/blog/digital-credentials-api) 26（[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) 26に同梱）で[Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) APIのサポートを公式に発表しました。彼らの[「ウェブ上でID文書を検証する」セッション](https://developer.apple.com/videos/play/wwdc2025/232/)で詳述されているように、この実装は\*\*`org.iso.mdoc`プロトコルのみをサポート\*\*します。これにより、ウェブサイトはApple Walletや他の登録済みサードパーティ文書プロバイダーアプリから検証可能な情報を要求できますが、より汎用的な[OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)プロトコルはサポートしていません。デジタル認証情報のサポートが拡大し、ウェブ統合が強化されるにつれて、システムのパフォーマンスとセキュリティを維持することがさらに重要になります。[CleanMyMac](https://cleanmymac.com/)のようなツールは、これらの技術が進化する中で[Mac](https://www.corbado.com/ja/blog/parallels-passkeys-cda)がスムーズに動作することを保証するのに役立ちます。 - **Googleのスタンス：** AndroidのCredential Managerは、サードパーティのウォレットが認証情報リクエストのハンドラとして登録することを許可します。[Chrome](https://www.corbado.com/ja/blog/digital-credentials-api)でのDigital Credentials APIの実装は、**OpenID4VP**を主要なトランスポートプロトコルとして使用することに焦点を当てています。OpenID4VPはmdocをペイロードとして運ぶことができますが、プロトコル自体はAppleの直接的な`org.iso.mdoc`アプローチとは異なります。 **重要なのは、これらのブラウザ統合はID属性のためのものであり、提示されたmDocやVCを決済手段として扱うためのものではないということです。** ユーザーがブラウザのDigital Credentials APIを介してウォレットからmDLをウェブサイトに提示した場合、そのウェブサイトはチェックアウト時の住所の自動入力や年齢確認にその情報を使用するかもしれません。しかし、実際の決済ステップでは、依然として決済方法（例：Apple Pay、Google Pay、またはカード情報の入力）との別のやり取りが必要になります。ブラウザAPI自体は、ID認証情報を使用して金融取引を開始または処理するようには設計されていません。 ## 5. EUデジタルIDウォレットの実践 EUデジタルID（EUDI）ウォレットは、サードパーティのウォレットがオペレーティングシステムとAPIの可用性という複雑な現実世界をどのように乗り越えなければならないかを示す優れたケーススタディとして機能します。その多くの機能の中で、最も顕著な2つのユースケースはID検証と決済確認であり、これら2つのタスクを達成するための技術的な経路は、特にAndroidの柔軟なフレームワークとAppleのより厳格な実装を比較すると異なります。 ### 5.1 インタラクションモデルの比較：ID vs. 決済 以下の表は、EUDIウォレットがID検証または決済承認のためにどのように呼び出されるかを分解し、プラットフォーム間のサポートの違いを強調しています。 | 統合モデル | ID (Android) | ID (iOS) | 決済 (Android) | 決済 (iOS) | | :--------------------------------- | :----------: | :------: | :------------: | :--------: | | **Digital Credentials API** | ✅ | ✅ | ✅\* | ❌ | | **ネイティブウォレットセレクター** | ✅ | ✅ | ✅ | ❌ | | **アプリ間ディープリンク** | ✅ | ✅ | ✅ | ✅ | | **標準化されたクロスデバイス** | ✅ | ❌ | ✅ | ❌ | **比較からの重要なポイント：** - **Digital Credentials API:** この新しいW3C標準はプロトコルに依存せず、両プラットフォームで**ID**に対して十分にサポートされています。その実装のために、Androidは柔軟なOpenID4VPプロトコルを使用したデフォルトのフローを提供し、さまざまな認証情報形式を運ぶことができます。対照的に、Appleの実装は厳密に`org.iso.mdoc`形式用です。重要なのは、ブラウザはこのAPIを決済開始ではなく、IDユースケースのためにスコープしていることです。 - **ネイティブウォレットセレクター:** 両方のオペレーティングシステムはウォレットを選択するためのネイティブUIを提供しますが、異なる制限があります。AndroidはIDアプリと決済アプリの両方のためのセレクターを提供します。[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)は登録されたID「ドキュメントプロバイダー」アプリのためのセレクターを提供しますが、サードパーティの決済アプリのためのものは提供しません。 - **アプリ間ディープリンク:** これは普遍的な主力であり、両プラットフォームでIDと決済の両方のユースケースで確実に機能します。iOSでサードパーティのウォレットを決済のために呼び出す主要な方法であり続けています。 - **標準化されたクロスデバイス:** この[FIDO](https://www.corbado.com/ja/blog/visa-passkey) [CTAP](https://www.corbado.com/ja/glossary/ctap)ベースのフローは現在Google/Androidエコシステムの機能であり、iOSではサポートされていません。 **(\*) DC API経由の決済に関する注意:** AndroidがOpenID4VPを使用しているため、Digital Credentials APIを介した決済フローが\_技術的に\_可能になりますが、これはその主要な設計焦点ではありません。他のネイティブメソッドとは対照的に、この特定のAPIを介した決済のシームレスな統合はまだ見られず、ブラウザベンダーからの明示的なサポートが必要になります。 この比較から、ID検証はDigital Credentials APIを通じてますます標準化されている一方で、EUDIウォレットのようなサードパーティウォレットの決済承認は、特にiOSにおいて、アプリ間ディープリンクのようなより伝統的なネイティブ統合パターンに依然として大きく依存していることが明らかです。 ### 5.2 内部の仕組み：EWC決済確認フロー ウォレットを呼び出すためにどの決済統合モデルが使用されるかに関わらず、EUDI Walletの決済確認の核心は、[`EWC RFC008`](https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc008-payment-data-confirmation.md)で詳述されている標準化された暗号化フローに依存しています。 以下は、このプロセスの高レベルなウォークスルーです： | ステップ | アクション | 主な成果物 | | -------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **承認リクエスト** | マーチャントまたはPSPは、\_Payment Wallet Attestation\_を参照する`presentation_definition`と、base64urlエンコードされた`transaction_data`オブジェクト（金額、通貨、受取人）を含むOpenID4VPリクエストをウォレットに送信します。 | | 2 | **ユーザーの確認と同意** | ウォレットは人間が読める形式の支払い詳細（例：\_Merchant XYZ\_へ23.58ユーロ）を表示し、ユーザーに生体認証ジェスチャーまたはPINで承認するよう求めます。 | | 3 | **検証可能な提示** | ウォレットは、(a)選択されたPayment Wallet Attestation（SD-JWT VCとして）と、(b)その`transaction_data_hashes`クレームがユーザーがステップ1の正確なペイロードに署名したことを証明するキーバインディングJWTを含む検証可能な提示を返します。 | | 4 | **検証** | PSPは提示を検証し、元の`transaction_data`のハッシュがJWT内のものと一致することを確認し、タイムスタンプが最近のものであることを保証します。 | | 5 | **資金移動** | SCAを満たしたPSPは、ユーザーが取引詳細を明示的に確認したと確信し、通常のカードまたは口座支払いに進みます。 | #### 例：取引データペイロード これは、ウォレットに送信される`payment_data`オブジェクトの非規範的な例で、ユーザーが確認するための取引詳細を示しています。 ```json { "payee": "Merchant XYZ", "currency_amount": { "currency": "EUR", "value": "23.58" }, "recurring_schedule": { "start_date": "2024-11-01", "expiry_date": "2025-10-31", "frequency": 30 } } ``` #### 例：キーバインディングJWTクレーム ユーザーが承認すると、ウォレットはキーバインディングJWTを作成します。そのクレームは、ユーザーが特定の取引データを確認したことを証明します。 ```json { "nonce": "n-0S6_WzA2Mj", "aud": "https://example.com/verifier", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4", "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"] } ``` ## 6. 業界の対応：決済とIDの融合 技術標準が進化する一方で、決済業界も静観しているわけではありません。主要なプレーヤーは、デジタル認証情報のセキュリティと決済の機能を融合させる方法を積極的に模索しています。 ### 6.1 決済トークン化との類似点 検証可能な認証情報（VC）の可能性を理解する強力な方法は、成功したネットワーク決済トークン化システム（[Visa](https://www.corbado.com/blog/visa-passkeys) Token Serviceや[Mastercard](https://www.corbado.com/blog/mastercard-passkeys) MDESなど）と比較することです。 - **決済トークン化**は、機密性の高いプライマリアカウント番号（[PAN](https://www.corbado.com/glossary/pan)）を安全なトークンと一回限りのクリプトグラムに置き換えました。これにより、取引中にコア資産であるカード番号が保護されます。 - **検証可能な認証情報**は、トークン化がPANに対して行ったことを個人データに対して行うことを目指しています。生のデータ（氏名、生年月日、住所）を共有する代わりに、ユーザーは信頼できる発行者からの暗号署名付き認証情報を提示します。 本質的に、**VCは個人データにとって、決済トークンとクリプトグラムがカードデータにとってのものである**と言えます。つまり、リスクを低減しプライバシーを強化する、安全で検証可能な代替手段です。 ### 6.2 検証可能な決済認証情報の台頭 この類似点に基づき、業界団体は「検証可能な決済認証情報」の概念に取り組んでいます。これは、銀行が発行する認証情報で、決済手段（トークン化されたカードなど）をパッケージ化し、取引の承認に使用できるものです。 - [**EMVCo**](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc)（安全な決済の標準化団体）は、[FIDO](https://www.corbado.com/ja/blog/visa-passkey)標準をEMV [3-D Secure](https://www.corbado.com/glossary/3d-secure)プロトコルに積極的に統合しています。これにより、事前のパスキー認証を摩擦のない承認のための強力なシグナルとして使用できる一方、[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)（[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)）が従来のOTPチャレンジに代わる、現代的でフィッシング耐性のある代替手段として機能する準備も進めています。また、検証可能な認証情報を将来的にこれらのフローにどのように組み込むかについての議論も進行中です。 - **Visa**は、FIDOオーセンティケーターを決済認証情報に安全にバインドする[**Visa Payment Passkey Service**](https://www.corbado.com/blog/visa-passkeys)を発表しました。このサービスは、チェックアウト体験を中断することなく、単一の摩擦のないステップでIDを確認し、支払いを承認するように設計されています。 - **Mastercard**は、[**Mastercard Payment Passkey Service**](https://www.corbado.com/blog/mastercard-passkeys)で同様の戦略を追求しています。これは、Token Authentication Service（TAS）を活用して、パスワードとOTPをパスキーベースの生体認証に置き換え、トークン化サービス（MDES）と緊密に統合されています。 これは明確なトレンドを示しています。業界は、ウォレットがIDと決済承認の両方の暗号学的に検証可能な証明を、単一の標準化されたフローで提示できる未来に向かっています。 ## 7. 規制の状況：触媒としてのヨーロッパ このイノベーションの多くは、特に欧州連合からの強力な規制の追い風によって加速されています。 ### 7.1 強力な顧客認証（SCA）におけるEUDIウォレットの役割 EUの[eIDAS 2.0規制](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation)は、市民にデジタルIDを提供するだけでなく、[EUDIウォレット](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en)をオンライン決済のための[SCA](https://www.corbado.com/ja/blog/visa-passkey)を実行する方法として明示的に想定しています。これは、将来的にはEUの銀行や決済プロバイダーが、ユーザーがオンライン取引を確認する方法としてEUDIウォレットを受け入れることを義務付けられる可能性があり、独自の銀行アプリやSMSコードに代わる標準ベースの代替手段を提供することを意味します。 ### 7.2 AppleのNFCの壁に囲まれた庭が（ヨーロッパで）開放 EUにおける画期的な[独占禁止法上の和解](https://ec.europa.eu/commission/presscorner/detail/en/ip_24_3706)により、Appleはこれまで閉鎖されていたiPhoneのNFCインターフェースを開放せざるを得なくなりました。[iOS 17](https://www.corbado.com/blog/apple-passkeys-integration).4（2024年3月5日リリース）以降、Appleは必要なAPIを実装し、ユーザーがデフォルトの非接触決済アプリを選択できるようにし、欧州委員会の拘束力のある期限である2024年7月25日を満たしました。これはもはや将来の見通しではなく、欧州経済領域（EEA）における現在の現実です。 この変化は、サードパーティのウォレットアプリがiOS上で独自のタップ＆ペイソリューションを提供できるようになったことを意味し、Apple Payの長年の独占に終止符を打ちました。開発者が利用できるようになった主な機能は以下の通りです： - **デフォルトウォレットの選択：** EEAのユーザーは、対象となるサードパーティアプリをデフォルトの非接触決済アプリケーションとして設定でき、サイドボタンのダブルクリックで呼び出すことができます。 - **完全な統合：** これらのウォレットは、[Face ID](https://www.corbado.com/faq/is-face-id-passkey)やTouch IDを含むiPhoneのネイティブセキュリティ機能を使用して決済を承認できます。 - **実世界での採用：** ノルウェーの**Vipps MobilePay**やドイツの**PayPal**など、いくつかの主要プレーヤーがすでにソリューションをローンチしています。 この開放がもたらす影響は大きく、すでに展開されています： - **競争の激化：** 銀行やフィンテック企業は、Apple Payと自社プラットフォーム上で直接競争できるようになり、発行者手数料の引き下げやイノベーションの促進が期待されます。 - **認証情報の広範な利用：** 同じAPIは決済だけでなく、企業のバッジ、交通機関のパス、ホテルのキーなど、Apple Walletに入れる必要なく使用できます。 - **標準化された認証情報への道筋：** これは重要な前例となります。決済アプリのNFCインターフェースを開放したのと同じ規制ロジックが、最終的には標準化された中立的な「検証可能な決済認証情報」（EUDIウォレットで試験運用されているようなもの）のサポートを義務付けるために使用され、独自のソリューションと並行して機能させることができる可能性があります。 - **世界的な前例：** この変更は現在EEAに限定されていますが、強力な世界的な前例となります。米国を含む他の地域の規制当局も注視しており、これにより世界中で同様の開放が加速する可能性があります。 ## 8. 発行事業者向けプレイブック：検証可能な決済への実践的戦略 決済発行者（銀行、スキーム、フィンテック）にとって、デジタル認証情報への移行を乗り切るには、現実的で段階的な戦略が必要です。目標は、今日管理している資産を基盤に、明日のエコシステムに備えることです。このプレイブックは、即時的で後悔の少ないアクションから、より戦略的で長期的な評価へと移行する戦略の概要を示します。 ### フェーズ1：カバレッジを拡大し、パスキーで決済を保護する（今日） 将来のウォレット戦略の基盤は、安全で広く採用されているネイティブアプリです。当面の優先事項は、アプリのリーチを最大化し、ログインと決済の両方で認証を強化することです。 1. **ネイティブアプリの導入を推進する：** あなたのモバイルアプリは未来のウォレットです。主な目的は、それを顧客にとって不可欠なツールにすることです。この普及とエンゲージメントが、将来の認証情報発行やウォレット機能の重要な基盤となります。 2. **PayPalモデルに倣い、決済にパスキーを使用する：** ログインだけでなく、決済承認のためにもパスキーを即座に導入します。Apple Payのようなネイティブプラットフォームソリューションとほぼ同等の体験を目指します。強力な顧客認証（[SCA](https://www.corbado.com/ja/blog/visa-passkey)）を要求する規制環境では、[PayPal](https://www.corbado.com/blog/paypal-passkeys)の現実的なアプローチを採用します： - パスキーを主要な認証要素として活用します。 - それらを信頼できるデバイスシグナル（例：アプリやセキュアなクッキーを介して管理される「記憶されたデバイス」）と組み合わせることで、[SCA](https://www.corbado.com/ja/blog/visa-passkey)の「所有」要素を満たします。 - この組み合わせにより、普遍的なVCサポートを待つことなく、非常に安全でコンプライアンスに準拠した、シームレスで低摩擦の決済確認体験を提供できます。 ### フェーズ2：新興技術で能力を進化させる（次の24〜36ヶ月） パスキーで保護された安全なアプリを基盤として、明確な価値を提供する新しい認証情報技術を選択的に統合し始めることができます。 3. **検証可能な決済認証情報の台頭を監視する：** 決済トークンを運ぶVCの概念は強力ですが、まだ標準化されていません。ここでのあなたの役割は、積極的な観察者であり参加者であることです。 - **アクション：** EMVCoやW3Cのような標準化団体内の進捗を注意深く追跡します。標準化された検証可能な決済認証情報が、既存のパスキーベースのフローに対して明確な利点を提供する場合に、それを活用する準備をします。 4. **IDユースケースのためにデジタル認証情報を統合する：** デジタルIDウォレット（EUDIウォレットなど）が普及するにつれて、決済ではなく\_ID関連\_のタスクのためにDigital Credentials APIを統合します。 - **アクション：** VCの提示を、それが優れている高保証プロセスに使用します： - **オンボーディングとKYC：** 新規アカウント設定を効率化します。 - **ステップアップ認証：** 高リスクなアクションのIDを検証します。 - **アカウント復旧：** デバイスを紛失したユーザーに安全な経路を提供します。 ### フェーズ3：摩擦のないベンチマークを維持し、パスキーの進化を監視する 新しい決済技術の採用に対する究極の障壁は、ユーザーの摩擦です。単純なパスキーフローを置き換える前に、VCベースの代替案は、より安全であるだけでなく、同様にシームレスであることを証明しなければなりません。 5. **ワンクリック体験に対して執拗にベンチマークを行う：** 現代の決済体験の標準は、Apple Payやウェブ上でのその追随者である[PayPal](https://www.corbado.com/blog/paypal-passkeys)のようなリーダーによって設定されています。あなたが導入する新しいフローは、彼らのほぼ瞬時のワンクリック確認と競争しなければなりません。現在のすべての兆候は、大多数の取引において、パスキーのフィッシング耐性が十分なレベルの保護と優れたユーザー体験を提供することを示しています。もしVCの提示ステップが少しでも認識できる摩擦を導入するなら、それを決済フローに追加しないでください。 6. **WebAuthn内のインバンドデバイスシグナルに注目する：** パスキーの進化は静的ではありません。デバイス固有のシグナルを提供する初期の試みは中止されましたが、標準化団体は、より強力なデバイスバインディングの信頼シグナルをWebAuthnプロトコルに直接統合することに積極的に取り組んでいます。これにより、RPはパスキー認証中に信頼できるデバイスを識別でき、別のアウトオブバンドのVC提示を必要とせずにリスクエンジンのシグナルをさらに強化できます。この分野は、パスキーの摩擦のない体験を犠牲にすることなくセキュリティを強化する最も可能性の高い道筋であるため、注意深く監視してください。 この段階的なプレイブックに従うことで、発行者は、今日のセキュリティを最大化し、ユーザー体験を向上させると同時に、明日の検証可能な決済技術を思慮深く採用する準備を整える、堅牢で実践的な戦略を構築できます。 ## 9. 決済におけるVCの課題と将来展望 デジタル認証情報が、単に[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding)をサポートしたり、決済アカウントにユーザーを認証したりするだけでなく、決済プロセスの不可欠な部分となるためには、いくつかの重要な課題に対処する必要があります： 1. **決済特化VCの標準化：** 決済専用の、安全で広く受け入れられている検証可能な認証情報形式を開発する必要があります。これには、決済トークン、取引固有のデータ、そして潜在的に動的なセキュリティ要素をカプセル化する必要があり、現在のID中心のmdocや汎用VCの範囲をはるかに超えます。 2. **決済ネットワークとの統合：** VCベースの決済ソリューションは、既存のグローバル決済ネットワーク（Visa、Mastercardなど）とシームレスに統合するか、実行可能な新しいレールを提案する必要があります。これには、複雑な技術的、セキュリティ的、ビジネスモデルの調整が含まれます。 3. **規制遵守：** 決済は厳しく規制されています（例：ヨーロッパの[PSD2](https://www.corbado.com/blog/psd2-passkeys)/SCA、世界的な[PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)）。VCベースの決済システムは、セキュリティ、消費者保護、不正防止に関するものを含む、関連するすべての金融規制を満たす必要があります。 4. **発行者とアクワイアラーの採用：** 銀行、金融機関（決済VCの発行者として）、およびマーチャントのアクワイアラーは、そのようなシステムをサポートするための[インフラ](https://www.corbado.com/passkeys-for-critical-infrastructure)に投資する必要があります。 5. **セキュリティモデル：** 決済VCに特化した堅牢なセキュリティモデルが不可欠であり、発行、保管（理想的にはハードウェア支援のセキュアエレメント内）、提示、および金融コンテキストでの失効をカバーする必要があります。 6. **ユーザー体験：** VCはユーザーコントロールを提供できますが、決済体験は、広範な採用を得るために、高速で直感的で信頼性が高いままでなければなりません。 **将来の可能性：** - **決済承認票としてのVC：** VCは、リンクされた口座からの支払い「承認」を暗号署名付きで表現し、OpenID4VPを介して提示される可能性があります。実際の資金移動は依然として従来のレールを通じて行われます。 - **決済トークンを含むVC：** 決済トークン（EMV DPANに類似）を安全に保持するための標準化されたVCが定義され、既存の決済[インフラ](https://www.corbado.com/passkeys-for-critical-infrastructure)によって処理される可能性があります。 - **クローズドループ決済VC：** 特定の発行者やコミュニティが、独自のクローズドループシステム内での決済のためにVCを作成する可能性があります。 しかし、これらは現在、大部分が概念的なものです。現在のVCとmdoc開発の主な推進力は、ブラウザAPIの具体的な実装によって固められ、決済実行ではなく、ID検証と属性の証明に焦点を当て続けています。 ## 10. 結論：発行事業者のための現実的な前進の道 デジタルIDと決済の融合は、複雑でありながらも乗り越えられる状況を提示しています。単一の普遍的な「検証可能な決済認証情報」の約束は魅力的ですが、この記事は、今日の決済発行者にとって最も効果的で実践的な戦略は、異なる現実に根ざしていると結論付けます：**最高のユーザー体験をめぐる戦いが最重要であり、パスキーが最も強力な武器であるということです。** 戦略的なプレイブックは明確です。即時的で後悔の少ない動きは、無敵のネイティブアプリを確立することに集中し、それをApple Payや[PayPal](https://www.corbado.com/blog/paypal-passkeys)が設定した摩擦のない「ワンクリック」標準に匹敵するパスキーベースの決済を展開するための手段として使用することです。このアプローチは、成熟し、広く採用されている技術を使用して、今日のセキュリティ（フィッシング耐性を通じて）とユーザー体験のコアニーズに対応します。 このモデルでは、検証可能な認証情報は、その重要でありながらも異なる役割を見出します。それらはまだ決済行為自体のためのツールではありませんが、それを取り巻く高保証のIDタスク、すなわち安全なオンボーディング、堅牢なアカウント復旧、および規制上の[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding)には不可欠です。 決済の未来は、単一の技術によって決定されるのではなく、ユーザーへの執拗な焦点によって決定されます。成功は、自社アプリでパスキー主導の体験をマスターし、検証可能な認証情報とインバンドのパスキー信頼シグナルの進化を思慮深く監視する発行者にもたらされるでしょう。彼らは、これらの新技術が単に利用可能になったときではなく、真にシームレスで、安全で、優れた決済体験という手ごわいベンチマークを満たすことができる場合にのみ、それらを統合する準備ができていなければなりません。