Intent to Implement: 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

Summary

For every payment method, there must be a corresponding JSON manifest file describing how that method participates in the web payments ecosystem.

Motivation

• The ability to confirm the authenticity of payment apps associated with payment methods. Put another way, if a user installs a payment application associated with a proprietary payment method on their platform of choice, we want to verify that the app is who it claims to be.
• The ability for proprietary payment methods to control what other payment apps in the system are able to support their payment method.
• The ability for payment mediators to offer improved UX in cases where a users wants to use a payment method but doesn't have a necessary app installed (i.e. run-time or dynamic payment app registration/installation).

Interoperability risk

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: No signals

Compatibility risk

The feature extends the web app manifest with two custom fields: "sha256_cert_fingerprints" and "version" in the "related_applications" section with "platform": "play" identifier. If other specs have defined these fields, there would be a conflict. We're not aware of any such specs.

The feature adds a new type of HTTP Link header: rel="payment-method-manifest", which will need to be registered in a global index. This identifier is not yet taken and we're not aware of anyone planning to use it aside from us.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

No. Not supported on WebView, which does not have web payments feature due to lack of user interface. The other platforms are planned to be supported.

OWP launch tracking bug

http://crbug.com/684655

Link to entry on the Chrome Platform Status

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

Requesting approval to ship?

No.

[Dimitri Glazkov]

Thank you for driving this complex problem. I am excited about the concept of integrating various payment ecosystems in an extensible, specifiable way. I am also worried about the scope of the challenge, lack of interop signals and whether the shape of the API is congruent with the rest of the platform.

I would like for Ergonomics and Predictability ( +Dru Knox ) as well as Capabilities ( +Owen Campbell-Moore ) programs to track this work and help Rouslan and Zach strike the right balance between the three.

:DG<

[Owen Campbell-Moore]

cc Alex to take a look from a capabilities and manifest perspective

I don't see anything blocking here, but would like to see support from Alex on the approach before an I2S to ensure this slots in to the way we've been thinking about manifests

[Zach Koch]

Thanks, Dimitri! Domenic has been helping us with this as part of ergonomics program.

I actually think we have positive signals from edge and Firefox. Both we're present at the WG mtg and voted to adopt as formal work item.

Rouslan has submitted to TAG review as well.

[Dru Knox]

+Ian Kilpatrick and +Rick Byers as FYI

We're happy to be helpful however we can :) I imagine collaborating with Domenic and filing a TAG review are enough touch points for ergonomics, but let us know if there's more we can do!

For predictability, that's good to hear that Edge and Firefox are interested! Do we expect that either of them will have an implementation around the same time, or at least a public commitment to implementing? If not, are we able to place any of the testing work we do for this feature in web platform tests so that later implementations will be more easily interoperable?

Thanks!

-Dru

[Zach Koch]

For predictability, this is tied to if and win a browser will support third party payment apps. Edge has expressed interest, but no timeline. Firefox has expressed strong interest and is very vocal in the group. Since the payment method manifest is important important for this to work, I suspect they will have an implementation. Timelines, however, will not be aligned. We're much further along than they are, and to wait for them would be to delay us by many months. I'm happy to commit to putting our tests into web platform tests, but honestly, given the way this works, I'm not sure there's all that much that's testable without the full 3P flow working. Rouslan, is there something we could do here test wise?

-Zach

[Rouslan Solomakhin]

Does web platform test framework accept tests with manual instructions? The inherent user interaction requirements of the web payments API complicate fully automated testing.

On Mar 28, 2017 3:39 PM, "'Zach Koch' via blink-dev" <blin...@chromium.org> wrote:

For predictability, this is tied to if and win a browser will support third party payment apps. Edge has expressed interest, but no timeline. Firefox has expressed strong interest and is very vocal in the group. Since the payment method manifest is important important for this to work, I suspect they will have an implementation. Timelines, however, will not be aligned. We're much further along than they are, and to wait for them would be to delay us by many months. I'm happy to commit to putting our tests into web platform tests, but honestly, given the way this works, I'm not sure there's all that much that's testable without the full 3P flow working. Rouslan, is there something we could do here test wise?

