パスキーによるダイナミックリンキング：Secure Payment Confirmation (SPC)

Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.

Get Report

全4回の包括的なシリーズ（パート1、パート2、パート3、パート4）では、PSD2によって導入された**強力な顧客認証（SCA）**の措置にパスキーがどのように統合されるかを探りました。特に、銀行アプリケーションへのアクセスにSCAが必要とする認証要素に焦点を当てました。SCA要件は、アプリケーションへのアクセスだけでなく、電子決済トランザクションをリモートで開始し、署名する際にも適用されます。さらに、これらの要件では、ダイナミックリンキングとして知られるメカニズムの使用が求められます。この記事では、ダイナミックリンキングについて説明し、現在そして将来にわたってこのメカニズムを効果的に実装するためにパスキーをどのように活用できるかを検証します。

ダイナミックリンキングは、PSD2指令およびその実施補遺である技術的規制基準（RTS）に基づくセキュリティ要件です。この概念は、各トランザクションが認証コードによって特定の金額と特定の受取人に一意に結び付けられることを保証することで、電子決済のセキュリティを強化するために導入されました。この連携により、支払人が認証した後のトランザクション詳細の変更が防止され、それによって不正のリスクが低減されます。電子決済には、オンラインバンキングソフトウェアでの銀行振込だけでなく、クレジットカード決済やマーチャントサイトでの決済も含まれます。

PSD2指令および付随するRTSによれば、ダイナミックリンキングは「生成される認証コードが、電子決済トランザクションを開始する際に支払人によって合意された金額と受取人に固有のものであること」を保証するプロセスとして定義されています（PSD2第97条(2)）。これは、決済の詳細に変更があれば認証コードが無効になり、再認証が必要になることを意味します。

ダイナミックリンキングは、中間者攻撃など、さまざまな種類の不正に対して特に脆弱なリモート電子トランザクションに関連するセキュリティリスクに直接対処するため、PSD2において極めて重要です。

このようにトランザクションを保護することで、ダイナミックリンキングは不正なトランザクションの可能性を大幅に低下させます。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

RTS第5条は、ダイナミックリンキングにおける認証コードの要件をさらに詳しく規定しています。これらの要件には以下が含まれます：

• 支払人の認識：支払人は、決済トランザクションの金額と受取人を認識していること。

• 認証コードの一意性：各トランザクションに対して生成される認証コードは一意であり、他のトランザクションで再利用できないこと。

• 認証コードの特定性：生成されるコードと受け入れられるコードは、支払人によって確認されたトランザクションの金額と受取人のIDに固有であること。金額または受取人に変更があった場合、認証コードは無効になります。

• 安全な送信：認証コードの生成、送信、使用を含む認証のすべての段階で、トランザクションの金額と受取人の機密性、真正性、完全性が維持されること。

これらのダイナミックリンキングの技術的要件を整理したところで、次のセクションでは、新しいテクノロジーとしてパスキーがどのように役立つかを見ていきます。決済認証プロセスを合理化し、安全にするためのパスキーの可能性を探り、ダイナミックリンキングをより堅牢にするだけでなく、よりユーザーフレンドリーにする方法を検討します。

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

多くの企業がCorbadoを信頼し、ユーザーを保護し、パスキーでログインをよりシームレスにしています。今すぐ無料のパスキー相談をお申し込みください。

無料相談を申し込む

まず、ダイナミックリンキングでパスキーを使用するためのさまざまな選択肢を分析してみましょう。

このアプローチでは、パスキー自体が暗号学的なアサーションとして機能し、それが直接認証コードとして使用されます。トランザクションプロセス中に発行されるチャレンジは、金額や受取人などの特定のトランザクション詳細を具体的に反映するように生成され、その情報と共に保存されます。ユーザーがパスキーを使用してトランザクションを承認すると、一意で暗号学的に安全な署名が生成され、これを検証してトランザクションと共に保存できます。この応答は、堅牢な認証要素として機能するだけでなく、承認を特定のトランザクション詳細に直接結びつけ、PSD2のダイナミックリンキング要件に厳密に準拠します。

