Re: [w3ctag/spec-reviews] Web Payments Working Group Specifications (#152)

So I looked at the [Payment Method Identifiers](https://w3c.github.io/webpayments-method-identifiers/) spec today as well, and filed a bunch of issues (linked just above).  But some other thoughts that I haven't yet been able to turn into a spec issue against the spec repository, partly because I don't yet understand what the suite of specs as a whole is doing and where the parts not yet filled in are going to go (so I'd welcome feedback to better target or to assuage these concerns):

It's not clear to me whether https://github.com/w3c/webpayments-method-identifiers/issues/9#issuecomment-246436501 reflects a group decision that is still partly pending editing, whether some of that is reflected in the two issues in [3. URLs as Payment Method Identifiers](https://w3c.github.io/webpayments-method-identifiers/#urls-as-payment-method-identifiers) (and if so how those issues will be resolved), or whether the spec is out of date relative to that discussion.  But I'm concerned about some of the issues raised there, particularly about whether the URLs point to something that has the information needed for a web client to actually interact with the payment system and present a user interface for it.  Which is I guess a bigger issue that I should probably bring up:


So I'm going to try to speak here with my TAG hat on and my Mozilla hat off.  TAG members are not supposed to be representing their employers interests, and I think what I'm saying here does disagree in some ways with what I would say as Mozilla's AC Rep.  (Obviously, even with "hat off" I'm still speaking based on what I've learned in my own experiences.)

One of the things that always attracted me to the Web was that it was an open platform.  The specifications were publicly accessible and freely implementable, which meant that one of the Web's strengths was that newcomers could try to improve pieces of the system, whether by adding or improving aspects of the Web, or by bringing the Web to a new platform without permission from anyone else.

There have been a whole bunch of things recently that have moved (quite quickly) towards adding things to the Web that tie big external pieces of technology into the Web in ways that put these characteristics at risk.

EME was probably the first of this bunch (separated by a bit from the others), but was done as part of making a tradeoff between the addition of one external piece of technology (EME) and the removal of another larger one (plugins).  This tradeoff had some advantages (sandboxing leading to much less security and privacy risk, smaller and largely-fixed feature set rather than open-ended one) and some disadvantages (no published API that allows new browsers to enter the market by using existing plugins, although this was only the case for plugins on existing operating systems, giving a somewhat more official blessing to DRM).

We recently saw the Remote Playback API, which led to the concerns that the TAG documented in https://github.com/w3c/remote-playback/issues/74#issue-220897112 .  (That case is perhaps more clear-cut because it doesn't cross industries as widely.)  I worry that this comment may apply to payment methods as well, and particularly to the ability to get in to systems more secure than card payment.

That is, I'm concerned that the payments specifications may have the same problem:  that by being too much glue to other systems and not enough of its own technology, they may tie Web content to the use of payment methods that are specific to an operating system, a browser, or both, or ties browsers to payment systems, in ways that inhibit the ability for newcomers to build browsers or bring browsers to new operating systems.

But again, I still don't feel I understand what's going on with the set of specs as a whole.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/152#issuecomment-293298243