Propose a payment method specification that includes an example of field level security

[adrianhopebailie]

This action was inspired by the discussion on #55.

It would be useful if someone in the group proposed a payment method specification that illustrated how field level encryption or signing could be used in the payment method data. This may be in the form of an "Advanced Card Payment Specification" or an extension of some other scheme.

[halindrome]

I agree that this would be very valuable. I also feel like it would be an incremental change to almost any existing payment method specification (once there are more of them).

[corwinAmbre]

Hello,
In order to reduce security risks on client side, I would suggest to delegate this part when the show method is fired. As I'm pretty sure it won't be possible to have a common encryption mechanism for all payment methods, the data will be available in plain text at the beginning of the process.
When show method is triggered, the browser first request to the payment application a public key (encryption method could be added here if needed). If received, browser internally replace plain text data with encrypted data. If field encryption is not supported, previous call can send back a "not supported" message and plain text data will be kept to call the payment app.
The payment flow itself is then unchanged. I tried to summarize it in this Sequence diagram
This approach should:

• minimize public key exposition to client. A public key could be generated for each payment instead of being hard coded into the merchant website
• allow transparent update for integrators to field encryption mechanism as it would be automatically done between browser and payment application

Currently, our team integrated many payment methods and none of them have encryption at field level, maybe because most of the calls are made server-side.
I hope it'll help you.

[halindrome]

I think actually if there is any encryption beyond TLS, it would necessarily be on the merchant side when initiating the request. If I care about encrypting my content, I surely do not want to expose it to the user agent. I want to pass the encrypted blob to the payment app along with some sort of an indication of how to decrypt it.

I also think this is out of scope for what we are designing right now, but I could be wrong.

[lyverovski]

Agree that a field-level encryption mechanism should be investigated further, and a field level encryption mechanism that supports any number fields (not just the basic card payment fields) would be valuable.

Field-level encryption is beneficial in scenarios where a third-party (e.g. the merchant) is in the flow of the information that we wish to protect. A number of PSPs have client-side encryption mechanisms, whereby an encryption key is requested from the PSP by the client (typically via Javascript in the user’s browser) for each transaction. This is for the purpose of encrypting the payload prior to being submitted to the merchant’s servers, who then submits the payload to the PSP for decryption and processing. However, the original intent was to reduce PCI exposure for the merchants, however the PCI standards council has since implemented the Self Assessment Questionnaire (SAQ) A-EP as part of PCI DSS 3.0, for specifically this scenario.

@halindrome: I want to make sure I understand your point above. In some cases, the user agent itself is the payment app (e.g. basic card payment flow where the browser stores the card details). I think the merchant would need to identify the fact that it can support field-level encryption for specific PSPs or payment apps, however the key itself would need to be provided by the PSP.

[rsolomakhin]

@halindrome wrote:

this is out of scope for what we are designing right now

+1

[ianbjacobs]

Migrated to:
w3c/webpayments#179