Become part of our Passkeys Community for updates & support.

Join

より高度な統合では、追加のトランザクション詳細をWebAuthnチャレンジ自体にエンコードします（これは技術的にはPSD2/RTSで要求されていません）。この方法では、受取人と金額の暗号学的ハッシュを、他のランダムデータと共にチャレンジに組み込むことを提案しています。これにより、認証プロセスはパスキーを通じてユーザーの身元を確認するだけでなく、トランザクション詳細の完全性を暗号学的に証明します。このアプローチは、金額や受取人の詳細が改ざんされた場合に最終的な支払いの時点で検出可能にすることで、追加のセキュリティ層を提供します。暗号学的証明は認証コードの不変の一部となり、高リスクのトランザクション環境における信頼性とセキュリティを向上させます（詳細はこちら）。

これら2つのオプションの限界と課題を分析してみましょう。

パスキーをダイナミックリンキングの文脈、特に決済認証で使用する際の限界の1つは、支払人が受取人情報について正確に知らされたという具体的な文書や保証がないことです。

パスキーはユーザー認証のための安全な方法を提供しますが、特に受取人に関するすべてのトランザクション詳細が支払人に正しく表示されたかどうかを本質的に検証するものではありません。

この問題はパスキーに特有のものではなく、さまざまなオンライン決済システムに共通の課題です。支払人が支払いを開始する前にすべてのトランザクション詳細を完全に認識し、同意することを保証することは、信頼とセキュリティを維持するために不可欠です。

パスキーをダイナミックリンキングに統合する際の最も大きな制約は、ファーストパーティ登録とサードパーティ登録の区別にあります。

ファーストパーティ決済コンテキストとは？

✔️ ファーストパーティ決済コンテキストでは、ユーザーはイシュアー/銀行のインターネットサービスおよびドメイン上で直接やり取りします。パスキーはシームレスに登録および認証できます。例えば、銀行が自社のウェブサイトでパスキーを登録し、それをオンラインバンキングソフトウェアからの支払い開始を承認するために使用するケースが考えられます。ここでは、パスキーはシームレスに機能します。銀行は、パスキーが自社のドメイン内で使用されることを保証でき、決済環境とトランザクションのセキュリティを管理下に置くことができます。

ファーストパーティ決済コンテキストにおけるMastercardのパスキー実装については、当社のブログ記事をご覧ください。

サードパーティ決済コンテキストとは？

サードパーティ決済コンテキストでは、ユーザーは異なるドメイン（例：amazon.com）のマーチャントページでチェックアウトプロセス中にクレジットカード取引を開始しようとします：

• ✔️ ケース1 – ユーザーが既にイシュアー/銀行のパスキーを持っている場合： マーチャントは、パスキーによる認証が行われるiframeを表示します。このIFRAMEは、SCAとダイナミックリンキングをサポートする必要があるクレジットカード取引のために既に導入されている3Dセキュア2（3DSS/EMV 3DS）プロセスによって表示されます。

• ❌ ケース2 – ユーザーがイシュアー/銀行のパスキーを持っていない場合： この場合も、マーチャントはiframeを表示します。まだパスキーが利用できないため、ユーザーは既存の認証要素（例：SMS OTPやスマートフォンのネイティブバンキングアプリ）によって認証されます。この時点で、認証が成功した後、ユーザーのためにパスキーを登録する絶好の機会となりますが、これはWebAuthn標準の制限により許可されていません。クロスオリジンiframeでのパスキーの登録は許可されていません（メインページとiframeのドメインが同一である必要があります）。次のスクリーンショットのような段階的な登録は不可能です：

将来的にはクロスオリジンiframeでのパスキー登録はサポートされるのか？

