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

> This is not correct. Please see:
> w3c/webpayments-methods-card#23

I already commented there. You are currently proposing a lot of spec changes with no context of the conversations that have already gone on relating to this topic. My request is to understand the reasons behind the current design before you merge this in and change it.

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

That is what I asked a long time ago. But at the time nobody could see the impact of the decision to stick with WebIDL so the issue went stale and was closed by @ianbjacobs 

Please have a look at: https://github.com/w3c/browser-payment-api/issues/132

> 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.

Exactly! Where were you when I logged the above issue over a year ago? :smile:

Note that the only arguments in that thread in favour of using Web IDL essentially boil down to: "It's a nice data-structure definition language".

>> 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.

I'm not sure I follow. The basic card spec says nothing about how the browser handles this data.

>> 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.

Actually I think you are wrong.

How would a "proprietary payment methods denoted by a URL" be registered to handle that type? There is no way for the browser to associate the URL with the type at run-time.

Basic card is unique as it's the only payment method for which browsers ship with built in handlers. That is not expected to be the case for all payment methods that are published by the WG (whether they use WebIDL or not). If it is then that is news to me and we should all agree that is the intent and understand the implications of that.

My assumption to this point has been the only justification for using WebIDL in the basic card spec is because there is a built in handler for it. I.e. it will allow browser vendors to generate bindings between the submitted JS and the code that processes the request (the internal handler) .

> 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.

I think we should stop using WebIDL, I'm yet to hear a good argument why we are besides that it's easy to write specs with in ReSpec. As I suggested in that issue I think we should follow the data modeling language used for web app manifest.

> 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.

So are you suggesting that browsers will not accept any new payment methods in the ecosystem for which they haven't shipped built-in data validation?

That's the opposite of the goal of this system. 

>> A set of filters used to filter handlers based on their capabilities
>This doesn't match the spec.

Correct, like I said it was a proposal that was rejected because the implementation that have shipped don't work that way.

> 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).

That simply won't work. The whole point of `.data` is that anyone can invent a new payment method with whatever data model they want in there. If they need browsers to ship new data validation for it then the whole design is broken.

-- 
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-303997650