1. Introduction

2. What is Dynamic Linking in PSD2?

  2.1 Definition and Importance in PSD2

  2.2 Requirements for Dynamic Linking in Financial Transactions

3. How Can Passkeys Be Used for Dynamic Linking?

  3.1 Option 1: Standard Use of Passkeys in Dynamic Linking

  3.2 Option 2: Enhanced Cryptographic Proof through WebAuthn Challenge

  3.3 Limitations and Challenges of Standard Passkey Options

    3.3.1 Payer Awareness Cannot Be Assured

    3.3.2 Use Case: First-Party vs. Third-Party Payment Context

4. Future Option: Secure Payment Confirmation (SPC)

  4.1 What are the Objectives of the SPC Standard?

  4.2 How Would the SPC Passkey Flows Look Like?

    4.2.1 SPC Passkeys: Register / Authenticate Directly on the Issuer / Bank Website

    4.2.2 SPC Passkeys: Register / Authenticate on a Merchant Website During Payment

    4.2.3 SPC Passkeys: Cross-Origin Authentication

  4.3 What’s the Status of the Secure Payment Confirmation Standard?

5. Future Option 2: The Confirmation Extension

  5.1 What are the Objectives of the Confirmation Extension?

  5.2 How Does the Confirmation Extension Work?

  5.3 Why It Matters for Dynamic Linking

  5.4 Current Status of the Confirmation Extension

  5.5 Comparison: How SPC and the Confirmation Extension Are Different

6. Recommendation for Issuer / Banks

7. Conclusion

In our comprehensive four-part series (part 1, part 2, part 3 & part 4) on PSD2, we explored how passkeys integrate with the strong customer authentication (SCA) measures introduced by PSD2. 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 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.

Dynamic linking is a security requirement under the PSD2 directive and its implementing addendum the Regulatory Technical Standards (RTS). The concept was introduced to enhance the security of electronic payments 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 include bank transfers in online banking software but also credit card payments on merchant sites.

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 transaction" (Article 97(2) of PSD2). This means that any changes in the 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.

Subscribe to our Passkeys Substack for the latest news and insights.

Subscribe

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.

Let’s first analyze different options how passkeys can be used in dynamic linking.

In this approach, the passkey itself acts as a cryptographic 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 requirements for dynamic linking.

Become part of our Passkeys Community for updates and support.

Join

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).

Let’s analyze the limitations a challenges of these two options.

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.

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 / 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 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 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 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 shows an iframe where the authentication with the passkey can happen. The IFRAME is shown by the underlying 3-D 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. As no passkeys are available yet, the user is authenticated by existing authentication factors (e.g. SMS OTP or the native 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 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:

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 support is already incorporated into the ongoing WebAuthn Level 3 specification (which will be made generally available by the end of 2024). However, browsers still have to catch up to specification:

As of today, it seems that by 2024, coverage for cross-origin registration of passkeys could become a reality in major browsers, which would lift the most significant technical limitation in using passkeys for payments.

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 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.

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:

Example from 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 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 must occur in a first-party context, SPC enables the registration of passkeys directly from a cross-origin iframe. This capability addresses common use cases in the payment ecosystem and facilitates easier integration for merchants 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 for a transaction, even if it leverages credentials from another Relying Party (without the need to leave the page). In this case, not even an iframe from the merchant / issuer is needed. This feature is particularly useful in scenarios where multiple parties (merchant + 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.

The example above is taken from the SPC Explainer and shows the concept of Cross-Origin Authentication of payments: In a payment process using SPC, the user remains on the merchant's site (highlighted in blue) throughout the transaction. The web browser (colored in green) maintains the display of the merchant's 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 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 processes while maintaining high security standards across the digital payment landscape.

Let’s go through all possible flows that SPC would allow and compare them to standard passkeys, so that that we understand the benefits.

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 Authentication. Let’s go through them one by one.

Here is a mock-up example of registering an SPC passkey directly on the page of Mastercard. As you can see here, the passkey creation is offered right after the completion of the authentication via SMS OTP in this case.

In this case, the communication would look like a standard passkeys registration process as this happens completely in the first-party context.

Taken from 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).

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 (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 site (e.g. amazon.com) but controlled by the payment service provider or issuing bank (e.g. mastercard.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) or the issuing bank (e.g. mastercard.com). Therefore, the SPC passkey is created with the issuer / bank directly and not the merchant. The simplified flow would look like this:

Taken from https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

On 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:

It also allows to play around with the bank’s site directly which is hosted under: 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.

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 (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.

Originally from (partially adjusted): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Originally from (partially adjusted): 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.

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, Google Chrome is the only major browser that supports the SPC in some form. 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 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.

The challenges outlined above, especially around payer awareness, have prompted ongoing work in the WebAuthn Working Group on a so-called confirmation extension (formerly known as “txAuthSimple”) within the WebAuthN Standard. Its aim is to allow either the 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.

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 (or client platform) signs a record of the exact text displayed. By verifying this signature, the 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.

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:

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 data if the authenticator supports the extension.
3. Returns any authenticator output to the 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. 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.

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.

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. 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.

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:

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.

Our recommendation for issuers, 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: Passkeys are a very good solution for issuers / 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 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 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.

Why are Passkeys important?

Passkeys for Enterprises

Passwords & phishing put enterprises at risk. Passkeys offer the only MFA solution balancing security and UX. Our whitepaper covers implementation and business impact.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Get whitepaper

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 Google Chrome currently being the sole supporter. 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.