Re: [w3c/browser-payment-api] editorial: clarify that payment handler data is converted (#536)

> On 25 May 2017, at 7:16 pm, Adrian Hope-Bailie <notifications@github.com> wrote:
> 
> @marcoscaceres and @domenic this was discussed at some length on a WG call a few weeks ago and has been a niggling issue since pretty much the first payment method spec was written.
> 
> My understanding from @rsolomakhin and @zkoch was that the data is treated as an opaque object and no validation is done against the IDL in the payment method spec.
> 

This is not correct. Please see:
https://github.com/w3c/webpayments-methods-card/pull/23

If we don't want IDL conversion, then why would we use WebIDL? 

WebIDL is not a data-structure definition language: it's a system for type coercion and moving things between c++ and js. Thus, we can't say on one hand "oh! It's Web IDL..." but then "it's an opaque blob". 

If we really don't want WebIDL, then we should not use it as the basis for BasicCardRequest.

> The browser passes the opaque data onto the payment handler which then parses it and uses it. If it is invalid then the response from the handler will indicate this.
> 

Again, this doesn't match what basic card spec says. 

> The basic-card payment method is "special" because the handler is internal to the browser but the implementation of how the data is validated shouldn't be exposed in the Payment Request spec.
> 

I'm sorry, but again you are mistaken. It's not special and it's not treated as special. Anything can act as a "basic-card" handler (including proprietary payment methods denoted by a URL) if registered to handle that type.

Also, if it's expected to be a basicCardRequest, then it must be treated as WebIDL or we should stop using WebIDL to represent BasicCardRequest. 

> Before you say: "But we need to look at the filters like supportedTypes before the data is passed to the handler". I know.
> 
I don't think this is where we were going. 

> In an ideal world each PaymentMethodData would have:
> 
> A set of identifiers it applies to
> A blob of opaque data that the browser ignores and simply passes to the handler
This seems like a massive security risk. Passing arbitrary data to apps that are expecting well-structured payment requests seems extremely bad. 

I don't think I would want to do that. 

> A set of filters used to filter handlers based on their capabilities

This doesn't match the spec. 

> The proposal to add a new member filters was rejected on the basis that Chrome have already deployed this and moving supportedTypes from data to filters is too disruptive.
> 
> Another way to solve this is that we are revisiting the idea of handlers defining a function which is presented with the opaque data and can respond true/false if they will be able to handle the payment.
> 

No, we are fine to work with the current structure: we just need to define some simple rules to avoid the insanity of arbitrary .data types (at least, that's my opinion). That's why I'm proposing having .data be converted to the PMI's data type (when not null). 

> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/536#issuecomment-303974223