パスキーは単一ドメイン内のファーストパーティ決済コンテキストにおけるダイナミックリンキングには良い解決策を提供しますが、サードパーティ決済コンテキストでは現在WebAuthn Level 2でサポートされていません。しかし、良いニュースとして、クロスオリジンiframeのサポートは既に進行中のWebAuthn Level 3仕様に組み込まれています（2024年末までに一般利用可能になる予定です）。ただし、ブラウザはまだ仕様に追いつく必要があります：

今日現在、2024年までには主要なブラウザでパスキーのクロスオリジン登録が現実のものとなる可能性があり、これによりパスキーを決済に使用する上での最も大きな技術的制約が解消されるでしょう。

ウェブ上での決済体験を向上させるために、W3CのGoogle主導のワーキンググループによって、これまでいくつかの試み（例：BasicCard、PaymentHandler、PaymentManifest）が行われてきました。現在までのところ、いずれも大きな市場カバレッジと利用を得ていません。eコマース取引における決済プロセスの摩擦は、不正に対する規制が強化される中で大きな課題であり続けています。GoogleとStripeによって開始されたSecure Payment Confirmation標準は、現在WebAuthn標準を基盤として構築されている最も有望な標準です。

Secure Payment Confirmation (SPC) は、ダイナミックリンキング要件を含むPSD2 SCAのすべての重要な要素に対応し、同時にUX体験の向上を試みています。

• ブラウザネイティブなUXの提供：SPCはブラウザを活用して、異なるマーチャントサイトやリライングパーティ間で一貫性のある、合理化された認証体験を提供します。このアプローチは、一貫した外観を持ち、支払人の認識を保証することで、通常iframeでレンダリングされるコンテンツで達成される以上のトランザクションセキュリティを強化することを目的としています：

出典： https://www.w3.org/press-releases/2023/spc-cr/

• 暗号学的証拠の提供：この標準は、WebAuthnチャレンジに情報をエンコードする必要なく、ユーザーが支払い詳細を確認したことの暗号学的証明が生成され、WebAuthnアサーションに含まれることを保証します。

• サードパーティ登録の許可：WebAuthn Level 2標準ではオーセンティケーターの登録がファーストパーティコンテキストで行われなければならないのとは異なり、SPCはクロスオリジンiframeから直接パスキーを登録することを可能にします。この機能は、決済エコシステムにおける一般的なユースケースに対応し、マーチャントや決済処理業者にとっての統合を容易にします。上記で議論したように、この機能は既に基盤となる標準の次期バージョンの一部であるため、将来的にはSPCから削除される可能性があります。

• 支払いのクロスオリジン認証：SPCは、他のリライングパーティからのクレデンシャルを利用する場合でも、任意のオリジンがトランザクションのアサーションを生成できるようにすることで、WebAuthnの有用性を拡張します（ページを離れる必要はありません）。この場合、マーチャント/イシュアーからのiframeさえも不要です。この機能は、複数の当事者（マーチャント + イシュアー/銀行）が認証プロセスに関与し、アサーションを元のリライングパーティ（口座提供者、例：銀行）に転送して検証できるシナリオで特に役立ちます。

上記の例はSPC Explainerから引用したもので、支払いのクロスオリジン認証の概念を示しています。SPCを使用した決済プロセスでは、ユーザーはトランザクション中ずっとマーチャントのサイト（青色でハイライト）に留まります。ウェブブラウザ（緑色）はマーチャントのオリジンの表示を維持し、また、ダイナミックリンキングのためのすべての重要情報（金額＋受取人）を含む、事前に定義されたカスタマイズ不可能なダイアログを提示してトランザクションを確認します。ユーザーの確認後、オペレーティングシステム（オレンジ色で描写）がトランザクションを検証するために必要な生体認証を処理します。

これらの目的は、オンライン決済のセキュリティとユーザーエクスペリエンスの両方を向上させるというSPCのコミットメントを示しており、デジタル決済ランドスケープ全体で高いセキュリティ基準を維持しながら認証プロセスを簡素化することを目指しています。

SPCが許可するすべての可能なフローを見て、標準的なパスキーと比較して、その利点を理解しましょう。

