- From: Anders Rundgren <notifications@github.com>
- Date: Tue, 23 Apr 2019 12:04:55 -0700
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/issues/865/485934249@github.com>
Well, unfortunately I'm not (at all) a Bluetooth expert but maybe the FIDO interface could serve as a model? https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-bt-protocol-v1.2-ps-20170411.html As far as I understand the FIDO solution (when connected) advertises its availability to the browser's FIDO implementation making it transparent for a relaying party Web application if the FIDO authenticator is a part of the computing device itself or is externally provided through Bluetooth, USB etc. This is what I meant with "docking". _Bluetooth pairing is system wide_ and not related to FIDO but there is a specific service for FIDO. Applied to payments a native mobile App supporting `PaymentRequest` would through the proposed interface also be able to offer a desktop the same payment methods. Although `PaymentRequest` is a more elaborate solution than FIDO, I guess the OS/Browser/Mobile "plumbing" would be pretty much identical. I may (surely) be wrong, but from a security point of view I don't see any difference between a PR window popping up on the desktop than on a connected mobile device. If additional security decisions are required like "_this is the first time you interact with_ `evilmerchant.com`", they would likely be performed in the mobile device. -- 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-485934249
Received on Tuesday, 23 April 2019 19:05:17 UTC