Secure Payment Confirmation

Full Title

W3C standard stating "Secure Payment Confirmation (SPC), available through the Payment Request API, provides a mechanism for strong customer authentication and consent of payment during checkout, helping to protect against online payment fraud."

Context

• A digital Wallet is an application that allows you to store and organize loyalty cards, identification documents, bank details, concert tickets, airline tickets, crypto coins and payment cards on a mobile phone, a computer, a smart watch or on a tablet. This data can then be used in an Electronic Payment transmitted to other devices using wireless technologies (QR, NFC or Bluetooth) to make payments or perform specific validations. This frees the user from the use of physical cards and the mistakes that inevitable happen when long strings of numbers are keyed in by the holder.
• Secure Payment Confirmation (SPC) is a Web API to support streamlined authentication during a payment transaction. It is designed to scale authentication across merchants, to be used within a wide range of authentication protocols, and to produce cryptographic evidence that the user has confirmed transaction details.
• Using Secure Payment Confirmation is a Mozilla page to protect against online payment fraud, where it is common to authenticate the account holder. Strong authentication lowers the risk of fraud, but increases the likelihood that friction during checkout will lead to shopping cart abandonment. Banks, merchants, payment services providers, and other entities in a payments ecosystem therefore consider a number of factors when deciding what type and strength of authentication to use for each transaction, including the amount, the items being purchased, the user's payment history, which party bears liability in the case of fraud, and regulatory requirements (such as European Payment Services Directive 2 requirements for strong customer authentication and evidence of user consent).

Problems

• In 2022 versions of Chrome/Edge there is a Secure Payment Confirmation API which requires you to handover your card number in CLEAR to merchants. In addition to violating GDPR, it is based on a misguided concept: Merchants do not need card numbers, they need a payment confirmation which they only can get from the specific payment network. The following is an image of the Chrome browser (version M118) transaction dialog for SPC

Solutions

• SPC Design Choices for Flexibility and Scale 2021-10-06 Ian Jacobs
• SPC is designed to enable streamlined strong customer authentication (SCA) in a variety of payment systems, and to provide cryptographic evidence that the user has consented to the terms of a transaction. When the API is called, the browser displays elements of the transaction in a dialog box: the name of the merchant, payment instrument, and amount and currency of payment. Note the identity of the merchant is not user friendly and easy to spoof.

Because the browser passes the displayed data directly to the authenticator (with no JavaScript code able to alter the data), the Relying Party can have high confidence that the user consented to the displayed transaction data.

Apple/Google/Samsung Pay

Payment security is based on Tokenization of the payment card number. This technology never shares the actual data of the linked payment card is with the merchant when making payments. Nor is it stored in the user's device. This minimizes the risk of fraud and exposure of this information. This security feature is based on "tokenization" of the card data. In the card payments industry, a token is a non-confidential value used to replace the Primary Account Number (PAN) data. A payment token differs from Identifier tokens in that its format follows the parameters described in the EMVco technical specification. The management of these type of tokens is under the responsibility of entities registered with EMVco as Token Service Provider (TSP). The TSPs handle:

• Generation and issuance of payment tokens.
• Operation and administration of the Token Vault (database in which the original PAN and its corresponding token are stored, together with other transactional data).
• Assignment of tokens.
• Token life cycle management.
• Management of the token-PAN relationship and de-tokenization processes.
• Operation and administration of the underlying cryptographic platform for the execution of tokenization functions.

Maintenance of the security of the token management environment. The security controls to be implemented are described in the PCI TSP Security Requirements standard. These TSPs, in turn, offer their tokenization services to entities called Token Requestors (TR), who must be registered with the TSP to initiate token requests. In the case of Apple Pay, Google Pay and Samsung Pay, the companies behind these applications act as Token Requestors.

Device Binding

Proposal 2024-05-20: WebAuthn-agnostic device binding for Secure Payment Confirmation

Stephen McGruer (Google): I plan to walk through what I posted shortly before this meeting. This is a high-level proposal for adding device-binding to SPC without relying on WebAuthn SPK/DPK

• we have heard many requests for device binding from the payments industry to meet regulatory requirements.
• passkey synching does not on its own appear to satisfy requirements. There is a DPK/SPK extension but we don't have a sense of a timeline for support in platform authenticators.
• so the proposal here is to do the device binding directly in SPC.

stephen: The generated SPC key would be signed by the WebAuthn key to avoid a Man-in-the-middle (MITM) attack. expectation is that first time this device key appears, it would not be trusted. So there might be a step-up when it is first seen.

• however, on the same device for future authentications you would get back the same key.
• an alternative would be to register something at webAuthn registration time (using payment extension) but it would not work for extant credentials or when a 1p uses a vanilla webauthn credential.
• note that the key would be (1) browser specific on a given device, (2) available cross-origin
• We think per-browser is a feature rather than a limitation.

stephen: Where would keys be stored? There are software and hardware options; I think hardware is the right move here (to reduce risk of key exfiltration).

• but there may not be a TPM available on all platforms. We would have to think about a other situations like roaming authenticators or hybrid.

