- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 6 Jul 2016 07:19:14 +0200
- To: "Michael[tm] Smith" <mike@w3.org>, Adam Roach <abr@mozilla.com>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>, Florian Rivoal <florian@rivoal.net>
On 2016-07-06 03:47, Michael[tm] Smith wrote: > Adam Roach <abr@mozilla.com>, 2016-07-05 16:54 -0500: >> Archived-At: <http://www.w3.org/mid/23cb8d4c-e8f4-0081-b281-939a1a7db90a@mozilla.com> Well, this topic is by no means new, it has been mentioned (primarily by me...), but has to date been dismissed (or ignored) by the TAG, WebApps, and WebAppSec WGs since it is not the "Open Web". FWIW, Mozilla and Microsoft run a little-known W3C CG for this purpose: https://www.w3.org/community/browserext/ The CG currently proposes something which is a clone of Chrome's native messaging: https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host However, "in-browser" extensions and calling external applications are two entirely different use-cases. That they also have equally different security considerations IMHO, makes it more logical running these as separate missions. Although constraining native applications to the Web Payment API may be simpler (?), I wouldn't take that path. Below is a enhanced variant of native messaging which is "liberated" from the generic browser extension scheme: https://github.com/cyberphone/web2native-bridge#api You can even test it if you want: https://test.webpki.org/webpay-merchant/home The PC client (Win/Mac/Lin) uses a multi-step SPA (Singe Page Application) which also shows how much cleaner things get (on both the merchant side and in the native application) if you are not forced using HTTP POST like required by the Android implementation. Anders >> >> Ahead of seeing some of you face-to-face this week, I wanted to send out >> some thoughts about how native payment apps can be incorporated into our >> existing work by leveraging work already underway in the web browser space. >> To be clear, I'm not expecting to discuss this during our formally scheduled >> meetings, but would love informal feedback either via email or after hours. >> >> https://docs.google.com/document/d/1eljnrb4pT9ggRi7E_1T_jjv2CDt0i4sIxrrGfWgibvI/edit?usp=sharing >> >> At this point, I'm not sure this even needs any particular specification, as >> it functionally describes how to use existing technologies to bridge from >> the work we're currently engaging in to native applications. However, >> keeping this approach in mind as we move forward with the payment app spec >> -- to ensure we don't cut off this otherwise straightforward avenue as we >> develop that API -- would probably be quite helpful. > > Given that making this usable in browsers on mobile devices is important, and > relying on this approach would require users to install a browser add-on/ > extension, it seems like in practice a lot of the utility of this would depend > the browsers that users use allowing them to install add-ons/extensions. > > I know Firefox for Android has support for user-installable add-ons, and > there’s no technical limitation that would prevent other browsers from > providing users with the ability to install add-ons/extensions, but > currently Chrome for Android at least doesn’t allow users to do that. > > So the lack of extensions support in Chrome for Android would somewhat seem > to limit the utility of a browser-extension approach as far as solving > problems for many users on mobile. > > —Mike > > >
Received on Wednesday, 6 July 2016 05:19:51 UTC