Corbadoのアプローチは、フィッシング耐性の高いパスキー（SCA）と、銀行が管理する表示およびサーバーサイドのダイナミックリンキングを組み合わせることで、PSD2 RTS第5条（「見たものが署名するもの」）の要件を満たします。

• 主要な実装（現在）： パスキー認証の直前および認証中に、Bison-Bankが管理するUIで取引の金額と受取人を表示します。当社のバックエンドでは、正規化された取引情報（金額、受取人、取引ID）に紐付けられたワンタイムのチャレンジを生成します。レスポンスは、その情報と一致する場合にのみ受け入れられ、いかなる変更も無効とします。

• 規制上の立場： パスキーを使用する場合でも、リモート決済にはダイナミックリンキングが引き続き必要です（PSD2第97条(2)、RTS第5条）。RTSは、ダイナミックリンキングの「認証コード」をデバイス上で計算することを要求していません。表示の完全性、特定性、変更時の無効化が徹底されている場合、サーバーサイドでの生成・検証は許容されます（コードの計算場所に関するEBA Q&A 2020_5366も参照）。

• セキュリティと監査可能性： ハードウェアに固定された、フィッシング耐性の高いパスキー署名を特定の取引データに紐付けることで、改ざんや中継攻撃を防ぎ、支払者の同意に関する強力で否認不可能な証拠となります。対応している場合は、オプションでSecure Payment Confirmation (SPC)を採用し、バックエンドのモデルを変更することなく表示された詳細情報の暗号学的証明を追加できます。

• SCA：異なるカテゴリ（知識/所持/生体）からの2つの独立した要素で、適切な緩和策により開示や複製から保護されていること（RTS第6〜8条）。独立性が求められ（第9条）、多目的デバイスで実行される場合は分離も必要です（例：OSレベルの保護、セキュアハードウェア）。
• ダイナミックリンキング（RTS第5条）：
  • (i) 認証中に支払者が金額と受取人を認識できること
  • (ii) 認証コードがその金額/受取人に固有であること
  • (iii) いかなる変更もコードを無効にすること
  • (iv) 金額、受取人、コードの機密性/完全性がエンドツーエンドで保護されていること。これにより、規制が意図する「見たものが署名するもの」が実現されます。
• 意味合い：強力なユーザー認証だけでは、決済には不十分です。承認は特定の取引データに紐付けられ、その紐付けと支払者への表示に関する監査可能な証拠が必要です（RTS第5条(1)(a–d)）。

明確化 — フィッシング vs. 認可： パスキーはオリジンに紐付けられているため、偽のドメインでは有効な署名を引き出せません。しかし、PSD2ではリモート決済において、_認可_を正確な金額と受取人に紐付け、いかなる変更も無効にし、支払者に表示される内容の完全性を保護するために、ダイナミックリンキングが依然として必要です（RTS第5条(1)(a–d)）。ダイナミックリンキングは、フィッシングだけでなく、認可の完全性（MITM/MITB/TPPによる差し替えを含む）に対応します。

EBA 2019年意見書（EBA‑Op‑2019‑06）は、ダイナミックリンキングが認証を金額と受取人に紐付けることを強調し、要素の独立性を要求し、デバイス固有の紐付けが存在する場合にデバイスに紐付いた暗号鍵を所持要素として認めています。また、認証中に支払者に表示される内容の完全性も重視しています。 EBA Opinion 2019

PSD2以前、多くの銀行はSMS OTPや印刷されたTANリストに依存していましたが、これらは承認ステップで金額や受取人が表示されないことがよくありました。この欠点により、認証情報が盗まれた後、顧客を騙して意図しない送金を承認させることが容易でした。ダイナミックリンキングは、認証時に支払者が正確な金額と受取人を認識できるようにし、認証コードをこれらの詳細情報に固有のものとすることで、いかなる変更も無効にするという目的で導入されました（RTS第5条(1)(a–d)）。SMSがフローの一部である場合、発行者は認証の全段階で金額/受取人およびコードの機密性、真正性、完全性を保証する必要もあります（Q&A 2018_4414; RTS第5条(2)）。今日のアプリ内承認（例：「Face IDでジョン・スミスへ100ドルを承認しますか？」）は、この「見たものが署名するもの」の原則を顧客に使いやすい形で実装しています。

