Re: [w3c/webpayments] [Payment Apps] Extending invocation of payment apps with other techniques than HTTP (#156)

Hi @LaurentCastillo 
In my interpretation Native Messaging features two steps:
1. Invocation of the native App.
2. Creating a channel between the invoking Web page and the native App. 

It is really the latter that makes the difference with schemes using HTTP including:

- Potentially eliminating session state-holding outside of what is usually already provided through the invoking Web page.

- Enables (voluntarily) reuse of the the browser's communication facilities (like "fetch()") which means that external communication required by invoked Apps would be subject to the same security constraints (SOP, CORS, etc) as "real" Web applications, whereas Apps POSTing data OOB are free breaking such rules whenever they want.

- Improved alignment with Wallets using NFC/BLE since these typically do not require Internet connectivity; they rather need a bi-directorial "channel" to the merchant.  The exact nature of this channel  can easily be abstracted.

- Support for Web page and App life-cycle management.  This is currently a major hassle in Android where the invoking Web page becomes "orphaned" and the App continues on its own leading to a poor user experience and occasionally to crashes.

Regarding actual implementations, there is no consensus here, and most W3C folks actually appear to be _against_ standardization of Native Messaging.

Anyway, from what I can deduct, Apple have already created a _proprietary_ and _application specific_ Native Messaging solution:
var request = {
  countryCode: 'US',
  currencyCode: 'USD',
  supportedNetworks: ['visa', 'masterCard'],
  merchantCapabilities: ['supports3DS'],
  total: { label: 'Your Label', amount: '10.00' },
var session = new ApplePaySession(1, request);

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

Received on Thursday, 7 July 2016 16:39:22 UTC