ここでわかるように、最も重要な違いは、マーチャントのウェブサイトのiframe内での登録（これはまだパスキーではサポートされていません、上記の議論を参照）と、全く新しいクロスオリジン認証の可能性です。一つずつ見ていきましょう。

これは、Mastercardのページで直接SPCパスキーを登録するモックアップ例です。ご覧のように、このケースではSMS OTPによる認証が完了した直後にパスキー作成が提供されます。

この場合、通信は完全にファーストパーティコンテキストで行われるため、標準的なパスキー登録プロセスのように見えます。

出典： https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

このSPCパスキーは、マーチャントサイトでの認証、マーチャントサイト上のiframe内、およびクロスオリジン認証（下記参照）で使用できるようになります。

前述の通り、マーチャントのウェブサイトでSPCパスキーを登録するプロセスは、通常、3Dセキュア（3DS）フローの文脈で、支払いトランザクション中に行われます。このフローは、カード所有者の身元を確認する追加の認証ステップを伴うことで、オンラインのクレジットカードおよびデビットカード取引のセキュリティを強化するように設計されています。

支払いトランザクション中に3DSフローが開始されると、認証プロセスはマーチャントのサイト（例：amazon.com）でホストされているが、決済サービスプロバイダーまたは発行銀行（例：mastercard.com）によって制御されるiframeを介して促進されます。このiframeは、顧客が既存の認証要素を使用して自分の身元を認証するための安全な環境として機能します。

顧客がこれらの従来の要素（例：SMS OTPやバンキングアプリ）を使用して正常に認証されると、将来の取引のためにSPCパスキーを登録する機会があります。SPC標準はiframe内からのクロスオリジンパスキー作成を許可しているため、これは機能します。 このiframeでのパスキーの登録には、通常、顧客が互換性のあるデバイスで指紋や顔認識を検証するなど、パスキーを生成してクレジットカードに紐付けるアクションを実行することが含まれます。iframeは決済サービスプロバイダー（例：PayPal）または発行銀行（例：mastercard.com）によって制御されていることに注意してください。したがって、SPCパスキーはマーチャントではなく、イシュアー/銀行と直接作成されます。簡略化されたフローは次のようになります：

出典： https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

https://spc-merchant.glitch.me/で、GoogleはWindowsおよびMacのChrome経由でアクセスできるデモアプリケーションをセットアップしており、これがiframe内からどのように機能するかを示しています：

また、https://spc-rp.glitch.me/reauthでホストされている銀行のサイトを直接試すこともできます。この例では、マーチャントとイシュアー/銀行間のAPIによる帯域外通信は不要で、すべてがブラウザによって処理されます。既存のパスキーを使用した認証も、iframe内から同様に機能します。

次の例では、ユーザーが既にMastercardでSPCパスキーを登録しているクロスオリジン認証を見ていきます。マーチャントサイトの例（decorshop.com）はクロスオリジン認証をトリガーできます。主要かつ重要な違いは、認証プロセス中にマーチャント/イシュアーのページが一切表示されないことです。ブラウザはオペレーティングシステムと連携して、事前定義された決済UX（SPC標準のブラウザ実装によって提供）と認証モーダル（WebAuthn標準）を提示します。マーチャントとイシュアー/銀行間の通信はバックグラウンドで処理されます。

出典元（一部修正）： https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

出典元（一部修正）： https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

クロスオリジン認証を使用する場合、マーチャントはイシュアー/銀行と何らかのAPIを介して通信し、既存のクレデンシャルに関する情報を交換します（上のシーケンス図の#2）。クレデンシャルが存在し、ユーザーのブラウザがSPCをサポートしている場合、認証が開始されます。最後に、アサーションはEMV 3DSのような既存のプロトコルを介してイシュアー/銀行に返送され、そこで最終的に暗号学的に検証されます（#16）。

アサーションにはブラウザによって表示された情報も含まれているため、ダイナミックリンキングのすべての要件が満たされます。これは、UXと顧客の決済体験の向上という点で大きな一歩となるでしょう。