今日、モバイルでは2つのパターンが主流です。1つ目は、プッシュ通知で顧客をアプリにディープリンクさせ、取引詳細を確認して承認させる方法です。監督当局は、第7条の管理策が導入され、不正利用を防止し複製を防ぎ、全体的なプロセスがRTSに準拠していれば、プッシュ通知は所持要素の証拠となり得ると明確にしています。それでもソーシャルエンジニアリングのリスクは残るため、UXで対応すべきです（Q&A 2019_4984; RTS第7条）。

2つ目は、デバイスのネイティブ生体認証（PINフォールバック付き）を使用した承認で、秘密鍵の操作を解除するためにローカルでユーザー検証を行います。秘密鍵はセキュアなハードウェア環境（Secure Enclave/TEE/TPM）に存在し、チャレンジに署名します。これはSCAに明確に対応します：生体認証（生体要素）と、デバイスへの紐付けおよびデバイスに紐付いた暗号鍵によって証明される所持要素です（EBA‑Op‑2019‑06、パラグラフ25、35–37）。リモート決済の場合、コードは金額と受取人に動的にリンクされ、これらの詳細はユーザー検証の前に支払者に表示されなければなりません（RTS第5条）。両方の要素が1つのデバイス上にある場合、一方の侵害が他方を侵害しないように、分離されたセキュアな実行環境と完全性チェックを実装する必要があります（RTS第9条(2)–(3)）。

内部的には、ローカル生体認証は銀行に直接「認証」するわけではありません。代わりに、生体認証（またはPINフォールバック）がデバイス上でユーザー検証を行い、ハードウェアベースのセキュリティモジュールに保存されたエクスポート不可能な秘密鍵へのアクセスを許可します。支払者が承認すると、デバイスはその秘密鍵を使用して、銀行が提供したチャレンジに対するデジタル署名を生成します。銀行がそのチャレンジを取引の正規化されたスナップショット（金額、受取人、識別子）から導出または関連付けると、結果として得られる署名は、これらの詳細に固有の認証コードとして機能します。保存されたスナップショットが一致しなくなるか、または強化された設計ではチャレンジの導出方法が変わるため、いかなる変更もコードを無効にします。支払者認識の部分はUX要件として残ります：ユーザー検証の直前に、銀行が管理するビューで金額と受取人を表示することです。これらを合わせることで、RTS第5条の認識、特定性/一意性、変更時の無効化に関する要件を満たし、第7条の管理策とデバイスへの紐付けが所持要素を証明します。

• 所持（デバイス紐付け型および同期型キー）：パスキーの秘密鍵はセキュアハードウェア（TEE/Secure Enclave/TPM）に保存されます。デバイスに紐付いたパスキーはエクスポート不可能であり、デバイス固有の紐付けに関するEBAの期待と一致します（EBA‑Op‑2019‑06、パラグラフ25、35–37）。同期パスキーも、デバイスへの紐付けと複製防止策が有効であれば、認証ごとに所持を証明できます。規制当局は、要素とデバイス間の信頼できるリンクの必要性を強調しています（EBA‑Op‑2019‑06; RTS第7条）。
• 生体/知識（ユーザー検証）：生体認証（生体要素）またはデバイスPIN（知識要素）によるユーザー検証が、ローカルで鍵を有効化します。これを所持と組み合わせることで、要素の独立性を備えた真の2FAとなります。一方の侵害が他方を危険にさらしません。

ダイナミックリンキングは、認証を取引に紐付けることです。銀行にとっての問いは、「ユーザーがパスキーで支払いを承認できるようにした場合（例えば、OTPや署名デバイスの代わりに）、この承認が意図した金額と受取人に固有であり、再利用や操作ができないことを保証できるか？」ということです。

