Should the messages support field-level encryption?

[msporny]

Migrated from w3c/webpayments#78 via @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

[adrianhopebailie]

Based on the discussion on the original thread I believe the consensus to be:

1. A standard for this is out of scope for the API specification
2. We should include some discussion on this in the Security Considerations
3. We should consider providing a mechanism for field-level encryption in the basic card payments specification as an example of how this could be done.

If that is the consensus then I'll close this issue and record that outcome.

[burdges]

Just allow fields to be base64 encoded encrypted blobs if the payment app supports it perhaps?

It's only really a problem if the spec says some field is required, and some payment app says that field needs to be private when turned over to the PSP or whoever, possibly for legal reasons btw. As long as any field that needs protection from some party isn't required in the first place then it's probably not a problem anyways.

[ianbjacobs]

@adrianhopebailie,

+1 to the proposal.

Ian

[mattsaxon]

@adrianhopebailie,
+1 to the proposal.

Though in terms of management of issues, should we not wait until the spec is updated to reflect the outcome rather than close the issue now?

[adrianhopebailie]

@msporny,

I sent a mail [1] to the IG (specifically the VCTF) hoping that someone would step up to document how field level encryption and signing could be done for payment method specific data.

I agree with @mattsaxon that we shouldn't close this until someone has taken this on, but thus far I have had no response to my email. Is this something the VCTF plans to look at?

[1] https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Apr/0015.html

[burdges]

We should probably avoid limiting field size as if maybe one needs to encode after first encrypting with a nonce, public key, and authenticator, which obviously consumes space. This is not really an issue in JavaScript anyways.

[adrianba]

@adrianhopebailie wrote: "If that is the consensus then I'll close this issue and record that outcome."

I agree and recommend closing this issue.

[adrianhopebailie]

There is an issue marker in the spec indicating the need to add a security section and addressing this issue. I leave it with the editors or someone else in the WG to address this outstanding requirement.

[ianbjacobs]

I don't think basic card should deal with field level encryption. Perhaps we will have an "advanced" card specification that could do more.

(I am also thinking about what enhanced security might look like; if I come up with something I will share here.)