Encryption

This is a proposal for a mechanism to encrypt payment method response data for any payment method. End-to-end encryption from payment handler to processor can help address several use cases:

• Encryption of data leaving the browser can lower PCI-DSS assessment burden (for card payments).
• Encryption of payment handler data can protect against man-in-the-browser (MITB) attacks.

High-Level Proposal

• The party that calls Payment Request API (whether the merchant or their processor) provides a public key to be used by the payment handler to encrypt the entire response.
• Only the party who has the corresponding private key (e.g., the gateway) can decrypt the response.
• Each payment method defines which response fields are not sensitive. Those fields are returned in the response along with the encryption of the full response.

Example

const methodData = [
  {
    supportedMethods: "basic-card",
    data: {
      supportedNetworks: ["visa", "mastercard"],
      supportedTypes: ["debit", "credit"]
    }
  },
  {
    supportedMethods: "https://example.com/bobpay",
    data: {
      [...method data...],
      dataSecurity: {
        responseEncryptionKey: {...}
      }
    }
  }
];

The response data would include:

• an encrypted PaymentResponse.details object inside of a JOSE JWE envelope, and
• any payment-method defined non-sensitive fields, returned unencrypted.

   {
      encryptedData: {...},
      plainData: {...}
   }

Note that the merchant does not determine which fields the payment handler should return in plainData; that determination is made in a standard fashion by the payment method definition.

Data model

• dataSecurity is a container for security-related information from the requestor. (It is reused in the proposal to protect against tampering.)
• encryptedData is the PaymentResponse.details object inside of a JOSE JWE envelope
• plainData is an unencrypted list of payment-method defined, non-sensitive response fields.

Additional Considerations

• Keyur: Needs to support asymmetric and symmetric encryption.
• Q. Do we need just one encryption, or might we need to encrypt for multiple parties?
• The data model described above has been conceived to enable experimentation with these ideas without requiring changes to the Payment request API or Payment Handler API specifications.
• Encryption could be done either within a payment handler or by the mediator.
• If the mediator were to take responsibility for the encryption, only the embedded data object would need passing to the payment handler. The payment handler could remain unchanged. However it should be noted that, at least for initial PoC, this is not required and the payment handler should deal with the encryption. This could then be generalized with the creation of standard libraries to aide implementation.
• This is not a proposal to replace TLS encryption or other transport encryption which occurs from the browser to the merchant and from the browser to the payment handler.

FAQ

Why is TLS not sufficient?