Should we be concerned about the use of the Browser API in a non-HTTPS environment? about webpayments

[msporny]

Should the Browser API be restricted to HTTPS-only environments?

Yes, we want the attack surface as small as we can make it while delivering on the important use cases. I can't think of an advantage that HTTP-only brings other than a potential reduction in cost for buying an HTTPS certificate (and hopefully that's going away soon w/ Let's Encrypt).

[halindrome]

I think consumers are becoming more aware of the little lock icon in the
location bar. They WANT things to be "secure", even as they don't really
know what that means. So yes, require HTTPS. Why not?

On Tue, Dec 1, 2015 at 10:39 PM, Manu Sporny [email protected]
wrote:

Should the Browser API be restricted to HTTPS-only environments?

Yes, we want the attack surface as small as we can make it while
delivering on the important use cases. I can't think of an advantage that
HTTP-only brings other than a potential reduction in cost for buying an
HTTPS certificate (and hopefully that's going away soon w/ Let's Encrypt).

—
Reply to this email directly or view it on GitHub
#20 (comment).

Shane McCarron
[email protected]

[ianbjacobs]

TAG recommends end-to-end encryption:
http://www.w3.org/2001/tag/doc/encryption-finding/
"This includes the use of TLS for transport encryption as well as applications that enable user-to-user encryption."

[msporny]

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).

[adrianhopebailie]

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).

Strong +1

Data in messages will be encrypted or signed as defined by the payment method.
The payments browser API should only be available in a secure context.

[ianbjacobs]

I hear @adrianhopebailie (and perhaps others) saying "If it's meant to be encrypted, the Web app and
the Payment app will both do what's necessary."

This sounds about right if the Web app and the payment app are the endpoints, and they can
encrypt and decrypt the message data. The spec probably should say that the Web application and
the payment app SHOULD secure message data.

Aside: The flow diagrams could aid us in seeing whether there are steps in the transaction where the messages must be secured.

It also sounds like we would want to advise those who want to do encryption to at least consider using the W3C WebCrypto spec (as an informative reference):
http://www.w3.org/TR/WebCryptoAPI/

I do not have any sense yet that a stronger requirement to use WebCrypto for all encryption is appropriate.

[mountielee]

I think HTTPS should be default even considering Web Crypto API.
but allow switching to HTTP with user consent.

On Thu, Dec 10, 2015 at 2:58 AM, ianbjacobs [email protected]
wrote:

I hear @adrianhopebailie https://github.com/adrianhopebailie (and
perhaps others) saying "If it's meant to be encrypted, the Web app and
the Payment app will both do what's necessary."

This sounds about right if the Web app and the payment app are the
endpoints, and they can
encrypt and decrypt the message data. The spec probably should say that
the Web application and
the payment app SHOULD secure message data.

Aside: The flow diagrams could aid us in seeing whether there are steps in
the transaction where the messages must be secured.

It also sounds like we would want to advise those who want to do
encryption to at least consider using the W3C WebCrypto spec (as an
informative reference):
http://www.w3.org/TR/WebCryptoAPI/

I do not have any sense yet that a stronger requirement to use WebCrypto
for all encryption is appropriate.

—
Reply to this email directly or view it on GitHub
#20 (comment).

Mountie Lee

PayGate
CTO, CISSP
Tel : [phone]
E-Mail : [email protected]
Twitter : mountielee

[msporny]

Migrated to w3c/payment-request#22