-Zach

On Tue, Mar 28, 2017 at 12:32 PM Dru Knox <dk...@chromium.org> wrote:

+Ian Kilpatrick and +Rick Byers as FYI

We're happy to be helpful however we can :) I imagine collaborating with Domenic and filing a TAG review are enough touch points for ergonomics, but let us know if there's more we can do!

For predictability, that's good to hear that Edge and Firefox are interested! Do we expect that either of them will have an implementation around the same time, or at least a public commitment to implementing? If not, are we able to place any of the testing work we do for this feature in web platform tests so that later implementations will be more easily interoperable?

Thanks!

-Dru

On Tue, Mar 28, 2017 at 9:10 AM Zach Koch <zk...@google.com> wrote:

Thanks, Dimitri! Domenic has been helping us with this as part of ergonomics program.

I actually think we have positive signals from edge and Firefox. Both we're present at the WG mtg and voted to adopt as formal work item.

Rouslan has submitted to TAG review as well.

On Tue, Mar 28, 2017 at 08:45 Dimitri Glazkov <dgla...@chromium.org> wrote:

Thank you for driving this complex problem. I am excited about the concept of integrating various payment ecosystems in an extensible, specifiable way. I am also worried about the scope of the challenge, lack of interop signals and whether the shape of the API is congruent with the rest of the platform.

I would like for Ergonomics and Predictability ( +Dru Knox ) as well as Capabilities ( +Owen Campbell-Moore ) programs to track this work and help Rouslan and Zach strike the right balance between the three.

:DG<

On Mon, Mar 27, 2017 at 2:01 PM Rouslan Solomakhin <rou...@chromium.org> wrote:

Contact emails

rou...@chromium.org, zkoch@chromium.org

[Dru Knox]

@Zach - that shipping situation sounds fine!

+Philip Jägenstedt in case I say anything crazy, but I think it should be fine if many of your web platform tests need to be run manually. @Philip is that right?

On Tue, Mar 28, 2017 at 2:47 PM Rouslan Solomakhin <rou...@chromium.org> wrote:

Does web platform test framework accept tests with manual instructions? The inherent user interaction requirements of the web payments API complicate fully automated testing.

On Mar 28, 2017 3:39 PM, "'Zach Koch' via blink-dev" <blin...@chromium.org> wrote:

For predictability, this is tied to if and win a browser will support third party payment apps. Edge has expressed interest, but no timeline. Firefox has expressed strong interest and is very vocal in the group. Since the payment method manifest is important important for this to work, I suspect they will have an implementation. Timelines, however, will not be aligned. We're much further along than they are, and to wait for them would be to delay us by many months. I'm happy to commit to putting our tests into web platform tests, but honestly, given the way this works, I'm not sure there's all that much that's testable without the full 3P flow working. Rouslan, is there something we could do here test wise?

-Zach

On Tue, Mar 28, 2017 at 12:32 PM Dru Knox <dk...@chromium.org> wrote:

+Ian Kilpatrick and +Rick Byers as FYI

We're happy to be helpful however we can :) I imagine collaborating with Domenic and filing a TAG review are enough touch points for ergonomics, but let us know if there's more we can do!

For predictability, that's good to hear that Edge and Firefox are interested! Do we expect that either of them will have an implementation around the same time, or at least a public commitment to implementing? If not, are we able to place any of the testing work we do for this feature in web platform tests so that later implementations will be more easily interoperable?

Thanks!

-Dru

On Tue, Mar 28, 2017 at 9:10 AM Zach Koch <zk...@google.com> wrote:

Thanks, Dimitri! Domenic has been helping us with this as part of ergonomics program.

I actually think we have positive signals from edge and Firefox. Both we're present at the WG mtg and voted to adopt as formal work item.

Rouslan has submitted to TAG review as well.

On Tue, Mar 28, 2017 at 08:45 Dimitri Glazkov <dgla...@chromium.org> wrote:

