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! -- 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-347605320
Received on Tuesday, 28 November 2017 17:46:36 UTC