Re: Authenticating Merchants

Thanx Tommy for a good response!

I also noted that the Merchant signature issue has has been put on hold.

Anders

On 2017-02-22 13:54, Tommy Thorsen wrote:
> Payment Providers that want to do Merchant authentication, should require some form of Merchant identifier to be passed in the PaymentMethodData.data <https://w3c.github.io/browser-payment-api/#dom-paymentmethoddata> field. The Payment Provider is free to decide how this data field should look, and what are the required fields, so there's no problem requiring the Merchant to also pass some kind of signature that can verify the integrity of the Payment Request and the identity of the Merchant.
>
> You could argue that these things should be actual members of the Payment Request dictionary or on of the sub dictionaries, but I think it's actually better that they are not. First and foremost; Merchants will most likely have different identifiers with the different Payment Providers, meaning that a single merchantId field is not going to work very well for a Payment Request that supports many different payment methods.
>
> Signing Payment Requests has been discussed, for instance here: https://github.com/w3c/browser-payment-api/issues/291
>
> -Tommy
>
> On Wed, Feb 22, 2017 at 8:58 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     Have you considered authenticating Merchants in some way?
>     It is possible that I haven't looked enough, but I couldn't find such references.
>
>     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.
>     2) if authentication is performed through a digital signature, verify that the payment request haven't been tampered with.
>
>     Apple Pay seems to have something along these lines which (at least) checks that the Merchant is a genuine Apple Pay Merchant.
>
>     /A
>
>