Thank you for driving this complex problem. I am excited about the concept of integrating various payment ecosystems in an extensible, specifiable way. I am also worried about the scope of the challenge, lack of interop signals and whether the shape of the API is congruent with the rest of the platform.

I would like for Ergonomics and Predictability ( +Dru Knox ) as well as Capabilities ( +Owen Campbell-Moore ) programs to track this work and help Rouslan and Zach strike the right balance between the three.

:DG<

On Mon, Mar 27, 2017 at 2:01 PM Rouslan Solomakhin <rou...@chromium.org> wrote:

Contact emails

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

[Matt Giuca]

From the Web Manifest perspective, I think this needs some more discussion about the exact changes required to the manifest. (Happy to take this offline if you don't want to clutter the blink-dev thread.) Adding Marcos, the editor of the Manifest spec (though I think he's already been in contact with Web Payments standards effort so may already be aware).

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

Firstly, I'm not sure why Web Payments is going to mandate things specific to Play (i.e., the Android platform). How will this work on other platforms? Will you need to specify a native app for each platform? Will we need to specify additional metadata in other platforms for related_applications?

This proposes adding two new fields to the related_applications struct. This is already kind of a dumping ground for proprietary metadata (since the "id" field is at the discretion of the platform, and specific platforms are not part of the standard). But the manifest spec currently doesn't allow for arbitrary extra fields to be added by platform, so we should work out a way to do that in a future-proof way. Maybe we just say "any platform can add new proprietary fields", or maybe we want to add a standard-named field "meta", which is a dict that can contain arbitrary JSON content.

Lastly, it doesn't say what those two fields are used for. I assume sha256_cert_fingerprints is to verify that the Android app matches that fingerprint (so you can't just have a random side-loaded app with the same app ID). Would we be incorporating this checking into all the things that use related_applications? Or just web payments?

And what is version for? Minimum? Maximum? Is it supposed to match the Android version code? What if I want to define rules for a range of allowed versions? Is this going to break if a new version of the APK rolls out?

Matt

[Domenic Denicola]

Just chiming in here. Zach and I worked together on this to evolve it into something that fits well with the platform, and I think we’re both pretty happy with the result. The remaining questions are indeed around web app manifest usage. We’re both happy with it but it would indeed be good to:

 

• Run this design past Alex Russell and Marcos Caceres to make sure it conceptually fits with their vision for web app manifest
• Open a spec discussion about how to deal with adding fields to related_applications. Our assumption was that this was intended to be extensible over time, but indeed the spec right now is not, so we should be sure everyone is agreed on the exact extensibility mechanism.

 

I agree that the details of exactly how Chrome interprets each field in the "play" related_applications is unclear from just the linked document. And it is indeed something we should “specify”---although probably not in a web platform spec, but instead in a design doc or Chromium wiki page or somewhere in the play store developer guidelines. I believe Rouslan has a design doc he’s preparing.

 

Regarding web platform tests, we can indeed write manual web platform tests, although I’m not sure “web platform” tests is a good place for testing Android-specific integrations. It would be fine for the web payment app case though.

[Matt Giuca]

Update: I moved this train of thought (about Web App Manifest) to a GitHub issue: https://github.com/w3c/webpayments/issues/225

[Rouslan Solomakhin]

FYI, the Chicago face-to-face meeting notes for Web Payments have been published here: https://www.w3.org/2017/03/24-wpwg-minutes.

See the resolution to work on web payment manifests: RESOLUTION: To take up payment method manifest as a work item.

Contact emails

rou...@chromium.org, zkoch@chromium.org

[Rouslan Solomakhin]

Thank you, everyone, for an insightful conversation on github. Here's the new format:

  {

    "related_applications": [{
      "platform": "play",
      "id": "com.bobpay.app",
      "min_version": "1",
      "fingerprints": [{
        "type": "sha256_cert",
        "value": "59:5C:88:65:FF:C4:E8:20:CF:F7:3E:C8:64:D0:95:F0:06:19"
      }]
    }]
   }

I've updated the design doc and uploaded a patch for this format. The design doc includes the algorithms for processing the manifests. Domenic will write it up in a W3C style spec.