パスキーでダイナミックリンキングを実装するには2つの選択肢があります：

• サーバーサイドリンキング（標準）： バックエンドが正確な金額と受取人に関連付ける、ワンタイムのWebAuthnチャレンジを生成します。ユーザーは銀行管理のビューで「YにXユーロ」と表示されるのを見て、パスキーで承認します。レスポンスはその取引に対してのみ受け入れられます。いかなる変更も無効になります。
• 暗号学的包含（強化版）： 金額/受取人のハッシュをチャレンジに埋め込み、署名が取引データにコミットするようにします。これはRTSで要求されていませんが、バックエンドでの差し替えも検証に失敗するという保証が加わります。

明確なコンプライアンス注記： RTSは、ダイナミックリンキングの「認証コード」を支払者のデバイスで計算することを要求していません。PSPは、金額/受取人が保護され、いかなる変更もコードを無効にする限り、サーバーでそれを生成・検証できます（コードの場所/タイミングに関するEBA Q&A 2020_5366を参照）。これが、当社の**サーバーサイドダイナミックリンキング（標準）**アプローチです。

どちらも、取引に固有で再利用不可能な「認証コード」を生成します。主な注意点は支払者認識です：WebAuthn自体は何が表示されたかを証明しません。表示の完全性は、銀行が管理するUIによって確保されなければなりません。

RTS第5条は、支払者が認証中に金額と受取人を見ることを要求します。WebAuthnは何が表示されたかを証明しません。理論上、アプリやOSが侵害された場合、認証装置が署名している間にユーザーが誤解させられる可能性があります。このリスクが実際にはどのように作用し、なぜ本当のセキュリティリスクではなく、規制解釈の問題であるかを以下で詳しく分析します。

私たちが実施する表示の完全性に関する管理策：

• 銀行管理のビューで金額＋受取人をレンダリング：ビューが隠されたり、フォーカスが外れたりした場合は、パスキーの呼び出しをブロックします
• アプリ/Webでのオーバーレイ/改ざん検出：隠されたiframeからのパスキープロンプトは表示しません
• デバイスの完全性/構成証明によるゲート：ルート化/ジェイルブレイク/侵害されたシグナルがある場合は拒否またはステップアップします
• サーバーが保持する金額/受取人のスナップショットに対するアトミックな承認：パラメータが変更された場合は、新しいチャレンジが必要です

暗号学的包含について： WebAuthnの「取引表示」拡張機能（SPC）は、今日では広くサポートされていません。当社のポータブルなベースラインはサーバーサイドの紐付けであり、取引スナップショット（例：H(金額 ‖ 受取人 ‖ 取引ID ‖ nonce)）からチャレンジを導出することで強化し、署名がこれらの値にコミットするようにしています。

どちらのパターンも、エクスポート不可能なデバイスキーを持つ公開鍵暗号を使用し、署名操作を解除するためにローカルのユーザー検証に依存します。どちらの場合も、銀行はユーザー検証の直前に銀行管理のビューで金額と受取人を表示することで支払者認識を保証し、認証コードをこれらの詳細に紐付けることで特定性を保証します（いかなる変更も無効にします）（RTS第5条(1)(a–d)）。RTSは技術中立であり、OSの生体認証モーダル内で金額/受取人をレンダリングすることを要求していません。支払者への表示とコードの紐付けを要求しています（RTS第5条）。両方のSCA要素が1つのデバイスで実行される場合、第9条の完全性と分離の要件が等しく適用されます（RTS第9条(2)–(3)）。最後に、ダイナミックリンキングの計算場所は柔軟です。完全性が維持され、いかなる変更もコードを無効にする場合、サーバーサイドで実行できます（Q&A 2020_5366）。これらは、規制当局がすでにPKIを用いたローカル生体認証を認めているのと同じ条件です。したがって、同じ支払者認識と紐付けの管理策で実装されたパスキーも、同等の基準で受け入れられるべきです。

では、WebAuthn標準に準拠した通常のパスキーは、ダイナミックリンキングの_意図を満たす_のでしょうか？ 部分的にです：

