Re: [Agenda] 31 Jan 2017 Payment Apps task force call

On 1/30/17 12:58, Ian Jacobs wrote:
> Proposed way forward in light of recent threads
>
> I have endeavored to synthesize recent discussions and would like to see
> whether we can get to agreement on a model for payment apps:
>   https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
>
> That proposal includes:
>
>  • A proposed way forward
>  • Issues where we have not yet converged (and commentary on current discussion)
>  • Suggested resolutions to issues (based on point 1.)
>
> Even if there is not yet agreement on those points, I hope that the proposal
> helps frame the discussion.

Thanks, Ian! I have some initial thoughts on this proposal; some aspects 
of it are new to me, though, and may require additional consideration. 
As my general statement regarding the priority of constituencies drew 
fire on the call last week, I have highlighted the two specific 
proposals that I believe are inverting these priorities.

*Identity*: This is a radical departure in the meaning of "payment app." 
For avoidance of doubt, I would propose ejecting the name "payment app" 
altogether (since we're basically shutting down that concept if we adopt 
this definition), and instead call these "payment web apps."  I have 
also heard non-trivial objections from people regarding the implicit 
limitation here: this would limit a single origin from appearing in the 
"list of things that users select" more than once. If we can get 
explicit payment provider buy-on in this restriction, I'm fine; 
otherwise, I have serious concerns that we're going down a path that 
will be cleaner in the sense of theoretical purity, but fail to meet 
author (merchant and/or payment provider) needs.

*Registration*: This is a bit unclear. The notion here is that a service 
worker makes itself part of a payment web app by registering for 
payment-related events?

*Payment App Code*: I have concerns with how we're dealing with 
"canMakePayment" in this context, as this seems to be (or have 
substantial overlap with) the filter function we describe below. I think 
its purpose needs to be made clearer; and, in particular, I think we 
need to keep in mind the well-established privacy and business concerns 
that arise from activating service workers associated with payment web 
apps other than the one selected by the user.

*Recommended Payment Apps*: we would need a more concrete proposal about 
how one maps from origin to "the place one goes to install a payment web 
app." The current design has answers for that. It's not clear how the 
new design accommodates it.

*Handling Payment Requests*: I think this is largely fine, modulo my 
concerns on Identity.

*Relation to Payment Method Manifest Files*: This seems correct.

*Information Provided to the Payment App*: This is a much deeper 
philosophical problem than the text in the proposal captures. See 
<https://github.com/w3c/webpayments-payment-apps-api/issues/99#issuecomment-276227625>. 
This is another place that I think the recent proposal puts theoretical 
purity above user needs.

*Filters*: I think this is at least partly on me to sketch out how a 
configuration-based approach would look so that people can compare them 
with each other. I'm 100% certain that an event-based approach lacks the 
privacy characteristics we need.

*Opening Windows*: I think everyone has been pulling in the direction of 
"put a new method on the event" at this point. I would expect this to be 
pretty uncontroversial.

*Setting Payment Method Information*: I think Matthieu is off in the 
weeds here. People who can't keep their state straight can always just 
delete all methods and set new ones. This complaint is similar to saying 
"I don't like the fact that we can insert and remove things from the DOM 
because it requires applications to keep track of what it currently 
looks like."

*Icons and Labels for Payment Methods, Options*: I have serious and 
extreme concerns about even mentioning

*Issue 48 resolution*: We can't close this until we have a clear 
proposal about how we get from whatever a merchant suggests to the page 
that actually installs an app.

*Issue 74 resolution*: It's not clear what this proposal envisions if 
the recommended payment app is not installed. I'm certain many people 
have in mind that this is part of the bootstrapping mechanism for the 
whole payments ecosystem. What happens for already-installed apps is 
far, far less important, and not what we should be focusing on right now.

*Issues 79 through 94*: No comment; proposed resolutions look fine.

*Issue 98*: I repeat my earlier assertion that this has devolved into a 
terminology issue. See "Identity," above.


-- 
Adam Roach
Principal Engineer, Mozilla