PaymentRequest: Introduce PaymentMethodData.

third_party/WebKit/public/platform/modules/payments/payment_request.mojom

Index: third_party/WebKit/public/platform/modules/payments/payment_request.mojom
diff --git a/third_party/WebKit/public/platform/modules/payments/payment_request.mojom b/third_party/WebKit/public/platform/modules/payments/payment_request.mojom
index 0c0b6be686b5b21851cf8bb58995d6c52f0c1f87..f5b1cced039b6fd084eeb93b26e2b36e4cea6156 100644
--- a/third_party/WebKit/public/platform/modules/payments/payment_request.mojom
+++ b/third_party/WebKit/public/platform/modules/payments/payment_request.mojom
@@ -87,21 +87,25 @@ struct PaymentOptions {
   bool request_shipping;
 };
 
+struct PaymentMethodData {
+  array<string> supported_methods;
+  // A JSON string built by the renderer from a JavaScript object that the
+  // merchant website provides. The renderer uses
+  // blink::JSONObject::toJSONString() to generate this string. The browser
+  // parses the string via base::JSONParser and passes a part of the JSON

[dcheng, 2016/06/04 02:32:36]

We cannot use JSONParser on untrusted data in the browser process. Is this
already happening today?

[please use gerrit instead, 2016/06/04 02:42:30]

Yes, it's happening here:

https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chr...

       JSONObject result;
        try {
            result = new JSONObject(stringifiedData);
        } catch (JSONException e) {
            // Payment method specific data should be a JSON object.
            return null;
        }

What's the correct course of action?

[dcheng, 2016/06/04 03:30:01]

Hmm. The comment implies base::JSONParser, which is a C++-based parser (and
that's definitely not OK): in C++, the preferred idiom is to use
//components/safe_json_parser. However, I'm not sure if the same concerns apply
to parsing purely in Java, which should be memory-safe. So maybe this is OK...
but I'd start a thread with security@chromium.org to confirm.

[Tom Sepez, 2016/06/06 16:15:37]

Yes, the C++ impl has this restriction which the java doesn't.

+  // object to the payment app, for example Android Pay. There's no one
+  // format for this object, so richer types cannot be used. A simple
+  // example:
+  //
+  // {"gateway": "stripe"}
+  string data;
+};
+
 interface PaymentRequest {
   SetClient(PaymentRequestClient client);
-  Show(array<string> supported_methods,
+  Show(array<PaymentMethodData> methodData,
        PaymentDetails details,
-       PaymentOptions options,
-       // A JSON string built by the renderer from a JavaScript object that the
-       // merchant website provides. The renderer uses
-       // blink::JSONObject::toJSONString() to generate this string. The browser
-       // parses the string via base::JSONParser and passes a part of the JSON
-       // object to the payment app, for example Android Pay. There's no one
-       // format for this object, so richer types cannot be used. A simple
-       // example:
-       //
-       // {"https://android.com/pay": {"gateway": "stripe"}}
-       string stringified_data);
+       PaymentOptions options);
   UpdateWith(PaymentDetails details);
   Abort();
   Complete(bool success);