--- url: 'https://www.corbado.com/blog/dynamic-linking-passkeys-spc' title: 'Dynamic Linking with Passkeys: Secure Payment Confirmation (SPC)' description: 'Discover how dynamic linking, passkeys & Secure Payment Confirmation (SPC) can enhance digital payments. Learn the use of passkeys for dynamic linking.' lang: 'en' author: 'Vincent Delitz' date: '2024-04-20T08:02:13.769Z' lastModified: '2026-03-25T10:00:27.900Z' keywords: 'dynamic linking, secure payment confirmation, spc' category: 'Passkeys Strategy' --- # Dynamic Linking with Passkeys: Secure Payment Confirmation (SPC) ## Key Facts - **Dynamic linking**, required by PSD2's RTS Article 5, mandates authentication codes unique to each transaction's amount and payee: any modification to either detail invalidates the code. - **First-party payment contexts** on issuer/bank websites support passkeys for dynamic linking today; WebAuthn Level 2 blocks passkey registration in cross-origin merchant iframes. - **Secure Payment Confirmation (SPC)**, initiated by Google and Stripe, enables cross-origin payment authentication with browser-native UX, but only Chrome and Edge currently support it. - The **WebAuthn confirmation extension** (PR #2020) provides cryptographic proof that users saw correct transaction details at signing, directly addressing PSD2's payer awareness gap in standard passkey flows. ## 1. Introduction In our comprehensive four-part series (part 1, part 2, part 3 & part 4) on [PSD2](https://www.corbado.com/blog/psd2-passkeys), we explored how passkeys integrate with the **strong customer authentication (SCA)** measures introduced by [PSD2](https://www.corbado.com/blog/psd2-passkeys). We specifically focused on the authentication elements required by SCA for accessing banking applications. SCA requirements are not only applicable to accessing applications but also to initiating and signing electronic [payment](https://www.corbado.com/passkeys-for-payment) transactions remotely. Moreover, these requirements require the use of a mechanism known as **dynamic linking**. In this article, we will explain dynamic linking and examine how passkeys can be effectively utilized to implement this mechanism both today and in the future. ## 2. What is Dynamic Linking in PSD2? **Dynamic linking** is a security requirement under the [PSD2](https://www.corbado.com/blog/psd2-passkeys) directive and its implementing addendum the Regulatory Technical Standards (RTS). The concept was introduced to enhance the security of electronic [payments](https://www.corbado.com/passkeys-for-payment) by ensuring that each transaction is uniquely connected to a specific amount and a specific payee by an authentication code. This linkage prevents any modification of the transaction details once it has been authenticated by the payer, thereby reducing the risk of fraud. Electronic [payments](https://www.corbado.com/passkeys-for-payment) include bank transfers in online [banking](https://www.corbado.com/passkeys-for-banking) software but also credit card [payments](https://www.corbado.com/passkeys-for-payment) on [merchant](https://www.corbado.com/glossary/merchant) sites. ### 2.1 Definition and Importance in PSD2 According to the PSD2 Directive and the accompanying RTS, dynamic linking is defined as a process that ensures that "the authentication code generated is specific to the amount and the payee agreed to by the payer when initiating the electronic [payment](https://www.corbado.com/passkeys-for-payment) transaction" (Article 97(2) of PSD2). This means that any changes in the [payment](https://www.corbado.com/passkeys-for-payment) details would invalidate the authentication code, requiring re-authentication. Dynamic linking is crucial in PSD2, as it directly addresses the security risks associated with remote electronic transactions, which are particularly vulnerable to different types of fraud, such as man-in-the-middle attacks. By securing the transaction in this way, dynamic linking significantly lowers the possibility of unauthorized transactions. ### 2.2 Requirements for Dynamic Linking in Financial Transactions The RTS Article 5 expands on the requirements for the authentication code in dynamic linking. These requirements include: - **Payer awareness**: The payer is made aware of the amount of the payment transaction and of the payee. - **Authentication code is unique:** The authentication code generated for each transaction must be unique and must not be reusable for any other transaction. - **Authentication code is specific**: The codes which are generated and the code which is accepted must be specific to the amount of the transaction and the identity of the payee as confirmed by the payer. Any change to the amount or the payee results in the invalidation of the authentication code. - **Secure transmission**: Confidentiality, authenticity and integrity is maintained for the amount of the transaction and the payee throughout all of the phases of the authentication including the generation, transmission and use of the authentication code. With these technical requirements of dynamic linking laid out, in the next section we will see how passkeys can help as new technology. We'll explore their potential to streamline and secure payment authentication processes, making dynamic linking not only more robust but also more user-friendly. ## 3. How Can Passkeys Be Used for Dynamic Linking? Let’s first analyze different options how passkeys can be used in dynamic linking. ### 3.1 Option 1: Standard Use of Passkeys in Dynamic Linking In this approach, the passkey itself acts as a cryptographic [assertion](https://www.corbado.com/glossary/assertion) that is used directly as the authentication code. The challenge issued during the transaction process is generated to specifically reflect the specific transaction details, such as the amount and the payee, and is stored together with that information. When the user authorizes the transaction using their passkey, a unique, cryptographically secure signature is generated which can be verified and stored together with the transaction. This response not only serves as a robust authentication factor but also directly ties the approval to the specific transaction details, adhering strictly to [PSD2's](https://www.corbado.com/blog/psd2-passkeys) requirements for dynamic linking. ### 3.2 Option 2: Enhanced Cryptographic Proof through WebAuthn Challenge A more advanced integration involves encoding additional transaction details into the WebAuthn challenge itself (which technically is not required by the PSD2/RTS). This method suggests incorporating a cryptographic hash of the payee and the amount, alongside other random data, into the challenge. By doing this, the authentication process not only verifies the user's identity through the passkey but also cryptographically asserts the integrity of the transaction details. This approach offers an additional layer of security by ensuring that any tampering with the amount or the payee details would be detectable at the point of final payment. The cryptographic proof becomes an immutable part of the authentication code, enhancing trust and security in high-risk transaction environments (more info [here](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)). ### 3.3 Limitations and Challenges of Standard Passkey Options Let’s analyze the limitations a challenges of these two options. #### 3.3.1 Payer Awareness Cannot Be Assured One of the limitations of using passkeys in the context of dynamic linking, particularly for payment authentication, is the lack of concrete documentation or assurance that the payer has been accurately informed about the payee information. While passkeys provide a secure method for user authentication, they do not inherently verify whether all transaction details, especially those concerning the payee, have been displayed correctly to the payer. This issue is not unique to passkeys; it is a common challenge across various online payment systems. Ensuring that the payer is fully aware of and consents to all transaction details before initiating the payment is crucial for maintaining trust and security. #### 3.3.2 Use case: First-Party vs. Third-Party Payment Context The most significant limitation of integrating passkeys into dynamic linking arises in the distinction between first-party and third-party registration. **What’s a First-Party Payment Context?** ✔️ In the First-Party payment context, the user is directly interacting with the [issuer](https://www.corbado.com/glossary/issuer) / bank on their internet service and domain. Passkeys can be registered and authenticated seamlessly. An example could be a bank that registers a passkey on their own website and uses it to authorize a payment initiation from their online [banking](https://www.corbado.com/passkeys-for-banking) software. Here, passkeys work seamlessly. The bank can ensure that the passkey is used within its domain, maintaining control over the payment environment and the security of the transaction. Please see our blog post for [Mastercard's](https://www.corbado.com/blog/mastercard-passkeys) passkey implementation on a first-party payment context. **What’s a Third-Party Payment Context?** In the Third-Party payment context the user is on a [merchant](https://www.corbado.com/glossary/merchant) page in the checkout process on a different domain (e.g. amazon.com) and wants to initiate a credit card transaction: - ✔️ **Case 1 – The user already has a passkey from their issuer / bank:** The [merchant](https://www.corbado.com/glossary/merchant) shows an [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) where the authentication with the passkey can happen. The [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) is shown by the underlying [3-D Secure](https://www.corbado.com/glossary/3d-secure) 2 (3DSS/EMV 3DS) process which is already in place for credit card transactions that need to support SCA and dynamic linking. - ❌ **Case 2 – The user does not have a passkey from their issuer / bank:** Again, the merchant shows the [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn). As no passkeys are available yet, the user is authenticated by existing authentication factors (e.g. SMS OTP or the native [banking](https://www.corbado.com/passkeys-for-banking) app on their smartphone). At this point, after a successful authentication, it would be the ideal moment to register a passkey for the user, but **this is not allowed due to WebAuthn standard restrictions**. Registration of passkeys in a [cross-origin iframe](https://www.corbado.com/faq/cross-origin-iframe-passkey-challenges) is not allowed (the domain of the main page and the iframe would need to be identical). A gradual enrollment like in the following screenshot would be impossible: ![dynamic-linking-passkeys-check-out-faster.png](https://www.corbado.com/website-assets/dynamic_linking_passkeys_check_out_faster_edb79b9e22.png) **Will passkey registration in cross-origin iframes be supported in the future?** While passkeys offer a good solution for dynamic linking in first-party payment context within a single domain, in third-party payment contexts, they are currently not supported by WebAuthn Level 2. However, the good news is that [cross-origin iframe](https://www.corbado.com/faq/cross-origin-iframe-passkey-challenges) support is already incorporated into the ongoing [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) specification (which will be made generally available by the end of 2024). However, browsers still have to catch up to specification: | **Browser/Standard** | **First-Party-Context** | **Third-Party-Context** | | --------------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | **Register passkeys** **in cross-origin iframes:** | | | | Required in WebAuthn Level 2 | ✔️ [Details](https://issues.chromium.org/issues/40258856) | ❌ | | Required in WebAuthn Level 3 | ✔️ [Details](https://issues.chromium.org/issues/40258856) | ✔️ [Details](https://issues.chromium.org/issues/40258856) | | Implemented in Chrome | ✔️ [Details](https://issues.chromium.org/issues/40258856) | ✔️ [Details](https://issues.chromium.org/issues/40258856) | | Implemented in Firefox | ✔️ [Details](https://issues.chromium.org/issues/40258856) | [Positive signal](https://github.com/mozilla/standards-positions/issues/964) for implementation | | Implemented in [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Details](https://issues.chromium.org/issues/40258856) | Awaiting signal for implementation | | **Authenticate using passkeys** **in cross-origin iframes:** | | | | Required in WebAuthn Level 2 | ✔️ | ✔️ | | Required in WebAuthn Level 3 | ✔️ | ✔️ | | Implemented in Chrome | ✔️ | ✔️ | | Implemented in Firefox | ✔️ | ✔️ | | Implemented in Safari | ✔️ | ✔️ | As of today, it seems that by 2024, coverage for [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) registration of passkeys could become a reality in major browsers, which would lift the most significant technical limitation in using passkeys for payments. ## 4. Future Option: Secure Payment Confirmation (SPC) There have been several attempts by (e.g. BasicCard, PaymentHandler or PaymentManifest) by Google-initiated working groups at W3C to improve the payment experience on the web. Up until now none has gained significant market coverage and use. Friction in the payment process for [ecommerce](https://www.corbado.com/passkeys-for-e-commerce) transactions remains a big challenge with increasing regulation against fraud. The **Secure Payment Conformation** standard which was initiated by Google & Stripe is currently the most promising standard building upon the WebAuthn standard. ### 4.1 What are the Objectives of the SPC Standard? The Secure Payment Confirmation (SPC) addresses all important elements of PSD2 SCA including the dynamic linking requirement, and at the same time tries to improve UX experience. - **Offer Browser-Native UX**: SPC leverages the browser to provide a consistent and streamlined authentication experience across different merchant sites and relying parties. This approach is intended to enhance transaction security beyond what is typically achieved with content rendered in an iframe by having a consistent appearance and guaranteeing payer awareness: ![Dynamic Linking Passkeys SPC Merchant](https://www.corbado.com/website-assets/dynamic_linking_passkeys_spc_merchant_8009b1ef5a.png)_Example from [https://www.w3.org/press-releases/2023/spc-cr/](https://www.w3.org/press-releases/2023/spc-cr/)_ - **Provide Cryptographic Evidence:** The standard ensures that cryptographic proof of the user's confirmation of payment details is generated and included in the WebAuthn [assertion](https://www.corbado.com/glossary/assertion) without the need to encode the information into the WebAuthn challenge. - **Allow Third-Party Enrollment:** Unlike in the WebAuthn Level 2 standard, where registration of an [authenticator](https://www.corbado.com/glossary/authenticator) must occur in a first-party context, SPC enables the registration of passkeys directly from a [cross-origin iframe](https://www.corbado.com/faq/cross-origin-iframe-passkey-challenges). This capability addresses common use cases in the payment ecosystem and facilitates easier integration for [merchants](https://www.corbado.com/glossary/merchant) and payment processors. As we have discussed above this functionality is already part of the next version of underlying standard and therefore will probably be removed in the future from SPC. - **Cross-Origin Authentication of Payments:** SPC extends the utility of WebAuthn by allowing any origin to generate an [assertion](https://www.corbado.com/glossary/assertion) for a transaction, even if it leverages credentials from another [Relying Party](https://www.corbado.com/glossary/relying-party) (without the need to leave the page). In this case, not even an iframe from the merchant / [issuer](https://www.corbado.com/glossary/issuer) is needed. This feature is particularly useful in scenarios where multiple parties (merchant + [issuer](https://www.corbado.com/glossary/issuer) / bank) are involved in the authentication process and the assertion can then be transported to the original Relaying Party (the account provider e.g. a bank) for verification. ![Cross Origin Authentication Payments](https://www.corbado.com/website-assets/cross_origin_authentication_payments_1fe18ec791.png) The example above is taken from the SPC Explainer and shows the concept of [Cross-Origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) Authentication of payments: In a payment process using SPC, the user remains on the [merchant's](https://www.corbado.com/glossary/merchant) site (highlighted in blue) throughout the transaction. The web browser (colored in green) maintains the display of the [merchant's](https://www.corbado.com/glossary/merchant) origin and also presents a pre-defined non-customizable dialog with all important information for dynamic linking (amount + payee) to confirm the transaction. After the user’s confirmation, the operating system (depicted in orange) handles the [biometric authentication](https://www.corbado.com/blog/passkeys-biometric-authentication) needed to verify the transaction. These objectives illustrate SPC’s commitment to improving both the security and user experience of online payments, aiming to [simplify authentication](https://www.corbado.com/faq/one-tap-passkey-login-simplify-authentication-abandon-passwords) processes while maintaining high security standards across the digital payment landscape. ### 4.2 How Would the SPC Passkey Flows Look Like? Let’s go through all possible flows that SPC would allow and compare them to standard passkeys, so that that we understand the benefits. | **Use Case** | **SPC Passkeys** | **Passkeys** | | --------------------------------------- | ---------------- | ------------ | | **Issuer website auth/register** | ✔️ | ✔️ | | **Merchant website register in iframe** | ✔️ | ❌/✔️ | | **Merchant website auth in iframe** | ✔️ | ✔️ | | **Merchant website auth cross-origin** | ✔️ | ❌ | As we can see here, the most important distinction is the registration on the merchant website within an iframe which is not yet supported by passkeys (see our discussion above) and the completely new possibility of [Cross-Origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) Authentication. Let’s go through them one by one. #### 4.2.1 SPC Passkeys: Register / Authenticate Directly on the Issuer / Bank Website Here is a mock-up example of registering an SPC passkey directly on the page of [Mastercard](https://www.corbado.com/blog/mastercard-passkeys). As you can see here, the [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) is offered right after the completion of the authentication via SMS OTP in this case. ![SPC Passkeys Issuer Bank](https://www.corbado.com/website-assets/spc_passkeys_issuer_bank_3d68dd2043.png) In this case, the communication would look like a standard passkeys registration process as this happens completely in the first-party context. ![SPC Passkeys Flow](https://www.corbado.com/website-assets/spc_passkeys_flow_1324c4d2d7.png)_Taken from [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_ This SPC passkey could now be used on a merchant site for authentication, in an iframe on the merchant site and for Cross-Origin Authentication (see below). #### 4.2.2 SPC Passkeys: Register / Authenticate on a Merchant Website During Payment As we have discussed before, the process of registering a SPC passkey on a merchant website would typically occur during the payment transaction, within the context of the [3-D Secure](https://www.corbado.com/glossary/3d-secure) (3DS) flow. This flow is designed to enhance the security of online credit and debit card transactions by involving an additional authentication step that verifies the cardholder's identity. During a payment transaction, when the 3DS flow is initiated, the authentication process is facilitated through an iframe hosted on the [merchant's](https://www.corbado.com/glossary/merchant) site (e.g. amazon.com) but controlled by the [payment service provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) or issuing bank (e.g. [mastercard](https://www.corbado.com/blog/mastercard-passkeys).com). This iframe serves as a secure environment for the customer to authenticate their identity using existing authentication factors. Once the customer successfully authenticates themselves using these conventional factors (e.g. SMS OTP or banking app), there is the opportunity to register a SPC passkey for future transactions. **As the SPC Standard allows cross-origin passkey creation from within iframes, this would work.** The registration of this passkey in the iframe would typically involve the customer performing an action that generates and binds the passkey to their credit card, such as verifying their fingerprint or facial recognition on a compatible device. Keep in mind that the iframe is controlled by the payment service provider (e.g. [PayPal](https://www.corbado.com/blog/paypal-passkeys)) or the issuing bank (e.g. [mastercard](https://www.corbado.com/blog/mastercard-passkeys).com). Therefore, the SPC passkey is created with the issuer / bank directly and not the merchant. The simplified flow would look like this: ![SPC Passkeys Merchant Flow](https://www.corbado.com/website-assets/spc_passkeys_merchant_flow_267ffda65a.png)_Taken from [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_ On [https://spc-merchant.glitch.me/](https://spc-merchant.glitch.me/), Google has set up a demo application that can be accessed via Chrome on Windows and Mac, which illustrates how this would work from within an iframe: ![SPC Passkey Demo App](https://www.corbado.com/website-assets/spc_passkey_demo_app_4458eb6295.png) It also allows to play around with the bank’s site directly which is hosted under: [https://spc-rp.glitch.me/reauth](https://spc-rp.glitch.me/reauth). In this example, no out-of-band communication with APIs between the merchant and the issuer / bank is needed – everything is handled by the browser. Authenticating using an existing passkey would work the same way from within the iframe. #### 4.2.3 SPC Passkeys: Cross-Origin Authentication In the following example, we see the Cross-Origin Authentication where the user has already registered a SPC Passkey with Mastercard. The example merchant site (decorshop.com) can trigger the Cross-Origin Authentication. **The major and important difference is that the merchant / issuer page is never visible during the authentication process**. The browser in combination with the operating present the predefined [payment UX](https://www.corbado.com/faq/redirect-based-passkeys-preference) (provided by the browser implementation of the SPC standard) and the authentication modal (WebAuthn standard). The communication between merchant and issuer / bank is handled in the background. ![SPC Passkeys Cross-Origin Authentication](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_3cc4d40619.png)_Originally from (partially adjusted): [https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf](https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf) (Mastercard)_ ![SPC Passkeys Cross-Origin Authentication Flow](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_flow_d6d05cdf6b.png)_Originally from (partially adjusted): [https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams](https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams)_ When using Cross-Origin Authentication, the merchant communicates with the issuer / bank via some form of API to exchange information about existing credentials (#2 in the sequence chart above). If credentials exist and the browser of the user supports SPC, the authentication starts. At the end, the assertion is returned all the way back to the issuer / bank via existing protocols like EMV 3DS, where the assertion can be finally cryptographically verified at the end (#16). As the assertion also includes information about the information displayed by the browser, all requirements for dynamic linking are fulfilled. This would be a major step in terms of UX and customer payment experience improvements. ### 4.3 What’s the Status of the Secure Payment Confirmation Standard? The Secure Payment Confirmation (SPC) standard is an interesting development in the world of online payment authentication, aimed at enhancing security while streamlining user experience. As of today, [Chromium-based browsers (Chrome and Edge)](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation) support SPC. However, this is not surprising as the standard has partially been initiated by Google. From other major browsers like Apple's Safari and Mozilla Firefox, there is a notable lack of commitment with no clear signals about their plans to support SPC. Specifically Apple pushes its own proprietary Standard **Apple Pay** and seems not to be interested in other payment standards. The connection of SPC with WebAuthn has made the development process more difficult. This is because any enhancements or modifications in the SPC standard need to be carefully evaluated to prevent redundancy and ensure they provide genuine improvements over existing capabilities. The goal is to refine the SPC to serve specific needs within the payment process that are not fully covered by WebAuthn, such as direct integration into the checkout flow and providing a more [user-friendly authentication](https://www.corbado.com/faq/passkey-user-experience-benefits-non-technical-audience) experience that can operate seamlessly across different merchant sites. As the SPC continues to evolve, its adoption across different browsers will be crucial for widespread implementation. The involvement of major players like Google indicates a positive direction, but broader support will be necessary to establish SPC as a standard across the online payment industry. ## 5. Future Option 2: The Confirmation Extension The challenges outlined above, especially around **payer awareness**, have prompted ongoing work in the [WebAuthn Working Group](https://github.com/w3c/webauthn/pull/2020) on a so-called **confirmation extension** (formerly known as “txAuthSimple”) within the WebAuthN Standard. Its aim is to allow either the [authenticator](https://www.corbado.com/glossary/authenticator) or the browser/OS (in a privileged UI) to display the transaction details to the user and ensure that the relying party receives cryptographic proof that the user actually confirmed these details. This directly addresses the “lack of guaranteed user awareness” problem described in [section 3.3.1](#331-payer-awareness-cannot-be-assured). ### 5.1 What are the Objectives of the Confirmation Extension? Similar to how Secure Payment Confirmation (SPC) provides a dedicated, browser-driven dialog, the confirmation extension tackles the “What You See Is What You Sign” (WYSIWYS) concern. Its main objectives are: - **Trusted Display of Transaction Details**: Rather than leaving it up to the web content to show the amount and payee, the extension leverages either a device’s secure screen or a browser UI dialog under the OS’s control. - **Cryptographic Evidence**: The [authenticator](https://www.corbado.com/glossary/authenticator) (or client platform) signs a record of the exact text displayed. By verifying this signature, the [relying party](https://www.corbado.com/glossary/relying-party) can confirm that the user was shown the correct details. - **Fallback if Authenticator Doesn’t Support Display**: In cases where a hardware authenticator cannot show text, the browser may display it and include it in the \[=client data=]. This is a weaker guarantee but allows wider compatibility. ### 5.2 How Does the Confirmation Extension Work? The extension adds a new field to the existing WebAuthn extension structures. Relying Parties supply a simple text string (with optional basic formatting) called `confirmation`: ```webidl partial dictionary AuthenticationExtensionsClientInputs { USVString confirmation; }; ``` When the client (browser) receives this, it: 1. **Prompts** the user with a special confirmation dialog (so they know this is more than a basic login). 2. **Passes** the same string to the authenticator as [CBOR](https://www.corbado.com/glossary/cbor) data if the authenticator supports the extension. 3. **Returns** any authenticator output to the [Relying Party](https://www.corbado.com/glossary/relying-party). If the authenticator supports displaying text, it **must** show that text (e.g., on its own screen or trusted UI) before completing [user verification](https://www.corbado.com/blog/webauthn-user-verification). It then includes the same string in its signed output. On the Relying Party side, the verification steps ensure that the returned `confirmation` text **matches** what was sent. If the authenticator extension output is missing but the Relying Party policy allows a fallback, the Relying Party can rely on the `confirmation` value from the client data—indicating the browser displayed the text instead of the authenticator. ### 5.3 Why It Matters for Dynamic Linking By embedding the **payee** and **amount** into this extension, the user sees precisely what they are authorizing on a trusted display. The user’s signature now reflects not just a hashed challenge but also the **exact transaction text**. This is particularly valuable for PSD2’s dynamic-linking requirement, since: - Any mismatch or modification of the transaction details after display invalidates the signature. - The Relying Party can prove that the user was given the correct transaction details at the time of signing, fulfilling PSD2’s “payer awareness” requirement far more robustly than just hashing data in the challenge. ### 5.4 Current Status of the Confirmation Extension While the **confirmation extension** is still under discussion, it represents a crucial step toward more secure and user-friendly transaction flows. By building it directly into the WebAuthn specification, it offers: - **Interoperability**: Any authenticator or client implementing the extension would follow the same standardized format. - **Flexibility**: Relying Parties can enforce stronger policies (requiring authenticator-level display) or accept browser-level fallback if needed. - **Broader Ecosystem Alignment**: It aligns well with regulatory mandates like PSD2, especially around robust dynamic linking. For more technical details, you can take a look into the ongoing discussion: [GitHub pull request #2020](https://github.com/w3c/webauthn/pull/2020). In summary the confirmation extension could also close the last major gap in standard passkey-based flows: providing **cryptographic proof** of exactly **what** the user saw when they gave their consent albeit less structured than with the Secure Payment Confirmation . Should it gain traction among browsers and authenticator vendors, it could become a highly standardized method for delivering the WYSIWYS security guarantee necessary under PSD2 dynamic linking—and beyond. ### 5.5 Comparison: How SPC and the Confirmation Extension Are Different Although **SPC** and the **confirmation extension** share a common goal to strengthen dynamic linking in WebAuthn they differ in scope and approach. The table below highlights some of these differences: | **Comparison Criteria** | **SPC** | **Confirmation Extension** | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------ | | **Integrated Payment Flow**
_(Handles full checkout, amounts, payee, UI, etc.)_ | ✔️ Includes a standardized browser dialog for payments | ❌ Focuses only on displaying and signing a text string | | **Trusted Transaction Display**
_(Ensures user sees correct payee/amount)_ | ✔️ Browser-based flow ensures consistent UX | ✔️ Either authenticator display or browser | | **Fallback Handling**
_(If authenticator has limited or no display capability)_ | ❌ Not specifically designed for fallback paths | ✔️ Relying Party can accept client-level display if needed | | **Scope Beyond Dynamic Linking**
_(Broader goals, e.g. single-click flows, cross-origin auth)_ | ✔️ Designed to streamline entire checkout process | ❌ Strictly an extension to standard WebAuthn challenge/response | | **Current Maturity & Adoption**
_(Cross-browser readiness)_ | Low adoption beyond Chrome; uncertain timeline | Under discussion in [WebAuthn WG](https://github.com/w3c/webauthn/pull/2020) but promising | In essence, SPC attempts to offer a comprehensive payment solution\* and also incorporates dynamic linking\* as part of its flow. The confirmation extension\*, meanwhile, addresses the _“what you see is what you sign”_ requirement _within_ standard WebAuthn messages without imposing a full payment flow. Either approach could facilitate PSD2 compliance, but each depends on **browser** and **authenticator** support to deliver real-world benefits. ## 6. Recommendation for Issuer / Banks Our recommendation for [issuers](https://www.corbado.com/glossary/issuer), banks and financial institutions therefore is to carefully evaluate which use cases need to be covered and monitor the development of the eco-system as the easiness of passkeys will put substantial pressure on existing SCA & dynamic linking solutions to improve their UX. Customers will demand biometric solutions in the web. At the moment, our operational recommendations is: - ✔️ **[Passkeys for Payments initiated on Issuer / Bank Website](https://issues.chromium.org/issues/40258856):** Passkeys are a very good solution for [issuers](https://www.corbado.com/glossary/issuer) / banks to implement dynamic linking into their websites & apps directly. They could be combined with other authentication options like push notifications, email / SMS OTP or TOTP to further enhance security for high-risk payments. Of course, considerations regarding SCA compliance should always be a part of this discussion (see also our 4-part series on passkeys & SCA). A proposed solution can be implemented by issuer / banks themselves as passkeys are based on the open WebAuthn standard. However, this requires substantial know-how, dealing of edge cases and continuously keeping up with all new regulations and technical developments. The alternative is to use third-party authentication provider. For example, Corbado Connect supports dynamic linking via transaction signing, leveraging adjusted WebAuthn challenges. All information is logged in the audit log. This is not only useful for financial institutions but can be leveraged for all sorts of signatures (e.g. document signing, high-risk user actions). Optionally, an additional SMS or E-Mail OTP can be used to improve security even more. - ❌ **Passkeys for Payments on Merchant Pages:** Rolling out passkeys for payments on merchant pages is not possible yet. Cross-origin use cases are still in development but might be a viable option at the end of 2024. Using passkeys for authentication on merchant pages though is a great idea already today and can also be used to start collecting passkeys which can then also be used for payments in the future. - ❌ **SPC Passkeys or Confirmation Extension for Dynamic Linking**: The SPC Standard has not yet reached a mature state & support to be used in production environments. Overall we are happy to see that [merchants](https://www.corbado.com/glossary/merchant) and banks have started to engage with the standard and adding there requirements and support to the ecosystem. Looking ahead, financial institutions and [e-commerce](https://www.corbado.com/passkeys-for-e-commerce) platforms should monitor these technological advancements closely and consider how they might integrate passkeys into their systems. As regulations continue to evolve, it's crucial to stay ahead of the curve, ensuring that payment authentication processes align with the latest security standards and provide a secure, efficient user experience for consumers which improves conversion & reduces friction. ## 7. Conclusion As we review passkeys for dynamic linking, it is evident that while passkeys can help to adhere to SCA & dynamic linking, the technical integration in third-party services with the WebAuthn standard, originally designed for first-party contexts, presents some challenges. These standards are gradually evolving to better support third-party scenarios, demonstrating a shift towards greater flexibility in their application. Secure Payment Confirmation (SPC) seeks to further this adaptation, aiming to enhance payment authentication processes by incorporating more user-friendly and seamless interactions across various merchant sites. However, the advancement and broader acceptance of the SPC standard or Confirmation Extension heavily rely on its adoption by major browsers—a process that has been slow, with Chromium-based browsers (Chrome and Edge) currently being the main supporters. This slow adoption rate could potentially hinder especially SPC from moving beyond its current state unless more browsers begin to integrate it. The ongoing development and increasing traction of passkeys suggest a promising direction where systems relying on hardware security modules (HSMs) such as secure enclaves, TEEs, and TPMs will also play an important role for payment applications as these technologies offer enhanced security that could make the dynamic linking of payments more practical & comfortable not only for transactions initiated on banking sites but also on third-party merchant platforms. The potential for passkeys to extend their utility to online payment processes highlights an important aspect in securing web-based transactions and making the Internet in general a safer place. ## Frequently Asked Questions ### How do passkeys satisfy the dynamic linking requirement under PSD2? In a standard passkey flow, the WebAuthn challenge is generated to reflect specific transaction details such as the amount and payee, and the resulting cryptographic signature ties the approval to those exact details. Because any change to the amount or payee invalidates the authentication code, this approach aligns with PSD2 RTS Article 5 requirements. An enhanced option also encodes a cryptographic hash of the payee and amount directly into the WebAuthn challenge for an additional layer of tamper detection. ### Why can't my bank register a passkey for me during checkout on a merchant website right now? WebAuthn Level 2 prohibits passkey registration in cross-origin iframes, so a bank-controlled iframe embedded in a merchant site such as amazon.com cannot enroll a new passkey during checkout. WebAuthn Level 3 adds cross-origin iframe registration support, and Chrome already implements it, while Firefox has signaled positive intent and Safari is still awaiting a decision. Until broader browser coverage arrives, passkey registration for third-party merchant contexts remains limited. ### What is the difference between Secure Payment Confirmation (SPC) and using standard passkeys for payment authentication? Standard passkeys work well for payments initiated directly on an issuer or bank website but cannot support cross-origin authentication where a merchant triggers the flow without an iframe. SPC, initiated by Google and Stripe, adds a browser-native payment dialog that guarantees payer awareness, allows cross-origin authentication using credentials registered with a bank and provides cryptographic evidence of payment confirmation without encoding data into the challenge. However, SPC is currently only supported by Chromium-based browsers (Chrome and Edge) and is not yet considered mature for production environments. ### Should my bank or financial institution deploy passkeys for dynamic linking today, or wait for SPC? Banks and issuers can and should deploy passkeys for dynamic linking on their own websites and apps now, optionally combining them with SMS OTP, email OTP or push notifications for high-risk transactions. Rolling out passkeys specifically for merchant checkout pages is not yet practical, as cross-origin use cases are still maturing. Both SPC and the confirmation extension are not yet ready for production, so the recommendation is to monitor their ecosystem development while proceeding with first-party implementations. ### How does the WebAuthn confirmation extension improve on SPC for PSD2 dynamic linking compliance? The confirmation extension, under discussion in the WebAuthn Working Group (GitHub PR \#2020), allows relying parties to supply transaction text that is displayed on a trusted screen, either on the authenticator itself or in a browser UI, before the user signs. The authenticator then includes that exact text in its signed output, giving the relying party cryptographic proof of what the user saw, directly satisfying PSD2's payer awareness requirement. Unlike SPC, it does not impose a full payment checkout flow, making it a lighter-weight option for any WebAuthn-based signing scenario.