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. Recommendation for Issuer / Banks

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

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.

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.

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

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