@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 -- 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-347702663
Received on Tuesday, 28 November 2017 23:44:57 UTC