Re: [w3c/webpayments-method-identifiers] Why URLs? (#9)

@annevk , @tabatkins thanks for joining this conversation, we're at a key point in figuring out this aspect of the payment API design so getting some fresh eyes is valuable.

We made the decision a while ago that we didn't want to use linked-data to express the data models used by the API and I think using URLs as identifiers is left over as a compromise from that debate.

The group is currently considering the following proposal [1] from @zkoch which changes a lot of what we had decided before and introduced the use of URNs as an alternative.

That said, there are some bootstrapping use cases that I believe @zkoch has in mind where using a URL is useful. In some instances there is only one payment app that can be used for the payment method and the URL can be used to "get" the payment app .

What's not yet clear is what "get" means because we are still defining the payment apps API. It could mean download, it could mean register, it could be a manifest etc.

@zkoch and @adrianba have pushed for the payment request API [2], payment apps API[3] and payment method identifiers spec[4] to be defined separately so in some cases we need to leave things "undefined" in one place while we figure out the details in another.

The group is not planning to progress any one of these specs to CR until they have all stabilized so our expectation is to get feedback from "the market" (i.e. people that may publish payment apps) before then and not leave this entirely open to interpretation (and therefor fragmentation).

[1] https://github.com/w3c/webpayments/blob/gh-pages/proposals/zach-pmi.md
[2] https://w3c.github.io/browser-payment-api/
[3] https://w3c.github.io/webpayments-payment-apps-api/
[4] https://w3c.github.io/webpayments-method-identifiers/

-- 
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/webpayments-method-identifiers/issues/9#issuecomment-239748759