Intent to Ship: Web payment manifests

[Rouslan Solomakhin]

Contact emails

rou...@chromium.org, zk...@chromium.org

Explainer

https://github.com/zkoch/zkoch.github.io/blob/master/pmi-v2.md

Spec

https://docs.google.com/document/d/1izV4uC-tiRJG3JLooqY3YRLU22tYOsLTNq0P_InPJeE

Summary

For every payment method, a corresponding JSON manifest file describes how that method participates in the web payments ecosystem.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/YlMpaO-E2mE/-_GgiMiRCgAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, supported only where PaymentRequest API is available. Android WebView does not have PaymentRequest, because PaymentRequest requires UI, which Android WebView does not have. We plan to enable on Android first.

Demo link

1. Install BobPay on your test Android device.

2. Enable chrome://flags/#android-payment-apps in Chrome Canary > 59.0.3068.1.

3. Open https://rsolomakhin.github.io/pr/bob/.

Interoperability and Compatibility Risk

Web Payments WG voted to formally adopt this as a work item during our face to face meeting on 3/24.

Edge: No signals.

Firefox: Public support.

Samsung Browser: Public support.

Safari: No signals.

Web developers: Positive (Integration from multiple app providers).

Is this feature fully tested by web-platform-tests?

Not applicable.

OWP launch tracking bug

http://crbug.com/684655

Entry on the feature dashboard

https://www.chromestatus.com/feature/5716168929181696

[Domenic Denicola]

On Tuesday, April 11, 2017 at 2:37:14 PM UTC-4, Rouslan Solomakhin wrote:

Contact emails

rou...@chromium.org, zk...@chromium.org

Explainer

https://github.com/zkoch/zkoch.github.io/blob/master/pmi-v2.md

Spec

https://docs.google.com/document/d/1izV4uC-tiRJG3JLooqY3YRLU22tYOsLTNq0P_InPJeE

As briefly mentioned in the previous thread, I'm working with Rouslan and Zach to turn the non-platform-specific parts of this into a full spec that the web payments working group can adopt. My understanding is that they are all supportive of the general direction and the rough algorithms Rouslan has outlined, and that we'll move this to their GitHub shortly.

My work so far is at https://domenic.github.io/payment-method-manifest/ . As you can see it is mostly transcribing Zach's explainer and Rouslan's spec document into a more formal style. Along the way I encountered a number of edge-case ambiguities in Rouslan's spec, which I have called out as margin comments in his doc for now. (Things like: do we respect Content-Type for the manifest, or always use UTF-8; what happens if there are multiple Link headers; etc.) I do not believe these questions should affect interop in normal scenarios, although getting them straightened out is of course important in the medium-term, and that's what I'm doing this week.
 

[Rick Byers]

It's exciting to see Android Payment apps being close to shipping, and thank you for unifying the manifest story between web and android (see previous version of this intent)!

It looks like there's a TAG review request but no response yet (request 22 days old, but spec added just 5 days ago).  We don't generally block on getting TAG feedback.

You mention there's public support from Mozilla, can you provide a link for details?  In particular, is it support for the idea / use-case or for the specific proposal as now written in the spec?  Has someone from Mozilla reviewed the spec?  It looks like the only issues filed so for are from Domenic (and now me).

For Android payment apps in general, I agree - web-platform-tests is irrelevant.  But for the web payment manifest spec in particular that this intent is focused on I don't see why WPT wouldn't make sense.  From a naive skim of the spec it seems like you could have automated tests for most of the steps in the algorithm described by fetching and validating by checking to see if the specified web app manifest is fetched or not.  Then in the future when web app payment methods are supported, most of the rest of ingesting could be tested too.  Domenic, what are you thoughts on testing here?  Obviously what matters most is making it easier / more likely for the next implementation to be interoperable (not looking for busywork just for the sake of principle/process here).

Also can you please link to your existing implementation tests in chromium?

[zk...@google.com]

Hey Rick -

I think it's important to frame this work in the larger "web payments" story. This proposal isn't just about Android payment apps, though it is a blocker for doing so. This manifest proposal has long been talked about in the WG for making a link between an identifier (e.g. bobpay.com) and a corresponding "payment app", be it a native app or a web app. So it's a crucial piece of the whole 3P ecosystem story.

Up to now, the support from Mozilla has been to the idea and the explainer that I originally wrote. During out face to face in Chicago last month where two members of mozilla were present, there was consensus to adopt this as a formal work item (based on my explainer). MSFT was also present and were supportive, though their support of 3P payment apps is less clear.

The spec form itself is still very new. Domenic is working with Ian (W3C staff contact) to actually migrate the spec into the Web Payments WG repo. We'll be discussing it on the WG call tomorrow, but the plan is to go to FPWD along with the web-based payment app spec.

As for Chromium tests, here they are:

https://cs.chromium.org/chromium/src/components/payments/content/utility/payment_manifest_parser_unittest.cc
https://cs.chromium.org/chromium/src/components/payments/content/utility/fingerprint_parser_unittest.cc
https://cs.chromium.org/chromium/src/components/payments/content/payment_manifest_downloader_unittest.cc
https://cs.chromium.org/chromium/src/chrome/android/junit/src/org/chromium/chrome/browser/payments/PaymentManifestVerifierTest.java

Thanks,

Zach

[Domenic Denicola]

From: Rick Byers [mailto:rby...@chromium.org]

