Here we describe payments use cases to inform discussions about Web Authentication capabilities.

A theme common to these use cases is the desire to reduce to a minimum the number of explicit authorization events that interrupt the user's task.

Note: In what follows, "merchant" can mean the merchant itself, the merchant's payment service provider (e.g., from an iframe), or even a payment handler. We recognize that for use cases where the payment service provider code is included via an iframe, that the WebAuthn WG is already discussing enabling WebAuthn from an embedded iframe.

• On the merchant site, the cardholder chooses to pay with a card.
• In order to reduce fraud or for other reasons, the merchant chooses to leverage protocols (from EMVCo) intended to authenticate the cardholder. These protocols in turn can take advantage of Web Authentication / FIDO2.

In this protocol, ultimately the issuing bank decides whether it is satisfied with the authentication. However, the issuing bank may delegate some aspects of authentication to the merchant. Below we describe different authentication flows that may take place, and how they may vary according to which party to the transaction is the relying party.

Note:

• At this time we do not discuss maintaining information about prior authentication in pursuit of reducing user gestures during subsequent transactions.

In each flow below:

• The user enrolls an authenticator with the issuing bank. Authenticator enrollment would typically happen outside of a transaction.
• In these flows, the issuing bank operates a FIDO server and the merchant does not.

• At enrollment time, issuer performs its own authentication and creates FIDO credentials.
• At transaction time:
  • The merchant invokes 3DS.
  • If the challenge flow takes place, the issuing bank, via code embedded in the merchant site, redirects the user to an application of the issuing bank.
  • The user authenticates to the issuing bank application (with FIDO credentials).
  • The 3DS protocol completes.

Notes:

• At the current time, this is the most common flow.