• MITM/ネットワーク攻撃： はい。オリジンバインディングとチャレンジごとの署名が改ざんとリプレイを防ぎます。
• 取引の完全性： はい。サーバーでの関連付けまたはチャレンジのハッシュ化により、元の金額/受取人のみが検証されることを保証します。
• 支払者の同意： より難しい。パスキーには認証装置レベルの表示機能がありません。侵害されたデバイスでのUI詐欺の可能性があります。支払者の同意を保証するためには、何かを追加で構築する必要があります。

パスキーを使用してもダイナミックリンキングが必要な理由

• 法的理由： PSD2第97条(2)およびRTS第5条は、すべてのリモート決済開始に対してダイナミックリンキングを義務付けています。フィッシング耐性の高い方法に対する例外規定はありません。
• セキュリティ上の理由： パスキーはクロスオリジンのフィッシングを排除しますが、それ自体では支払者に何が表示されたかを証明しません。ダイナミックリンキングと表示の完全性に関する管理策により、ユーザーが見た特定の金額/受取人を銀行が実行し、いかなる変更も承認を無効にすることが保証されます。

要約すると、パスキーは取引データに厳密に紐付けられ、信頼できる表示メカニズムと組み合わせることで、ダイナミックリンキングを満たすことができます。残る課題は、ユーザーが実際に何を見たかを証明することです。

Corbadoは、上記の支払者同意に関する考慮事項に明示的に対処する、ダイナミックリンキング準拠のソリューションを提供します。

プロセスフロー：

• 銀行管理の表示で、支払者に正確な金額と受取人を示します。このビューが表示されていない限り、パスキーのプロンプトは表示されません。
• 認証： クライアントは、正規化された取引に対して、ワンタイムで紐付けられたチャレンジを用いてWebAuthnを呼び出します。認証装置はユーザー検証（生体認証またはデバイスPIN）を行い、チャレンジとオリジンに署名します。
• サーバー検証： バックエンドはRP IDのハッシュとオリジンを検証し、チャレンジを保存された取引と照合し、UV/フラグをチェックし、ワンタイム使用と有効期限を強制し、保存された金額/受取人のスナップショットを比較します。
• 承認と監査： その後初めて、取引はアトミックに承認されます。不一致/変更は拒否され、新しい認証が必要です。不変の監査記録（クレデンシャルID、authenticatorData、clientDataJSON、署名、チャレンジ、正規化された金額/受取人）が永続化され、オプションで改ざん防止のためにハッシュチェーン化されます。
• デバイスの完全性ゲート： デバイスの完全性と構成証明シグナルを評価します。デバイスがルート化/ジェイルブレイク/侵害されている場合は、拒否またはステップアップします。
• 受取人の正規化： フレンドリーなラベル（例：「ACME株式会社」）を表示しますが、正規の受取人識別子（例：IBAN/BICまたはその他の一意のスキーム）に対して紐付けと検証を行います。

技術詳細：

• バックエンド： 正規化されたデータ（例：正規化された通貨/小数、正規化されたIBAN/受取人）を持つ取引オブジェクトを作成します。これらの値にコミットする短命のチャレンジ（例：H(金額||受取人||取引ID||nonce)）を生成し、保留状態で保存し、クライアントには不透明なIDのみを公開します。

• クライアント/認証装置： 銀行管理のビューで支払者の詳細をレンダリングし、表示されている場合にのみWebAuthn（RP ID

  Bisonドメイン）を呼び出し、ユーザー検証を要求します。認証装置はWebAuthnに従ってチャレンジ＋オリジンに署名します。
• 検証/最終処理： 署名、RP IDハッシュ、オリジン/タイプ、UVフラグを検証し、リプレイ防止/有効期限チェックを行い、不変の金額/受取人スナップショットを比較し、アトミックに承認し、監査記録を永続化します。
• スナップショットからチャレンジを導出：： challenge = H(amount ‖ canonicalPayee ‖ txnId ‖ nonce)

UXポリシー：