> For Android payment apps in general, I agree - web-platform-tests is irrelevant.  But for the web payment manifest spec in particular that this intent is focused on I don't see why WPT wouldn't make sense.  From a naive skim of the spec it seems like you could have automated tests for most of the steps in the algorithm described by https://domenic.github.io/payment-method-manifest/#fetch-pmm and https://domenic.github.io/payment-method-manifest/#validate-and-parse by checking to see if the specified web app manifest is fetched or not.  Then in the future when web app payment methods are supported, most of the rest of https://domenic.github.io/payment-method-manifest/#ingest could be tested too.  Domenic, what are you thoughts on testing here?  Obviously what matters most is making it easier / more likely for the next implementation to be interoperable (not looking for busywork just for the sake of principle/process here).

Unfortunately, testing isn't possible in the current design because it's not predictable when the whole process ("injesting") kicks off. Apparently Chrome plans to do it with a background process, and not in response to any particular web platform API.

If we had some way of kicking this off, we could test things as follows:

* Have the server validate the characteristics of the initial request
* Have the server respond with different Link-header responses (e.g. bad Link headers, good ones, good ones that 404, no Link header, multiple Link headers, 204 vs. 200, non-HTTPS URLs, etc.)
* Have the server validate the characteristics of the manifest request
* Have the server response with different manifest responses
* Validate whether the parsing was done correctly by seeing whether requests get made to the web app manifest URLs specified in the payment method manifest. (So for example, if any of the web app manifest URLs are not HTTPS, or any of supported_origins contain path components, then no requests should be made. Similarly, you should be able to supply strings like "https:example.com\manifest.json" and get a request made to "https://example.com/manifest.json", since the URL parser is invoked.)

[Rick Byers]

Thanks guys. Please file a bug to track getting some interop testing here eventually (eg. once we have a pattern for testing APIs, presumably we could easily rely on one to kick off the process, then test as below).

Zach, how did the WG call go?  Do you mention specifically your desire to ship according to the current spec?  As long as we've asked for review and there are no specific concerns, then I'd support shipping.  I assume we're talking M60 at this point, right?  That'll give us plenty of time to change things if other implementors start getting into this over the next month or to and hit some concern.

Rick

[mcac...@mozilla.com]

On Wednesday, April 19, 2017 at 1:40:49 PM UTC+10, Rick Byers wrote:

It's exciting to see Android Payment apps being close to shipping, and thank you for unifying the manifest story between web and android (see previous version of this intent)!

It looks like there's a TAG review request but no response yet (request 22 days old, but spec added just 5 days ago).  We don't generally block on getting TAG feedback.

You mention there's public support from Mozilla, can you provide a link for details?  In particular, is it support for the idea / use-case or for the specific proposal as now written in the spec?  Has someone from Mozilla reviewed the spec?  It looks like the only issues filed so for are from Domenic (and now me).

I have reviewed the spec and am supportive of the direction, idea, and use cases. Particularly like the way it integrates payment providers potentially as PWAs.   

Although we (Moz) don't have plans to implement at this point, we will be watching Blink's implementation with great interest - and I'll be actively working with the Editors moving the spec forward at the W3C (as well as making sure it integrates well with Web Manifest if anything additional is needed there!). 

[Zach Koch]

Hey all -

Thanks again for commenting on this thread. A few final thoughts:

* The number of "payment method providers" that would need to implement this spec is quite small (hundreds), and right now we're only working directly with a very small subset of those (<5) to test the waters. If we did run into a situation where we needed to change one of the fields, I think we could do so easily and without much (if any) interop risk. All of our early partners are aware that this spec can change and are okay with that.

* Getting this rolled out is critical for letting other players participate in the PR ecosystem, at least on Android. I'd really prefer to not go down the full proprietary route to enable android native apps. We've kept the footprint on this intentionally small to leave room for growth and more advanced use cases. 

* We'll continue to take this through the standards process in the WG, hopefully moving towards an FPWD in the (very) near future.

Happy to address any more questions or clarify anything that would make others feel more comfortable about giving this an LGTM. :)

Thanks,

Zach

[Rick Byers]

Yep I think the risk here is quite low, this should be easy to change post-ship.  I was waiting only for a response to this before LGTMing myself:

Thanks guys. Please file a bug to track getting some interop testing here eventually (eg. once we have a pattern for testing APIs, presumably we could easily rely on one to kick off the process, then test as below).

[Rouslan Solomakhin]

On Tue, May 2, 2017 at 10:55 AM, Rick Byers <rby...@chromium.org> wrote:

Thanks guys. Please file a bug to track getting some interop testing here eventually (eg. once we have a pattern for testing APIs, presumably we could easily rely on one to kick off the process, then test as below).

 

Filed http://crbug.com/717547.

[Rick Byers]

Thanks.  LGTM1

[Chris Harrelson]

LGTM2. Please come back with comments if it seems the WG will not move towards a FPWD soon due to any objections.

Thanks.  LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Zach Koch]

Great, thanks Rick and Chris. Chris, I will reach out ASAP if I feel like there are issues going to FPWD. From a timing standpoint, we're currently in a CfC to go to FPWD for web based payment apps (which we also intend to support). Then we'll move on to a CfC for PaymentRequest to go to CR. And then we'll move on to a CfC to go to FPWD for web method manifests. I'll report back on this thread whenever there is movement.

Thanks,

Zach

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Hi Zach,

That sounds great. Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jochen Eisinger]

lgtm3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.