Re: [w3c/webpayments-methods-tokenization] Generalisation of Encrypted Card (#22)

@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

-- 
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/webpayments-methods-tokenization/issues/22#issuecomment-348982149