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

> The data type for URL identifiers is object. For standardized short strings it is a WebIDL dictionary.

Wrong. That is what you think it is because you haven't been part of any of the conversations on the WG calls where there have been numerous assurances made that, even for a new short-string based payment method, the only implementation burden on browsers is adding that short string to an enum of known identifiers.

>  The reason we are talking past each other is because we are not using code

Actually I think it's because you joined this conversation about a year late and haven't attended a single WG call (where this issue has been discussed at length). I appreciate that the timezone is a challenge but perhaps it would be prudent to approach the online discussion a little more patiently.

To illustrate (and prove that I'm serious, because apparently that's also important), here is a code example:
  1. It has to be a short-string because there is no authority to host a URL for Bitcoin. 
  2. BIP 70 (the mechanism for doing Bitcoin payments) is designed to be extensible so its unlikely that each new version is going to be supported by a new revision of a payment method specification published by the WG to update the WebIDL.

```javascript
const methodData = [{
  supportedMethods: ["bitcoin"],
  data: { 
    payment_details_version: 1, 
    pki_type: "none", 
    pki_data: "",
    serialized_payment_details: "F1AABE5B69...",
    signature: "1FE56C09..."
  }
};
```

The WG has been tracking Bitcoin's BIP 70 as a potential payment method for some time, we mapped out the flow here: https://github.com/w3c/webpayments-flows/tree/gh-pages/PaymentFlows/Bitcoin
For the full explanation: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

While I appreciate that a web, centralized around a small number of browsers that can quickly confer on new developments, is a comfortable position from which to design this system, that's not the world many of us are coming from in payments. 

A truly decentralized payment method has no authority so it can't use a URL as a payment method identifier. The only mechanism therefor is the short-string identifier but that can't only be available if that implies browsers must implement a full request/response data validation and keep it up to date.

Hope that makes things a bit clearer.

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