Secure Payment Confirmation（SPC）標準は、オンライン決済認証の世界における興味深い進展であり、セキュリティを強化しつつユーザーエクスペリエンスを合理化することを目指しています。今日現在、SPCを何らかの形でサポートしている主要なブラウザはGoogle Chromeのみです。しかし、この標準が部分的にGoogleによって開始されたことを考えると、これは驚くべきことではありません。AppleのSafariやMozilla Firefoxのような他の主要なブラウザからは、SPCをサポートする計画についての明確なシグナルがなく、コミットメントが著しく欠けています。特にAppleは独自の標準であるApple Payを推進しており、他の決済標準には関心がないようです。

SPCとWebAuthnの関連性は、開発プロセスをより困難にしています。これは、SPC標準の機能強化や修正が、冗長性を防ぎ、既存の機能に対する真の改善を提供することを保証するために慎重に評価される必要があるためです。目標は、チェックアウトフローへの直接的な統合や、異なるマーチャントサイト間でシームレスに動作できるよりユーザーフレンドリーな認証体験の提供など、WebAuthnでは完全にはカバーされていない決済プロセス内の特定のニーズに応えるためにSPCを洗練させることです。

SPCが進化し続ける中で、その普及には異なるブラウザでの採用が不可欠となります。Googleのような主要プレーヤーの関与は前向きな方向性を示していますが、SPCをオンライン決済業界全体の標準として確立するためには、より広範なサポートが必要になるでしょう。

上記で概説した課題、特に支払人の認識に関する課題は、WebAuthnワーキンググループで、WebAuthN標準内に確認拡張機能（以前は「txAuthSimple」として知られていた）と呼ばれるものに関する継続的な作業を促しました。その目的は、オーセンティケーターまたはブラウザ/OS（特権UI内）がトランザクション詳細をユーザーに表示し、リライングパーティがユーザーがこれらの詳細を実際に確認したという暗号学的証明を受け取ることを保証することです。これは、セクション3.3.1で説明した「保証されたユーザー認識の欠如」の問題に直接対処します。

Secure Payment Confirmation (SPC) が専用のブラウザ駆動ダイアログを提供するのと同様に、確認拡張機能は「What You See Is What You Sign」（WYSIWYS）の懸念に対処します。その主な目的は次のとおりです：

• 信頼できるトランザクション詳細の表示：金額と受取人をウェブコンテンツに表示させるのではなく、この拡張機能はデバイスのセキュアスクリーンまたはOSの管理下にあるブラウザUIダイアログのいずれかを活用します。
• 暗号学的証拠：オーセンティケーター（またはクライアントプラットフォーム）は、表示された正確なテキストの記録に署名します。この署名を検証することで、リライングパーティはユーザーに正しい詳細が表示されたことを確認できます。
• オーセンティケーターが表示をサポートしない場合のフォールバック：ハードウェアオーセンティケーターがテキストを表示できない場合、ブラウザがそれを表示し、[=client data=]に含めることがあります。これは保証としては弱いですが、より広い互換性を可能にします。

この拡張機能は、既存のWebAuthn拡張機能構造に新しいフィールドを追加します。リライングパーティは、confirmationと呼ばれる単純なテキスト文字列（オプションで基本的な書式設定付き）を提供します：

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

クライアント（ブラウザ）がこれを受け取ると、次のようになります：

1. プロンプト：特別な確認ダイアログでユーザーにプロンプトを表示します（これにより、これが基本的なログイン以上のものであることをユーザーに知らせます）。
2. パス：オーセンティケーターが拡張機能をサポートしている場合、同じ文字列をCBORデータとしてオーセンティケーターに渡します。
3. リターン：オーセンティケーターの出力をリライングパーティに返します。

オーセンティケーターがテキスト表示をサポートしている場合、ユーザー検証を完了する前に、そのテキストを（例えば、自身の画面や信頼できるUIに）必ず表示しなければなりません。その後、署名された出力に同じ文字列を含めます。

