Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PaymentRequest - Bluetooth connector #865

Open
cyberphone opened this Issue Apr 12, 2019 · 19 comments

Comments

Projects
None yet
3 participants
@cyberphone
Copy link

cyberphone commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 12, 2019

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.

@cyberphone cyberphone changed the title Consider offering a Bluetooth connector PaymentRequest - Bluetooth connector Apr 12, 2019

@marcoscaceres

This comment has been minimized.

Copy link
Member

marcoscaceres commented Apr 12, 2019

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 comment has been minimized.

Copy link
Author

cyberphone commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Member

marcoscaceres commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 12, 2019

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

Anyway, what do you think about the proposal?

@marcoscaceres

This comment has been minimized.

Copy link
Member

marcoscaceres commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 12, 2019

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

Please explain how

@marcoscaceres

This comment has been minimized.

Copy link
Member

marcoscaceres commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Member

marcoscaceres commented Apr 12, 2019

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

@cyberphone

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Member

marcoscaceres commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Collaborator

adrianhopebailie commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Collaborator

adrianhopebailie commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Member

marcoscaceres commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Author

cyberphone commented Apr 16, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.