Re: [webpayments] Should we be concerned about the use of the Browser API in a non-HTTPS environment? (#20)

> as well as applications that enable user-to-user encryption.

I'm gonna nitpick on the TAG finding. While the abstract mentions user-to-user encryption, I don't really see it discussed in the body of the finding.

I think there are two types of encryption that we are talking about here:

1. Connection encryption (such as TLS) that secures the communication channel.
2. Message encryption that secures the messages in the event that the communication channel is compromised.

I'm a strong +1 for the first item because it's fairly automatic these days and Web developers using the Web Payments API won't be dramatically affected by it.

I'm a bit more concerned about the second item because if we start encrypting messages, that means Web developers may have to start encrypting and decrypting them (added complexity on most Web devs using the payments API). We do want to enable things like encrypted card tokens, etc., and we may want to enable parts of the messages to be encrypted in special cases, but I think we should stay far away from requiring all messages to be fully encrypted.

So +1 for enabling parts of Web Payments messages to be encrypted (like card tokens). -1 for requiring any top-level Web Payments messages to be encrypted (like payment responses).

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/20#issuecomment-161506565