PaymentRequest - Bluetooth connector

[cyberphone]

As far as I know Apple Pay in the Mac/iPhone "combo" uses Bluetooth to achieve an integrated and convenient payment solution.

Although one can use Web Bluetooth this has major shortcomings and (probably) requires the user to grant each Merchant access to the Bluetooth connector.

With a dedicated interface this is not necessary since the Merchant never talks directly to Bluetooth channel (it isn't even aware of it). For the Merchant it is just PaymentRequest.

I believe this builds on the very same idea: https://www.blog.google/technology/safety-security/your-android-phone-is-a-security-key/ Here it is rather a FIDO2 interface.

[cyberphone]

Unlike the proprietary Chrome PaymentRequest Android interface, the Bluetooth counterpart must be universal. It can probably reuse the platform used by FIDO/WebAuth making the task quite reasonable.

In addition to being "phish-safe", this solution would eliminate quirky QR solutions or solutions using mobile phone numbers for establishing a trusted link between the Web application running a PC/Mac and a mobile wallet.

[marcoscaceres]

Although one can use Web Bluetooth this has major shortcomings and (probably) requires the user to grant each Merchant access to the Bluetooth connector.

I think it would be granted to the payment handler, not the merchant's website. Thus there would only be one prompt.

[cyberphone]

This proposal is unrelated to W3C's PaymentHandler, it builds on forwarding the PaymentRequest to a native mode mobile wallet which I believe is analogous to the FIDO2/WebAuthn use case.

[marcoscaceres]

The Payment Request API relies on some payment handler (e.g., basic card, apple pay, BlueTooth Terminal-0-matic) showing some UI... so I'm not following how it's unrelated to payment handler?

[cyberphone]

Sorry, it was a terminology issue. I thought you referred to the W3C PaymentHandler.

Anyway, what do you think about the proposal?

[marcoscaceres]

Anyway, what do you think about the proposal?

The proposal is fine, but I think it could be handled by any old payment handler. It doesn't seem to be in scope for Payment Request?

[cyberphone]

The proposal is fine, but I think it could be handled by any old payment handler.

Please explain how

[marcoscaceres]

you would create a payment handler and it would call the show window API when required to show the payment sheet... in the payment sheet, you would use the BlueTooth API to pair with the hardware. The user would grant access once. The browser would remember that "https://blue-tooth.payment.com" is allowed to use BlueTooth in the payment sheet.

Then if you got to another website and try to pay, the browser already knows that "https://blue-tooth.payment.com" already has the permission grant... so if the user chooses to pay with that payment handler, it just works (TM).

[cyberphone]

The idea was creating a counterpart to FIDO2/WebAuthn by defining a standardized interface between the Web and a bluetooth-connected device. The interface would follow the PaymentRequest API since it effectively works under the same umbrella. There would in similarity to FIDO2/WebAuthn be nothing to install in the PC/Mac end.

https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html

[marcoscaceres]

We generally don’t want to do specialized APIs like that. Ideally, we would make Web Bluetooth work.

[cyberphone]

This (mobile wallet + PC) is probably the biggest PaymentRequest use case after the mobile Web. I'm merely suggesting another way hooking into the PaymentRequest API, not a new API.

I leave it there and hope that you and team evaluate the different approaches. Since there already is a predecessor (Apple Pay), this should be reasonably simple.

Note that for the Merchant the code for the Mobile Web and the PC Web would be identical using the integrated approach.

[marcoscaceres]

I understand, but some UI needs to be shown, right? Like ApplePay (a payment handler) has a UI that does the interfacing with watch or phone.

Similarly here, won’t you need some kind of payment handler?

[cyberphone]

IMO, there would not be a need for a new UI in the PC/Web end; the PaymentRequest would only expose the additional matching payment alternatives acquired through the Bluetooth connection. It is like payment method "docking".

In the Mobile end, there would of course be a UI that should show the amount requested etc. This part would not differ from what for example Google Pay already does for Mobile Web.

There are a billion+ mobile wallets out there that could benefit from a solution that is standardized in the Merchant end while offering a better UI for users. This ought to be a great way to gain more traction for the PaymentRequest API. This is one step further towards "Converged Payments". The next step is the PoS terminal. Imagine, one protocol to rule them all! 😀

[adrianhopebailie]

The universal interface for PaymentHandlers is currently defined as browser API's in the Payment Handler API spec.

Chrome on Android also supports handlers in the form of Android apps and this interface is defined at the Android OS level.

Can you explain in more details how the same APIs and flows would be implemented via BT? Noting that this involves enrolment, and then handling payments.

What is the user experience you envisage? How would the origin-based security work?

[cyberphone]

Starting with the rationale. Mobile phones have become the center for just about everything, nowadays also including payments. However, some people (quite a bunch in fact) still prefer doing their on-line business on a "PC". The question is then how to combine the mobile phone holding payment credentials and the PC/Web. The current version of PaymentRequest doesn't do this particularly well.

In this proposal I envision the phone docking into the browser and enumerating its payment methods.

In the PaymentRequest UI on the PC you would see the new methods (maybe attributed by an icon indicating that they reside on a mobile device).

If the user selects a "mobile" payment method the phone would show a pay interface.

For PaymentRequest it is just another driver.

The security decisions would in this model be delegated to the mobile device like already is the case for the QR code predecessors. I haven't had the opportunity to test the Apple solution which I believe does something quite similar.

It probably requires a rather deep integration in the mobile end as well.

[adrianhopebailie]

The current version of PaymentRequest doesn't do this particularly well.

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.

That remote service pushes a message to the user's phone and the user approves the payment in the app on their phone.

I use a similar interaction daily to login to Google services and login and approve payments in my online banking service.

In this proposal I envision the phone docking into the browser and enumerating its payment methods.

Can you describe further what "docking" means? How does this pairing work and what OS-level APIs/features are required to allow this?

For PaymentRequest it is just another driver.

It's important to get the terminology right here because I think you and @marcoscaceres may be talking across each other. PaymentRequest is simply and interface for passing a payment request to the browser and returning a response to the website. It doesn't define how the browser gets that response.

We have defined an abstract component called a "Payment Handler" which handles the request and returns the response and we have specified an API for payment handlers (implemented as service workers) on the Web to register themselves with the browser and accept and respond to payment requests.

If you want to define an alternative form of payment handler then I think that would need to be in the form of an alternative payment handler API that defines how the handler registers itself with the browser and how it handles payments.

[cyberphone]

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.

[marcoscaceres]

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

Precisely, but the burden of proof falls on you to create such an example.

[cyberphone]

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

Precisely, but the burden of proof falls on you to create such an example.

@marcoscaceres @adrianhopebailie No, a solution proposed by somebody needs to be proven by the proposer which in this case (effectively) is the Web Payment WG. BTW, it sounds like a pretty fuzzy process having to install service workers for external (mobile phone based) payment handlers. Current solutions (which do not use PaymentRequest in the PC end) do not introduce such requirements.

This proposal builds on extending already rolled out concepts such as the Apple Pay MacOS/iOS "combo" and FIDO2/WebAuthn. The latter does (AFAIK...) not depend on push services or service workers.

Since one vendor already have a (vendor specific) solution, it really boils down to what the other vendor (having an 80% market share) wants to offer as a remedy. It is of course way simpler building a Chrome/Android specific solution. Note where you read it first 😀 @danyao @rsolomakhin

[adrianhopebailie]

It is of course way simpler building a Chrome/Android specific solution

Of course. Fortunately Google have chosen to support an open ecosystem by implementing Google Pay using the same tools anyone could use to publish their own handler.

[adrianhopebailie]

In this proposal I envision the phone docking into the browser and enumerating its payment methods.

Can you describe further what "docking" means? How does this pairing work and what OS-level APIs/features are required to allow this?

Providing this detail would really help make some progress here

[cyberphone]

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 example-merchant.com", they would likely be performed in the mobile device.

[adrianhopebailie]

Sounds like this is an integration between the browser/OS and the phone app/OS no?

Do you think this is something that should be standardised at W3C?

I agree that this would be a great UX hence we have designed for something similar (albeit proxied via the Internet) but I'm not sure that the W3C is the place one would work on this.

[cyberphone]

Sounds like this is an integration between the browser/OS and the phone app/OS no?

Right on!

Do you think this is something that should be standardised at W3C?

It is something that maybe could be standardized at W3C.

There are tons of other payment related issues that also lack a natural home, like electronic receipts.

[cyberphone]

Whatever solution we come up with we face the non-trivial task of convincing Merchants abandoning their current QR-code solutions. That these aren't compatible (desktop-wise) with PaymentRequest is (at the moment) not an issue. My proposal is very much about making the conversion to PaymentRequest more attractive by unifying the mobile and desktop in a way that is transparent for Merchants.

PaymentHandler is a cool concept but it is actually quite limited compared to mobile wallet solutions.

[ianbjacobs]

I'm going to close this issue because it does not bear directly on Payment Request.

For those interested in enabling more bluetooth use cases for the Web generally, please check out the work of the Web Bluetooth CG (though I don't know how active it is these days): https://www.w3.org/community/web-bluetooth/

Ian

[cyberphone]

Let me finish this issue with a few remarks:

• Extending payment solutions based on native payment handlers need solutions that are compatible with the distribution method used for native applications. That is, bringing in a ServiceWorker etc. is hardly a viable option. In fact, many native payment solutions do "by design" not even have a domain concept permitting them to host multiple payment credentials from independent payment providers in a single "wallet". See also: https://github.com/w3c/payment-handler/issues/368
• The security model for such schemes (pretty much independent how they are architected), also departs from the "tradition", since the critical resources are in the connected device rather than in the desktop browser. This is a bit similar to the Android Studio debugger, where it is the debugged device that asks its user if it is OK to be connected which is quite logical since debugging is potentially both privacy- and security-invasive.

The net effect of not having a useful DesktopWeb-2-MobileWallet solution is that PaymentRequest cannot be used for this quite popular scenario. QR remains as the currently only credible solution and is also the method established by the Chinese and [most of the] European mobile phone based payment providers.

@rsolomakhin @danyao