stephen: Regarding privacy sharing key cross-origin, there are two consent dialogs. … we will do a privacy review but the sense is that this is not adding issues beyond what has already been considered.

stephen: Some other topics are discussed in the FAQ (e.g., whether to offer a single-factor version of SPC where there is no biometric authentication and only the SPC key is used).

• that's an interesting situation but I'm not proposing it here; one reason has to do with the use of the WebAuthn key to avoid MITM attack.
• secondly and possibly more importantly, it simplifies the privacy store a lot if we keep close to WebAuthn's privacy bar.
• there's another topic: what if SPK/DPK does get wide interoperable adoption? If so, we have a few options including deprecation of the SPC feature.
• Ian also had an idea for defining the SPC key in such a way that it could be implemented in different ways (e.g., by browser or WebAuthn SPK).
• With respect to Device Bound Session Credentials, there are enough differences between the APIs that they are not really competing; and also their launch timeline would be much later.

Stephen: Are we reinventing the wheel with this proposal? Yes, to a certain extent. WebAuthn already addresses a bunch of topics. Our approach here should be to stick close to WebAuthn's experience. We should use the same primitives that they do (e.g,. their signing algorithms and crypto)

Stephen: Regarding device attestation, we've heard requests from the industry (in WebAuthn space) for this. On the Web there are privacy implications revealing device information, and ecosystem issues (barriers to entry for new players due to whitelisting).

• so at this time I am not proposing doing attestation with this proposal and hope that device binding alone will suffice.
• please note that at time of writing, there are only two implementations, so attestation is of limited value at this point.

Fahad: When would key be created? And who is the relying party?

stephen: It's created at authentication time using SPC payment method. It's bound to the actual party of the WebAuthn credential.

• this means that it can be created by a party other than the RP, but only when the RP has said it's ok for 3p to use their credentials.
• also, this key should not be used on its own, but only (in this proposal) in conjunction with the WebAuthn key.
• the trust in the user is from the WebAuthn credential.
• the trust in the device is from this newly minted identifier.

Fahad Saleem (Mastercard),: In the 3DS context, the issuer would have to register the key the first time they see it.

Stephen: Yes.

<Zakim> nicktr, you wanted to ask about browser profiles

nicktr: My question is specific to Chrome. You can have multiple profiles in a Chrome instance. Are these identifiers bound to the profile?

Stephen: I suspect the answer would be one key per profile. … Rick points out that these would be clearable keys as well … site storage is tied to profile … not sure yet where we will handle private browsing mode, but might issue a dummy key

Gerhard: I like the proposal. … I was in a call last week with a financial institution and they were worried about the attestation. … just to say that that may still be an issue. … what domain would the key be bound to?

Stephen: The identifier would be tied to tuple of the relying party and (possibly) the credential id

Gerhard Oosthuizen (Entersekt): So if I have two FIDO keys for an origin, I would get two device keys?

Stephen: Yes, at least to start.

Gerhard: That seems fine as a starting point.

Gerhard: Second topic (Gerhard shows a diagram) could we do the same device attestation and send it directly to the issuer? … that would take away a lot of the issue related to merchant MITM attack

Stephen: Yes, that is what FedCM is doing. Usually handled via a .well_known URL. But SPC doesn't do that because the initial proposal involved explicitly the RP not being actively involved in the flow. … if the ecosystem has changed, that may open new options.

Nakjo Shishkov (Netcetera): I like the proposal. I'd also like to get a device key at the time of registration. … the issuer, while creating the passkey, could use the key and remember it for this device. … that would reduce step-ups not he same device … I like this proposal as, in some sense, a special cookie that can be exchanged via the merchant without having a direct issuer connection at authentication time.

<Zakim> Ian, you wanted to ask about relationship to cookies (3p access, persistence) and to ask whether 3DS would need to be modified for this and to suggest device key creation at creation time as well to identify current device and to ask about regulatory satisfaction

Ian Jacobs (W3C): this would be available in a third party context so better than cookies … it would be good to be relatively long-lived (but still clearable) … if there is another key, do we have to modify 3DS? … I was also going to suggest device key creation at key creation time … do we have a sense of whether this would meet regulatory requirements?

JeanLuc: Thank you for this proposal. It's close to DBSC. Can we trigger the same key outside of SPC authentication? … there's a step where the issuer would like to identify the device (as is done with DBSC)

stephen: In the initial proposal, there would not be a way. But we could look at whether the key might be available via DBSC.

Jean-Luc di Manno (FIME): DBSC+CHIPS in an iframe could work. If issuer could use the same SPC key to recognize the device and not trigger step-up that would be nice. … note that DBSC also involves a direct connection to a RP; we could imagine the issuer as an endpoint and the issuer could do device recognition.

Stephen: Both Ian and Rick thought DBSC should be characterized as distinct from this SPC proposal; not sure myself.

JeanLuc: One question is how to do key renewal. The issuer might record a chain of device keys over time. Will the issuer have information about key renewal?

Stephen: I have not contemplated that. We get into concerns, however, about reinventing the wheel. each API has its own way of doing key management.

JeanLuc: Would this work in a custom tab?

Stephen: yes