Re: [w3c/browser-payment-api] Propose a payment method specification that includes an example of field level security (#141)

Agree that a field-level encryption mechanism would be valuable to investigate 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 ensure 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.
 

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/141#issuecomment-212228529