• At enrollment time, issuer performs its own authentication and creates FIDO credentials.
• At transaction time:
  • The merchant invokes 3DS.
  • If the challenge flow takes place, the ACS, via code embedded in the merchant site, requests that the merchant authenticate the user. The ACS provides the parameters necessary for the merchant to perform Web Authentication.
  • The merchant calls Web Authentication (using the issuing bank's parameters) and forwards the authentication assertion data to the issuer, which validates them.
  • The 3DS protocol completes.

Notes:

• This approach may also reduce friction for guest checkout because the user only enrolls the FIDO authenticator one time with the issuing bank, rather than with each site the user visits.

• At enrollment time, issuer performs its own authentication and creates FIDO credentials.
• At transaction time:
  • The merchant fetches Web Authentication parameters via a backend call to the issuer (the results of which can be cached)
  • The merchant invokes the Web Authentication API and receives some sort of cryptogram in response; no network requests to the issuer origin are required.
  • The merchant forwards the cryptogram to the issuer for validation via a second backend call. (We might also consider having a mechanism for merchants to check the cryptogram on their own in case the issuer is down, but it seems like this might involve a privacy trade-off for the user).
  • The issuing bank validates the cryptogram.

Notes:

• Some merchants may not wish to embed resources from (a large number) of issuing banks. Instead of embedding (ACS) code, therefore, this flow involves passing data to an issuing bank endpoint. However, making network requests to the issuer can be problematic in cases where the issuer has downtime or experiences network disruptions. Not all issuers are able to run highly-available internet-facing services, and the way that banks present a large target for DDOS attacks is always a concern. Further, because the payments use case involves coordinating between two parties (the merchant origin and the issuer origin), it's very difficult to pinpoint these sorts of problems when they're reported by customers. In contrast, the card networks are built around a store-and-forward model where messages can be queued if a component is unavailable. In an ideal world, Web Authentication would integrate with the card networks in a way that preserves this property,
• This approach may also reduce friction for guest checkout because the user only enrolls the FIDO authenticator one time with the issuing bank, rather than with each site the user visits.
• How the backend calls take place is a payment system implementation detail. For example, they might take place via 3DS, or SRC, or some other protocol.

• At enrollment time, issuer performs its own authentication and creates FIDO credentials. These credentials are created so that another party (e.g., the merchant's PSP or a payment handler) can use them, and they are scoped to that origin. The issuer keeps track of the public key and also returns the key (and credential id) to the PSP / payment handler.
• At transaction time:
  • The merchant invokes 3DS.
  • The merchant calls Web Authentication (using the credential from the issuer) and forwards the authentication assertion data to the issuer.
  • The issuer verifies the authentication assertion data.
  • The 3DS protocol completes.

Notes:

• See presentation from Dirk Balfanz and WebAuthn issue 1372

In these flows, the merchant bank operates a FIDO server and the issuing bank does not have to. Merchants may prefer this approach in order to exercise more control over the authentication user experience. For more information on this type of use case, see, for example the FIDO white paper "FIDO & PSD2 – Providing for a Satisfactory Customer Journey."

In each flow below:

• The user enrolls an authenticator with the merchant.
• The merchant typically communicates with the issuing bank to validate the identity of the cardholder. For example, this validation might take place via the challenge flow of the 3-D Secure protocol.

In these flows, the amount of information may vary in part based on the trust relationship between the merchant and the issuing bank. For example:

• Minimal sharing: merchant only shares a "success signal" with issuer.
• Moderate sharing: merchant shares a subset of FIDO credentials with issuer for risk assessment or partial revalidation. See the FIDO paper "Technical Note: FIDO Authentication and EMV 3-D Secure – Using FIDO for Payment Authentication"
• Maximal sharing: merchant shares authentication assertion data with issuer for full validation. See also WebAuthn issue 1372

Many thanks to comments from Jonathan Grossar and Benjamin Tidor for questions in this section.

• Reducing user friction (a key to conversion rates). An ideal experience is two steps: click the "buy" button, then authenticate (e.g., touch authenticator or facial recognition).
  • Question: Could we go even further, where two gestures be combined into one: where clicking the "buy" button constitutes the presence check required by Web Authentication?
  • Or the inverse: where authenticating constitutes pushing the "buy" button?
• Question: Can one gesture be used to mint multiple authenticator assertions for different origins? For example, when interacting with 4 SRC systems, could a single tap create authenticator assertions for each of the SRC systems to avoid the user tapping 4 times? For example:
  • The user enrolls an authenticator with each SRC system, e.g., when first enrolling a card associated with that SRC identity.
  • At transaction time, the merchant (or payment handler) fetches public keys associated with that SRC identifier from each SRC system, and bundles them into a single Web Authentication call.
  • The Authenticator generates N authenticator assertion responses, one per SRC system.
  • The merchant (or payment handler) returns the responses to the corresponding SRC systems.

At the TPAC 2019 face-to-face we discussed some scenarios that might benefit from the payment handler (or other payments context) being able to provide some input to the WebAuthn client:

• Dynamic linking (per PSD2). John Bradley commented that "We could have info from the payment handler signed as part of the client data; ... I think we could meet SCA requirements across all browsers with existing authenticators...signing the payment handler output in client data."
• Having more information from the payment handler might simplify UX in a way that makes it possible to use a single gesture for multiple activities.

• Reduce need for merchant to embed resources from third-party (e.g., issuing bank) origins in their pages.
  • Question: Can the browser implement some of the functionality performed by embedded ACS code?
• Reduce need for real-time network requests to the issuing bank (due to security and maintenance costs of banks providing network-facing services).
  • Question: Instead, consider a store-and-forward model where messages can be queued if a component is unavailable.

• How does the merchant or issuing bank know whether the cardholder has an authenticator?
• How does the merchant or issuing bank know whether the cardholder has an authenticator already registered with the relying party?
• What happens if user enrolls authenticator when using one device, but then wants to authenticate on a different device? Does the user see an error message? Are they prompted to enroll a new authenticator?

• Generation of credentials on behalf of another party, WebAuthn issue 1372
• Transaction confirmation; see proposal from Adrian Hope-Bailie

An issuing bank supports Web Authentication for their online banking portal; we can imagine that customers use it to log in, to confirm large transfers, and for other sensitive account actions.

If this bank wants to adopt Web Authentication for the payments use case, they would reasonably want to take the precaution of separating thecredentials used for payments from the credentials used for online banking. The bank wants, in effect, to require two identities:

• one used for online banking, which can never be accessed from a third-party context and can only be used to mint online banking sessions, and
• one that can only meaningfully be accessed from a third-party context (i.e. the bank won't let it be used to mint online banking sessions) and is instead used to mint some kind of payment cryptograms (a signature over a transaction ID and amount and merchant origin, more or less).

Based on 22 Jan 2020 discussion, one approach is for the issuing bank to set up one domain for banking and one for payments. Web Authentication allows relying parties to generate sub-domains dynamically. This will lead to enrollment and usage of distinct relying party IDs (RPIDs), and the bank will be able to ensure that keys are being used for the proper purpose.