How do we protect certain data in the messages from certain parties in the flow as the use case requires?

[adrianhopebailie]

Split out from #19 which is focused on the need (or not) for digital signatures as a way of validating that the payment request is received as intended by the payment app.

In that thread @mattsaxon raised a requirement for payment apps to be able to return data that is hidden from the payee themselves (perhaps for PCI scope reasons) as they will pass it on to their PSP who can then decrypt it and use it:

Some elements in the payment response may need to be hidden from the merchant also (e.g. card number)

@CYV suggested SCAI as an option for standardisation of signing and encrypting data through a multi-party flow:
https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI

So the question becomes; is field level encryption something that should be:

1. standardised and the Web Payments specs define this standard
2. defined as a best practice and the WG publishes this guidance
3. left entirely to the payment app publishers and payment methods to define as they see fit

[haavardmolland]

What would the reason be for standardizing it? That the Web Payment spec guarantees some level of security? That it will be easier for payment apps to apply message authentication and confidentiality?

I'm skeptical about this being standardized, and believe it should be left to the PSPs and the payment apps. Cryptography is a living research area, it is complex, and if you look at TLS it's easy to see how that leads to constant changes and backward compatibility issues for the browsers and other clients. Even if Web Payments spec did standardize message authentication and confidentiality, many PSPs would likely end up continue using their own schemes.

Finally, in many cases, it's not the payment app that applies the message authentication and confidentiality. It may be done by the PSP itself when the payment app authenticates the user and authorizes the transaction. The payment app will then forward the authorization message from PSP to the payee, which then forwards the message back to the PSP embedded in a transfer request. This is how Braintreepayments is set up (follow the nonce).

[rsolomakhin]

In the interest of keeping the API simple, I prefer option 3 ("Leave entirely to the payment app publishers and payment methods to define field level encryption as they see fit"). Also, this works nicely with payment apps that talk directly to payment processors, although this is not part of the spec. For example, Android Pay talks directly to Stripe and sends a crypto-token to the merchant. This crypto-token is opaque the merchant.

[ianbjacobs]

Each spec should have a "security considerations" section. We could say in the security considerations section that:

• Many applications will want to encrypt data. They should do so according to their needs.
• W3C has a WebCrypto API for doing so interoperably:
  http://www.w3.org/TR/WebCryptoAPI/

So maybe that is "option 3, but with some pointers to relevant work such as WebCrypto API"

Ian

[halindrome]

As I mentioned in issue #76, I thought we should try to tie this discussion back to our use cases at https://www.w3.org/TR/web-payments-use-cases/

I think that the following use cases are related to this feature:

Use case 6.1.2 (Registration-less payments) supports this in that portions of the payload relate to the identity of the payer, and they don't want the site getting that information.

Use case 6.2.2 (payer privacy) the payer might want to require obfuscation of the source of the funds, of their address, of their name. As long as the payee gets the funds, that is enough for some things.

Use case 6.3.1 (payer intiated payments) can be seen to support this, as presumably there is information the payee sends to the payer that then needs to be sent back to the payee to confirm the payment - but that information should be concealed from the payer's payment instrument. E.g., paypal doesn't need to know what I am buying - they need to send 9.95 to the payee.

Use case 6.4.2 (electronic receipts) is also relevant. An encoded receipt should be delivered as part of the payload; it may even move through all the corners of the transaction. However, only the payee and the payer should be able to decode that receipt. I could see smart wallet and payment apps might want to help their users by collecting and storing receipts for later reference (Android Pay, for example, does this now).

[adrianba]

I agree with @rsolomakhin - this is something that varies by payment method.

[adrianhopebailie]

Having looked at the use cases from @halindrome I am inclined to agree with the rest of the comments that this is not something that we should try to standardize.

Would everyone be happy if I propose that we put this explicitly out of scope for the API specification?

Note: I don't think that prevents anyone that wishes to write up some guidance on how this could be done, doing so, and if the group agrees with the work it could be published as a group note and referenced informatively from the Security Considerations section.

Note: We will likely provide an example of how this can be done in the card payments specification which we have proposed to do.

[msporny]

Migrated to w3c/payment-request#55.

@adrianhopebailie, close this issue if you feel like w3c/payment-request#55 should be the new home for this issue.