Straighten out the payment method data flow

[domenic]

This fixes #338 and helps with #307 by stating more explicitly how the data member of PaymentMethodDetails is serialized to a string, stored, and later passed to the appropriate payment app.

Along the way, this fixes #354.

This does not completely fix #307, as the problematic JSON-serializable concept is still used for PaymentDetailsModifier (and is still not used by any part of the processing model; that's #346).

---

This is on top of #374 and should be merged only after that is.

If this looks correct, then to clarify how the basic card spec actually interacts with the main spec, we'll edit the basic card spec to say:

• Payment apps for basic card must determine if they support the requested payment method by first performing steps equivalent to parsing the supplied data using JSON.parse, then converting the resulting object to a BasicCardRequest dictionary, and inspecting the results.
• Payment apps for basic card must supply a result object back to the payment request flow in the form of a BasicCardResponse dictionary.

This will then solve w3c/payment-method-basic-card#20.

[adrianba]

I think this is generally fine but I'd prefer that we don't require data be passed in JSON string form. In our implementation we might present the data to apps already "deserialized" so it won't look like a string to them. I think the spec ought not be so explicit in saying it will be that string form - an equivalent should also be okay. We likely to use an alternative RPC mechanism that isn't a string and this should be acceptable.

[domenic]

Well, in general,

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent.

The important part is that JSON.stringify is performed at a very particular point in the algorithm.

[adrianba]

Well, in general,

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent.

The important part is that JSON.stringify is performed at a very particular point in the algorithm.

That's true, but it looks like the end result here is passing off a JSON string to a payment app.

[domenic]

How would that be observably any different from passing along some other serialization format derived from or containing the equivalent information to that JSON string?

[adrianba]

My concern is that the way this is written implies that that Payment App spec will expect a JSON string.

[domenic]

Yes, I think it would. It can then transform that JSON string into whatever format is most appropriate for it.

What other serializable data structure would you expect a spec to be able to deal in?

[adrianba]

I think the transport format should be an implementation detail as long as it isn't exposed. The current language leaves ambiguous whether it would be exposed. I would like to close down that ambiguity.

We discussed in the editors call just now and Marcos is reviewing.

[domenic]

Can you explain how it's ambiguous that it would be exposed? No spec exposes it except to other specs.

We need a well-defined transport format for specs to be able to talk to each other. Specifying an entirely new one seems superfluous.

[marcoscaceres]

I think this is fine for now - but we should have at least 1 base thing here (probably "basic-card").

[domenic]

I'm not sure I completely understand the ask here, but maybe this is the same as my "If this looks correct, then to clarify how the basic card spec actually interacts with the main spec, we'll edit the basic card spec to say:" from the PR's OP?

[marcoscaceres]

Small conflicts

[domenic]

Rebased with conflicts fixed.