Generalisation of Encrypted Card

[mattsaxon]

@oyiptong made a well received proposal at TPAC 2017 for Encrypted Card, it was proposed that we could investigate the generalisation of this for all payment methods and a group discussed this at a breakout session. Other participants were Manu Sporny, Dave Longley, John Best and Andre Lyver.

Here are the bare bones notes that session as captured by me. It is unlikely to be a complete representation and as such I raise this issue to track the review of the notes and further refinement before the possible presentation back to the main group.

The notes are here

Please click below when you've reviewed and are happy;

• [ ] Manu
• [ ] Olivier
• [ ] Cyril
• [ ] Vincent
• [x] Ian (reviewed but do not yet support; see comments on this thread)
• [ ] Dave
• [ ] John
• [ ] Andre

[cyberphone]

This may sound as a good idea but it is not because all real world payment methods including Android Pay and Apple Pay already come with their own specific security solutions. Adding another layer on top of that will most certainly have a detrimental effect on interoperability.

The problem mentioned with encryption (a bad Merchant could swap key), is fully addressed in more developed payment solutions such as Saturn where the encryption key is provided as a part of the payment credential.

[clyouSeeroo]

I'm in support for @oyiptong's proposal and think that we should work as a separate spec in the WG.

As @oyiptong has mentioned at the presentation of TPAC 2017, this proposal will help reducing the activation cost for the merchants and can be easily adopted in market. Also this proposal seems to use generic encryption algorithm, which it doesn't seems to cause a detrimental effect on interoperability.

Also I'm in support for this because I personally think that security architecture and methods should be opened to public, rather than being in private structure and manner by specific security solution provider.

[cyberphone]

@clyouSeeroo It seems fairly pointless creating security solutions between the User and Merchant since the real relation in a payment scheme is between the User and a payment provider of some kind. Putting anything new security-wise "in between" is asking for problems. Encrypted Basic Card is a very simple solution that might be useful but extending this to other (and by the WG unknown) schemes is something I would be cautious about. It would probably be easier creating a brand new payment scheme with security built in from the beginning. But I leave it there for my part...

[ianbjacobs]

@mattsaxon,

Thanks to you and others for work on this. Here are some comments:

• It is not clear to me that that they key and signature should be part of the data object. I realize the goal is to leave PR API untouched, but that is a secondary priority IMO. I'd like to explore them as siblings to "data".

• I understand the proposal to be about encryption of the response (e.g., due to phrases like "end to end encryption from the Payment App to the Payment Processor"). If so, it's not clear to me what role plainData plays in the request. It is easier for me to envision this:

  { supportedMethods: "https://example.com/bobpay", data: { ...request data goes here...}, responseEncryptionKey: {...key of merchant or processor...}, returnUnencrypted: {property1, property2} }

Or, if you want to group them:

{ supportedMethods: "https://example.com/bobpay", data: { ...request data goes here...} encryption: { responseEncryptionKey: {...key of merchant or processor...}, returnUnencrypted: {property1, property2} } }

Then the payment response could include property1 and property2 in details but no other unencrypted properties. And, if encryption took place, encryptedResponse (which encrypts the entire details) would be present and a sibling of details. (Actually, we should clarify whether encryption is intended to be of the payment details or the entire PR API response.)

I am still thinking about the signature bits.

Thanks again!

Ian

[mattsaxon]

Thanks @ianbjacobs, very useful feedback. see my responses below, though I suspect a call is going to be required to go through in detail.

I agree somewhat with your point about having keys and signatures as part of the blob, leaving it this way moves someway towards what Manu was suggesting in terms of componentisation, rather than building a WebPayment monolith, so my goal was architectural, not editorial.

Re: plainData, this specifies to not encrypt it, so for example where the data is non sensitive and useful for example for routing.

Your example where encryption key is outside of the data implies the same encryption key for all payment methods and that all payment methods should be encrypted. I did not want to require that.

Your second example break my architectural goal of not interfering with the PR and PH APIs, but it could warrant further discussion. I still like the idea of prototyping it without touching them regardless.

Your example suggests that the merchant could specify what fields remain encrypted, in my proposal to date, it is the payment app which controls this, but again it warrants further discussion.

Overall my goal is to build this up slowly using use cases rather than try to support everything at once. 1st step is we should agree how full response encryption is done. If we can get agreement to that, we should build something!

[kmealey]

@mattsaxon; My thanks as well to you and the others for your work on this. Per your request on today's call, following are my high level thoughts for your consideration;

1. As suggested by others, I'd encourage amending the name from Encrypted Card to Encrypted Payment Method or Payment Instrument, as appropriate based on your intended use case(s).
2. For my part, I'd envision several use cases here, and I'd encourage you to explain your thinking around how and why this could be useful for developers, even the basics such as 1. Any security is better than no security. 2. Security in payment networks is typically applied in layers, so encryption is typically contemplated as just one of several security layers that developers should consider when building their payment solutions. Also, you might want to articulate if/whether encryption would supplement other layers (e.g. tokenization, 3DS 2.0 etc.) or is intended as a standalone solution. If so, then when?
3. Is the encrypted solution intended as point-2-point or End-2-End? That is, just the exchange of data between the merchant site - browser or to contemplate the entire payment process from user registration through to payment transaction, clearing and settlement in the instance of a card payment? Either way,

Hope this is useful input to you. Kind regards, Ken

[ianbjacobs]

@mattsaxon, you wrote:

Re: plainData, this specifies to not encrypt it, so for example where the data is non sensitive and useful for example for routing.

I believe I understand the use case. What confuses me is how it is specified. In the example it is shown on request data (e.g., bobPaySpecifiedField). I would expect plainData (or whatever it ends up being called) to be a list of responseData field names.

Your example where encryption key is outside of the data implies the same encryption key for all payment methods and that all payment methods should be encrypted. I did not want to require that.

I was not intending to have one encryption key for all payment methods. I was thinking it would be per payment method, thus a sibling of supportedMethods and data.

Your second example break my architectural goal of not interfering with the PR and PH APIs, but it > could warrant further discussion. I still like the idea of prototyping it without touching them regardless.

+1 to prototyping.

Your example suggests that the merchant could specify what fields remain encrypted, in my proposal to date, it is the payment app which controls this, but again it warrants further discussion.

Yes, that seems to be the main point of differing expectations. I am imagining the Merchant saying: a) I want the entire payment handler response data to be encrypted b) In addition, send me back payment method response members A, B, and G unencrypted.

The use cases from the merchant side include not wanting some information (for PCI reasons), and wanting information for other reasons (routing, display to the user).

What are the use cases from the payment handler perspective? I think it would surprise the merchant to receive unencrypted data without having a say in the matter, especially after explicitly asking for encrypted data.

Thanks again!

Ian

[ianbjacobs]

Moved to: https://github.com/w3c/webpayments-crypto/wiki

[ianbjacobs]

Closing this issue as the proposal has moved and evolved.