How do we ensure that the payment request from the merchant is not tampered with before it gets to the payment app?

[msporny]

If a merchant requests a payment, how can they be sure that their payment request is not tampered with when in transit to a 3rd party payment processor?

[msporny]

There are at least two ways to accomplish this:

1. Create an independent channel between the merchant and customer payment processor to send the payment request over.
2. Digitally sign the payment request.

I suggest that #2 is more flexible in the long run as the payment request could travel through a variety of communication channels that we can't imagine today. For example, HTTP -> NFC -> Bluetooth -> HTTPS.

[mattsaxon]

Some elements in the payment response may need to be hidden from the merchant also (e.g. card number), so signatures don't meet this requirement. Since we are creating other connection from the browser, e.g. to cloud payment instruments, couldn't the connection to the PSP be via the same means? My view is we may need to support both methods.

[CYV]

I may be rude, but the SCAI approach was:

• to avoid any tampering of the data by digital signing
• to enable some data could be hidden from the merchant (or from any other actor) (tunnelling)

regards

[ianbjacobs]

Cyril is referring to this proposal:
https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI

[msporny]

Some elements in the payment response may need to be hidden from the merchant also (e.g. card number), so signatures don't meet this requirement.

I'm wondering if you're raising another important issue.

This particular thread is about how you can trust a particular payment message.

I think what you're talking about could be broken into two sub-issues:

1. How can you obfuscate information in a payment message (encryption), and
2. What do you do with data that a PSP should not see (such as receipt information intended for a customer), or data that a merchant shouldn't see (such as a card number)?

Care to split it out into a different issue, @mattsaxon?

Since we are creating other connection from the browser, e.g. to cloud payment instruments, couldn't the connection to the PSP be via the same means? My view is we may need to support both methods.

For things like the PAN, I think the PSP would just drop that on the floor and not include it in the payment response message.

You do raise another interesting point, though. For example, when we get to digital receipts, how is that handled? The merchant could:

1. Provide a digital receipt at the point of the payment request
2. The pop-up takes over (keeping the merchant channel open), splits the digital receipt out (storing it temporarily), sends the payment request (sans receipt) onto the payment processor channel
3. The payment processor responds with a success via the payment processor channel
4. The pop-up opens a receipt storage channel to the customer's receipt storage location w/ the receipt and proof of success
5. The pop-up then relays the proof of success via the merchant channel back to the merchant.

In this example, the pop-up has 3 channels open:

• merchant channel
• receipt storage channel
• payment processor channel

To be clear, I don't think this is what we should do - receipts would most likely be best handled as after-the-fact storage decisions. I can't think of a realistic use case where we'd need to open more than two channels, but I can certainly conjure up edge-case ULTRA SECURE payment instruments that require you to piece together data from different servers at different data centers around the world.

Just food for thought - we may need to open more than 2 channels in the payment selection pop-up/message relay component (aka wallet).

[msporny]

the SCAI approach was:

• to avoid any tampering of the data by digital signing
• to enable some data could be hidden from the merchant (or from any other actor) (tunnelling)

Yes, but I expect that not everyone feels that digital signatures are absolutely necessary and there may be others that don't believe that in-message encryption is necessary.

I'm merely raising the point that both will most likely be necessary, if not for phase I, for later phases and we should keep this in mind as we do the design work.

[mountainhippo]

@manu

Merchants sometimes do want to see card number though. It might not be best

practice but it is certainly allowed today and supported.

Nick Telford-Reed
e: nicktr@gmail.com
m: +447538177619
On 3 Dec 2015 3:32 a.m., "Manu Sporny" notifications@github.com wrote:

the SCAI approach was:

• to avoid any tampering of the data by digital signing
• to enable some data could be hidden from the merchant (or from any
  other actor) (tunnelling)

Yes, but I expect that not everyone feels that digital signatures are
absolutely necessary and there may be others that don't believe that
in-message encryption is necessary.

I'm merely raising the point that both will most likely be necessary, if
not for phase I, for later phases and we should keep this in mind as we do
the design work.

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

[mattsaxon]

Care to split it out into a different issue, @mattsaxon?

We perhaps don't need a separate issue at this stage, the flows I am referring to are covered by the documented flows from the task force.

[adrianhopebailie]

I agree with @msporny that there are two issues here.

1. How do we ensure that the payment request from the merchant is not tampered with before it gets to the payment app.
2. How do we protect certian data in the messages from certain parties in the flow as the use case requires.

I think issue 2 is a problem for the designers of payment methods to solves ASSUMING we have solved issue 1.

The payment request from the website to the payment mediator (User Agent) and then to the payment app needs to be tamper-proof. Only then can the payment methods specific processing kick-in and implement whatever security mechanisms the payment method prescribes.

Is it sufficient to say that the API calls are only made in a secure context?

What happens if my UA has been compromised and whenever I get a payment request the merchant details are changed so my payment goes to the wrong person?

Do we need a standardized way to sign the payment request?

[ianbjacobs]

As mentioned on a separate thread, I think W3C WebCrypto [1] is relevant here but I don't know whether it meets all our needs. As the spec is fleshed out we'll know more.

@adrianhopebailie asked:
"What happens if my UA has been compromised and whenever I get a payment request the merchant details are changed so my payment goes to the wrong person?"

It seems to me that, like other topics, Web apps and payment apps can determine the degree of security they wish to guarantee. Some apps will use signatures, I assume, and perhaps they will distinguish themselves in the market by doing so. We make it easier to do through the WebCrypto API.

Thus, in the spec we can call this as a "Security Consideration".

Ian

[1] http://www.w3.org/TR/WebCryptoAPI/

[burdges]

As long as you imagine the person being payed is a merchant, as opposed to say a friend, then they do not need cryptographic deniability, so signatures work in principle. I suppose the question can be more clearly phrased as, how does the payment applicaiton get the merchant's key material, no?

Apologies if this is dealt with elsewhere, but does the standard address how should one deal with signing JSON data? It's obviously possible to construct a canonical JSON representation, as a string and sign it, but that proves tricky in practice. We wound up signing C structs encoded with C code compiled to JavaScript using emscripten, which although hacky at least always works correctly.

[dlongley]

Apologies if this is dealt with elsewhere, but does the standard address how should one deal with signing JSON data?

There's work in this area: JWS, a proposed standard at the IETF, and Linked Data Signatures, work from the Web Payments and Credentials CGs at W3C.

[msporny]

Migrated to w3c/payment-request#41