リライングパーティ側では、検証ステップで返されたconfirmationテキストが送信されたものと一致することを確認します。オーセンティケーター拡張機能の出力が欠落しているが、リライングパーティのポリシーがフォールバックを許可している場合、リライングパーティはクライアントデータからのconfirmation値に依存できます。これは、オーセンティケーターの代わりにブラウザがテキストを表示したことを示します。

この拡張機能に受取人と金額を埋め込むことで、ユーザーは信頼できるディスプレイ上で自分が承認している内容を正確に確認できます。ユーザーの署名は、ハッシュ化されたチャレンジだけでなく、正確なトランザクションテキストも反映するようになります。これは、PSD2のダイナミックリンキング要件にとって特に価値があります。なぜなら：

• 表示後のトランザクション詳細の不一致や変更は、署名を無効にします。
• リライングパーティは、署名時にユーザーに正しいトランザクション詳細が与えられたことを証明でき、PSD2の「支払人認識」要件を、単にチャレンジでデータをハッシュ化するよりもはるかに堅牢に満たすことができます。

確認拡張機能はまだ議論中ですが、より安全でユーザーフレンドリーなトランザクションフローに向けた重要な一歩を表しています。WebAuthn仕様に直接組み込むことで、次のことを提供します：

• 相互運用性：拡張機能を実装するすべてのオーセンティケーターまたはクライアントは、同じ標準化された形式に従います。
• 柔軟性：リライングパーティは、より強力なポリシー（オーセンティケーターレベルの表示を要求）を強制したり、必要に応じてブラウザレベルのフォールバックを受け入れたりできます。
• より広範なエコシステムとの連携：特に堅牢なダイナミックリンキングに関して、PSD2のような規制上の義務とよく連携します。

より技術的な詳細については、進行中の議論をご覧ください： GitHubプルリクエスト #2020。要約すると、確認拡張機能は、標準的なパスキーベースのフローにおける最後の大きなギャップ、すなわち、ユーザーが同意したときに何を正確に見たかの暗号学的証明を提供することもできますが、Secure Payment Confirmationよりも構造化されていません。ブラウザやオーセンティケーターベンダーの間で支持を得られれば、PSD2のダイナミックリンキング、そしてそれ以降で必要とされるWYSIWYSセキュリティ保証を提供するための高度に標準化された方法になる可能性があります。

SPCと確認拡張機能は、WebAuthnにおけるダイナミックリンキングを強化するという共通の目標を共有していますが、スコープとアプローチが異なります。以下の表は、これらの違いのいくつかを強調しています：

本質的に、SPCは包括的な決済ソリューションを提供しようと試み、そのフローの一部としてダイナミックリンキングも組み込んでいます。一方、確認拡張機能は、完全な決済フローを強制することなく、標準的なWebAuthnメッセージ内で_「見たままを署名する」_要件に対処します。どちらのアプローチもPSD2コンプライアンスを促進する可能性がありますが、それぞれが現実世界の利益をもたらすためには、ブラウザとオーセンティケーターのサポートに依存しています。

したがって、イシュアー、銀行、金融機関への私たちの推奨事項は、どのユースケースをカバーする必要があるかを慎重に評価し、エコシステムの発展を監視することです。パスキーの容易さは、既存のSCAおよびダイナミックリンキングソリューションにUXを改善するための大きなプレッシャーをかけるでしょう。顧客はウェブでの生体認証ソリューションを要求するようになります。現時点での私たちの運用上の推奨事項は次のとおりです：

