Re: [w3c/payment-request] PaymentRequest - Bluetooth connector (#865)

> I disagree. This use case has been top of mind for some time. It's quite easy for a Payment Handler (a Service Worker in the browser) to invoke a remote service over the Web when it is activated by a new Payment Request.

If it is that simple it should be simple to host an example showing how this would work in practice.

I'm indeed suggesting an alternative form of payment handler that follows the trail of FIDO2/WebAuthn (which has nothing to do with service workers as far as I know).   Such a solution would also work with payment authorization systems where the client only communicates with the merchant.

From a security point of view these concept are quite different since the service worker solution builds on OOB communication while the proposal uses a direct link (Web/Browser/PR API <=> Phone).  For authentication this is significant, for PaymentRequest it may be less vital but it is always nice to not have to bother about phishing.

Anyway, before slashing this proposal I suggest evaluating Apple Pay because the end-result for whatever solution you create must match Apple Pay.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/865#issuecomment-483338109