Re: Authenticating Merchants

Comments in line.

On 2017-02-23 22:44, Adam Roach wrote:
> On 2/22/17 01:58, Anders Rundgren wrote:
>> Merchant authentication seems to have two primary goals:
>> 1) giving the Payment Provider a chance to block a payment request because the Merchant has been black-listed.
>
> The current specification does pass along the (authenticated) origin of the payment requester. This origin could be used as input to any kind of desired whitelist/blacklist scheme.

That's great!  However, some systems (including Apple Pay), introduce another Merchant trust architecture which (usually) is exclusive for the payment network.


>
>> 2) if authentication is performed through a digital signature, verify that the payment request haven't been tampered with. 
>
> By whom? I've heard this mentioned a couple of times already, but always in a hand-wavy kind of way. Describe, concretely, the attack you are attempting to avoid.

A payment ecosystem consists of independently managed systems where particularly Merchants' and Users' systems are not assumed to be perfect.  A Merchant signature (if it can be securely derived to the claimed Merchant identity NB...), at least provides some kind of proof that the involved parties are actually dealing with the same data.  So I would rather characterize this as a basic data integrity solution.

Anyway, this draft
https://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
confirms the view that transaction related security solutions like Merchant signatures are out of scope for the WG since it currently doesn't sign anything.  I don't understand who is supposed to add this to the plot.

Anders

>
> -- 
> Adam Roach
> Principal Engineer, Mozilla