• ✔️ イシュアー/銀行のウェブサイトで開始される決済のためのパスキー： パスキーは、イシュアー/銀行が自社のウェブサイトやアプリにダイナミックリンキングを直接実装するための非常に優れたソリューションです。高リスクの支払いに対してセキュリティをさらに強化するために、プッシュ通知、メール/SMS OTP、またはTOTPなどの他の認証オプションと組み合わせることができます。もちろん、SCAコンプライアンスに関する考慮事項は常にこの議論の一部であるべきです（パスキーとSCAに関する当社の4部構成シリーズも参照してください）。

  提案されたソリューションは、パスキーがオープンなWebAuthn標準に基づいているため、イシュアー/銀行自身で実装できます。しかし、これには相当なノウハウ、エッジケースの処理、そしてすべての新しい規制や技術開発に継続的に追いつくことが必要です。代替案は、サードパーティの認証プロバイダーを使用することです。例えば、Corbado Connectは、調整されたWebAuthnチャレンジを活用して、トランザクション署名によるダイナミックリンキングをサポートしています。すべての情報は監査ログに記録されます。これは金融機関にとって有用であるだけでなく、あらゆる種類の署名（例：文書署名、高リスクのユーザーアクション）にも活用できます。オプションで、追加のSMSまたはEメールOTPを使用してセキュリティをさらに向上させることもできます。

• ❌ マーチャントページでの決済のためのパスキー： マーチャントページでの決済にパスキーを展開することはまだ不可能です。クロスオリジンのユースケースはまだ開発中ですが、2024年末には実行可能な選択肢になる可能性があります。ただし、マーチャントページでの認証にパスキーを使用することは、今日でも素晴らしいアイデアであり、将来的に決済にも使用できるパスキーの収集を開始するためにも利用できます。

• ❌ ダイナミックリンキングのためのSPCパスキーまたは確認拡張機能： SPC標準は、本番環境で使用できるほど成熟した状態やサポートにはまだ達していません。

全体として、マーチャントや銀行がこの標準に関与し始め、彼らの要件やサポートをエコシステムに追加していることを見て嬉しく思います。今後、金融機関やeコマースプラットフォームは、これらの技術的進歩を注意深く監視し、パスキーを自社のシステムにどのように統合するかを検討すべきです。規制が進化し続ける中で、決済認証プロセスが最新のセキュリティ基準に沿っており、コンバージョンを改善し摩擦を減らす、安全で効率的なユーザーエクスペリエンスを消費者に提供することが重要です。

なぜパスキーは重要なのか？

企業向けパスキー

パスワードとフィッシングは企業をリスクにさらします。パスキーは、セキュリティとUXのバランスを取る唯一のMFAソリューションです。当社のホワイトペーパーでは、実装とビジネスへの影響について解説しています。

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

ダイナミックリンキングのためのパスキーをレビューすると、パスキーはSCAおよびダイナミックリンキングに準拠するのに役立つ一方で、元々ファーストパーティコンテキスト用に設計されたWebAuthn標準とのサードパーティサービスにおける技術的統合にはいくつかの課題があることが明らかです。これらの標準は、サードパーティのシナリオをより良くサポートするために徐々に進化しており、その適用においてより大きな柔軟性への移行を示しています。Secure Payment Confirmation (SPC) は、この適応をさらに進め、さまざまなマーチャントサイト間でよりユーザーフレンドリーでシームレスなインタラクションを組み込むことで、決済認証プロセスを強化することを目指しています。

しかし、SPC標準または確認拡張機能の進歩とより広範な受け入れは、主要なブラウザによる採用に大きく依存しています。このプロセスは遅く、現在Google Chromeが唯一のサポーターです。この遅い採用率は、より多くのブラウザが統合を開始しない限り、特にSPCが現在の状態から脱却するのを妨げる可能性があります。パスキーの継続的な開発と増加する牽引力は、セキュアエンクレーブ、TEE、TPMなどのハードウェアセキュリティモジュール（HSM）に依存するシステムが、決済アプリケーションにとっても重要な役割を果たすであろう有望な方向性を示唆しています。これらの技術は、銀行サイトで開始される取引だけでなく、サードパーティのマーチャントプラットフォームでも、決済のダイナミックリンキングをより実用的で快適にする強化されたセキュリティを提供するためです。

パスキーがその有用性をオンライン決済プロセスにまで拡張する可能性は、ウェブベースのトランザクションを保護し、インターネット全体をより安全な場所にする上で重要な側面を浮き彫りにしています。