• 金額/受取人を明確に強調し、アクセスしやすい確認/キャンセル制御、短いタイムアウト、常に新しいチャレンジを使用した丁寧な再試行、即時の領収書（例：「YへXユーロを承認しました」）を提供します。表示が隠されている場合はパスキープロンプトをブロックし、署名前にパラメータが変更された場合は警告します。
• オーバーレイ/隠されたコンテンツを検出：取引ビューが表示されていない場合は、パスキープロンプトを絶対に表示しません。フローの途中でパラメータが変更された場合は拒否し、新しいチャレンジで再開します。

コンプライアンス注記： このエンドツーエンドの設計はRTS第5条を満たします：支払者認識（銀行管理の表示）、特定性と一意性（金額/受取人に紐付けられたワンタイムコード）、変更時の無効化（厳格なサーバーチェック）、および全段階での金額/受取人とコードの機密性/完全性（RTS第5条(1)(a–d)、5(2); SMSの完全性についてはQ&A 2018_4414も参照）。要素の独立性（第7–9条）は、デバイスに紐付いた所持と、適切な保護を備えた多目的デバイスでのローカルユーザー検証を通じて維持されます（RTS第9条(2)–(3)）。

注：* ウェブフローの場合、CorbadoはAppleが広範なサポートを提供した場合にオプションで[Secure Payment Confirmation](https://www.w3.org/TR/payment-request-secure-payment-confirmation/)を採用し、金額と受取人を暗号学的に証明する、信頼できるブラウザ仲介の表示を追加します。

懸念：フィッシング攻撃 対応： パスキーは設計上、フィッシング耐性があります。正当なオリジンに紐付けられており、共有される秘密情報がないため、OTPのように偽サイトで認証情報を収集されることはありません。トラフィックを模倣ドメインにプロキシする攻撃者は、銀行のオリジンに対する有効な署名を得ることはできません。このベクトルではダイナミックリンキングの貢献度は低いですが、いかなる承認も意図した金額と受取人に固有であることを保証するために依然として必須です。補完的な対策（フィッシング教育、ログインと決済承認の明確な分離、異常な決済コンテキストに対する異常/リスクスコアリング）により、リスクはさらに低減されます。

懸念：ソーシャルエンジニアリング / 正規プッシュ決済（APP）詐欺 対応： どんな認証装置も、ユーザーが偽の口実（例：「安全な口座」詐欺）で支払いを承認するのを完全に防ぐことはできません。ダイナミックリンキングは、ユーザーが受取人と金額を明確に確認し、同意の強力な証拠を提供することを保証しますが、確信している支払者の意思を覆すことはできません。補完策には、コンテキストに応じた警告（新しい受取人、初回の大口送金）、高リスク受取人に対するクーリングオフ期間や遅延実行、より強力な受取人検証、リスクシグナルに対するステップアップチェック（追加確認）などがあります。支払い後の通知と迅速な紛争解決チャネルは、被害の検出と抑制に役立ちます。当社は、リアルタイムのコンテキストに応じた警告（例：新しい受取人、初回の大口送金）、高リスク受取人に対するクーリングオフ期間、より強力な受取人検証、そして検出と対応を迅速化するための支払い後通知（「YへXユーロを承認しました」）を追加します。

懸念：マルウェアまたはデバイスの侵害 対応： 秘密鍵はエクスポート不可能であり、署名ごとにローカルユーザー検証が必要なため、マルウェアは単に認証情報を抜き取ることはできません。現実的なリスクは、完全に侵害されたOSでのUI詐欺です。セキュア/検証済みUI（例：保護された確認画面）、デバイスの完全性チェック/構成証明と高リスクデバイスのブロック、そしてSPCや利用可能な場合は確認拡張機能などの信頼できる確認手段で緩和します。侵害の兆候（オーバーレイ検出、ルート化/ジェイルブレイク）が現れた場合は、帯域外での再検証を使用するか、実行を拒否します。完全に掌握されたデバイスに対する完璧な消費者向け方法は存在しませんが、これらの統制は攻撃の機会を劇的に狭めます。

懸念：中間者攻撃（Man‑in‑the‑browser） / セッションハイジャック 対応： 悪意のある拡張機能や注入されたスクリプトは、正当なオリジンでアクションを開始できます。オリジンに紐付いたパスキーはクロスサイトフィッシングを阻止します。ダイナミックリンキングは、裏で行われる金額/受取人の編集が失敗することを保証します。私たちはCSP/改ざん防止制御を通じてチャネルを強化し、各確認に対して新鮮なワンタイムチャレンジを要求することで対応します。

懸念：内部脅威またはサーバーサイドの改ざん 対応： 認証レスポンスは元の金額/受取人に一意に結びついているため、サーバーサイドでのいかなる差し替えも検証に失敗します。監査/否認防止のために、改ざん防止機能のある不変のリンケージレコード（チャレンジ、クレデンシャル、署名、正規化された金額/受取人）を維持します。重要な決済処理パスに職務分掌と四つ目原則を適用し、内部リスクを低減します。

懸念：デバイスの盗難 / 認証情報の盗難 対応： デバイスを所持しているだけでは不十分です。各署名にはユーザー検証（生体認証/PIN）が必要で、OSレベルでのレート制限とロックアウトがあります。各支払いには、取引固有の新鮮なチャレンジが必要です。汎用的なセッショントークンで任意の支払いを承認することはできません。リモートでのデバイス失効、新しいデバイス使用時のステップアップ、ジオベロシティチェック、通知（「YへXユーロを承認しました」）などの追加機能により、不正利用をさらに抑制します。

全体として、パスキーはフィッシングとリプレイのリスクを大幅に削減します。ダイナミックリンキングは、取引の完全性を保証し、承認を金額/受取人に紐付け、残りの脅威シナリオ全体で情報に基づいた同意の強力な証拠を提供するために不可欠です。

質問1： パスキーを使用する際、ユーザーが実際に金額と受取人を見て同意したことをどのように証明できますか？ 回答： 私たちは、銀行管理のビューでの支払者への表示を強制し、承認を金額/受取人のサーバーサイドのスナップショットに結びつけます。パスキーのアサーション（authenticatorData, clientDataJSON, 署名）は、そのスナップショットから導出されたチャレンジに対してのみ受け入れられます。いかなる変更も新しいチャレンジを必要とします。私たちの改ざん防止監査は、アサーションを「受取人ID YへXユーロ」にリンクし、詳細が異なればシステムが進行しないことを記録します。サポートされている場合、SPCは、ユーザーが表示された詳細を確認したことの暗号学的証拠を追加します。

質問1： パスキーを使用する際、ユーザーが実際に金額と受取人を見て同意したことをどのように証明できますか？ 回答： これは本質的に否認防止の問題です。PSD2の下で、ダイナミックリンキングはユーザーが承認内容を認識していることを保証するために意図されました。パスキーの場合、私たちが保持する証拠は暗号署名（認証コード）と関連データ（それが当社のサーバーでどの金額/受取人に結びついていたか）です。ポリシーとして、ユーザーが認証する前にアプリやウェブページで取引詳細を表示します。その画面/ビューと、その特定の取引に対する後続の成功したパスキー認証をログに記録します。紛争の場合、ユーザーのデバイスが（例）「ACME社へ100ユーロ」に関連付けられたチャレンジに対して有効な署名を生成したこと、そして詳細が異なれば当社のシステムは進行しなかったことを示すことができます。当社のコンプライアンスは安全なロギングに依存しています：パスキーのレスポンスを取引データにリンクする際に、当社のシステムが改ざん防止であることを保証します。

質問2： デバイスやOSが侵害された場合はどうなりますか？ マルウェアは取引やパスキープロセスを操作できますか？ 回答： デバイスの侵害は、あらゆるデジタルバンキングシナリオにおける重大な脅威です。オペレーティングシステムが悪意のあるものである場合、ユーザーを誤解させたり、プロセスをハイジャックしたりしようとする可能性があります。しかし、この最悪のケースでさえ、パスキーはいくつかの重要な保護を維持します。秘密鍵はマルウェアによって抽出できません。マルウェアは、ユーザーの生体認証/PINなしではパスキー署名を生成できないため、銀行に対してユーザーになりすますこともできません。マルウェアができることのほとんどは、ユーザーに偽の口実で何かを認証させることです。ダイナミックリンキングは、完全性チェックを要求することでここで役立ちます。マルウェアは事後に取引詳細を静かに変更することはできません。もし変更すれば、署名は検証されません。最も弱い点は表示/UIです。洗練されたトロイの木馬は、ユーザーが見るものを変更する可能性があります（例：「ACME社」を表示しながら、実際の取引は別の受取人に向かっている）。これは、特に銀行アプリがセキュアなUIフレームワークを使用している場合は簡単ではありませんが、考えられます。とは言え、デバイス侵害の兆候（異常な動作、既知のマルウェアシグネチャなど）を検出した場合、帯域外の検証にフォールバックするか、取引を拒否します。要約： ユーザーのデバイスが攻撃者に完全に掌握されている場合、100%の解決策はありません。パスキーとダイナミックリンキングは攻撃対象領域を劇的に減らします（攻撃者は単に認証情報をプロキシしたり、ネットワークデータを変更したりすることはできず、リアルタイムでユーザーを騙す必要があります）。OSが侵害された場合でも、ダイナミックリンキングは少なくとも、あるべき姿と承認された内容との間の不一致がバックエンドで検出されることを保証します。

質問3： パスキーのロック解除に生体認証が使用される場合、それは1要素と見なされますか、それとも2要素ですか？ 2要素認証のルールを遵守していますか？ 回答： 生体認証だけではSCAには不十分です。それは単なる生体要素の一つです。しかし、パスキーの実装では生体認証は_単独ではありません_。デバイスの所持がもう一つの要素です。ユーザーの生体認証は、_デバイスに保存されている_秘密鍵を解除します。所持と生体は2つの異なるカテゴリです。これは、多くのバンキングアプリがすでにSCAを満たしている方法に類似しています。つまり、電話を持っている（所持）かつ、指紋や顔認証でアプリを解除する（生体）という組み合わせです。EBAは、デバイスへの紐付けと生体認証の組み合わせを準拠したSCAとして明確に認めています。パスキーのシナリオはまさにその組み合わせです。ユーザーが生体認証の代わりにPINを使用してパスキーを解除する場合、それは所持＋知識となり、これも準拠しています。私たちはすべてのパスキー操作でユーザー検証を強制しているため（つまり、ユーザーは毎回生体認証/PINを提供する必要があります）、デバイスを持っているだけで十分な状況はありません。したがって、パスキーを介したすべての支払い承認は、PSD2の定義の下で_2要素_のイベントとなります。

質問4： 攻撃者はパスキー認証を再利用したり、通信中のデータを操作してダイナミックリンキングをバイパスしたりできますか？ 回答： いいえ。これがパスキーとダイナミックリンキングが強力に連携する点です。すべてのWebAuthn認証は、一意の署名を生成し、それはチャレンジ（私たちが取引ごとに生成）に結びついており、当社のドメインにスコープされています。攻撃者はその署名を別の取引にリプレイすることはできません。署名自体がチャレンジのナンスを組み込んでおり、元々発行されたものに対してのみ有効です。攻撃者がネットワーク通信を傍受しても、署名を無効にすることなく金額や受取人を変更することはできません（チャレンジや取引コンテキストが一致しなくなるため）。これは、私たちが議論したMITM保護と実質的に同じです。また、パスキー署名にはオリジンデータが含まれており、当社の正確なウェブサイト/アプリのオリジンに送信されないと検証されません。したがって、フィッシングやリダイレクトは機能しません。要するに、いかなる操作の試みも、ダイナミックリンキングのルールに従って認証コードを無効にします。これは、ユーザーが時々汎用的なコードを承認し、リクエストが改ざんされるリスクがある一部の現行のOTPベースのフローよりも、実際には安全です。パスキーを使えば、ユーザー認証を特定のセッション/取引に暗号学的に結びつけることができます。

質問5： SCAにおけるWebAuthn/パスキーに関する規制当局の意見はありますか？ 規制当局がパスキーを準拠していると認める確信はありますか？ 回答： 現時点では、EBAはWebAuthnや「パスキー」という用語について、Q&Aやガイダンスで明確な意見を発表していません。しかし、彼らが示した原則に基づくと、パスキーは明らかに許容される方法の範囲内に収まります。EBAの2019年の意見書は、本質的にFIDO2のようなアプローチを予期していました。所持については、「公開鍵/秘密鍵の交換」と適切なデバイスへの紐付けを所持の証拠として明確に言及しています。WebAuthnパスキーはまさにそれです。公開鍵/秘密鍵のペアで、秘密鍵はデバイスに安全に紐付けられています。彼らはまた、「デバイスによって生成された署名」を有効な所持の証明として認めています。したがって、彼らはパスキーという言葉を使いませんでしたが、その方法は彼らの例でカバーされています。また、ヨーロッパの主要な決済事業者がパスキーの実装を進めていることも観察しています（例：PayPal）。これは、これがPSD2準拠であるという一定の自信を示しています。この例は、ダイナミックリンキングと全体的な要件が満たされている限り、パスキーが準拠したSCAフローの一部として受け入れられていることを示しています。

質問6： パスキーがフィッシング耐性を持つ場合でも、ダイナミックリンキングは必要ですか？ 回答： はい。パスキーはクロスオリジンのフィッシングを排除しますが、PSD2は依然としてリモート決済の開始にダイナミックリンキングを義務付けています。ダイナミックリンキングは、特定の金額と受取人をSCAの結果に結びつけ、いかなる変更も無効にし、フィッシングを超えた認可の完全性（例：MITM/MITB/TPPによる差し替え）に対応します。

Corbadoのソリューションは、ダイナミックリンキングおよびPSD2に準拠しています。認証前の支払者への表示、金額と受取人に紐付けられたワンタイムチャレンジ、厳格なサーバー検証、そして不変の監査は、支払者認識、一意性/特定性、変更時の無効化、および完全性/機密性に関するRTS第5条の要件を共に満たします。要素の独立性は、デバイスに紐付いた所持とUV（生体認証またはPIN）を通じて維持され、EBAのガイダンスと一致しています。

今日のOTP/SMS方式と比較して、Corbadoはセキュリティとユーザー体験において大幅な改善をもたらします。フィッシングやリプレイへの耐性、パラメータの静かな改ざんの防止、より強力な否認不可能な証拠、そしてデバイス上のUVによる摩擦の低減です。残存リスク（例：ソーシャルエンジニアリング、侵害されたデバイス）は具体的な統制で緩和され、従来の方法よりも狭められています。ウェブ向けには、Corbadoはプラットフォームのサポート（特にApple）が広範になった際にSPCを採用でき、中核となるコンプライアンスの姿勢を変えることなく、表示の暗号学的証明を追加します。

要するに、Corbadoのパスキーベースの取引承認は、PSD2ダイナミックリンキングの条文と精神を満たし、従来の方式と比較して不正行為への耐性と監査可能性を向上させ、エコシステムの成熟に伴う将来の機能強化（SPC）への明確な道筋を維持しています。

実際には、パスキーは3つのことを行うことでダイナミックリンキングを満たします。ユーザー検証の前に支払者に金額と受取人を表示し、これらの正確な詳細に固有の認証コードを生成し、いかなる変更もコードを無効にすることです（RTS第5条(1)(a–d)）。これは、規制当局がすでにローカル生体認証で受け入れている原則を反映しており、パスキーはOSネイティブで、追加アプリなしでウェブとアプリのチャネルを横断して機能するという利便性が加わります。オリジンバインディングと組み合わせることで、スプーフィングされたリクエストは表示されず、元のサイトやアプリからの正当なプロンプトのみがユーザーに表示されます。