What are the WPWG February 2016 face-to-face prioritized issues

[msporny]

This is an attempt to come up with a prioritized set of issues for the upcoming WPWG February 2016 face-to-face. The goal is to focus on issues that will get the group to a FPWD of the browser APIs by the end of March 2016.

Please list the issues, in priority order, that you feel are most important for the group to reach the March 2016 FPWD goal. The authors/editors of the Browser API specifications (@zkoch, @adrianba, @dlongley, @msporny) should certainly chime in as should any WG member that feels strongly about the issues that need to be dealt with to reach the March 2016 FPWD goal.

[msporny]

Here is my prioritized list of questions that probably need to be answered for us to get to a March 2016 FPWD goal:

Technical

1. Are we doing a high-level API (Checkout) AND a low-level API (Payment)? Or just a high-level API (Checkout)?
2. What if we get the Checkout API wrong? Should we specify APIs to get shipping address, request payment, and polyfill the rest until we can figure out the best way to do it?
3. Are we going to support "payment app" registration via the API or is it going to remain unspecified?
4. How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgement?
5. What are the combinatorial issues with adding the ability to "get more payer information" to the Checkout API?
6. Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.

Strategic

1. What are the goals of the Checkout API? What are the goals of the Payment API? Are they different?
2. What data do we have to study in order to see if the APIs will meet their goals?
3. How does one extend the type of information you can ask for via the Checkout API? For example, is a WG required to add a Billing Address request to the API?

Operational

1. Who are the editors of the WG specs going to be and when are we putting the specs into the WG repo?
2. How are we going to fix the transparency issues and backchannel discussions in the group?
3. Is the "incubate the specs in a CG" model working?

[adrianhopebailie]

Thanks @msporny.

@mattsaxon started documenting "Differences between the proposals" a while back on the wiki, which wasn't a bad basis for coming up with some good discussion material for the face-to-face.

What do you think of using the issue tracker to capture these in the same way we have been doing for calls? There is already a "Resolve at F2F" milestone?

We can use this thread to brainstorm but when there is a concrete proposal let's capture it as such and allow the group to discuss it.

On that note, are there any of our existing proposals/questions that we should tag for the F2F?

[adrianhopebailie]

I mean to link to the wiki page: https://github.com/w3c/webpayments/wiki/Issue-Summary
I changed it from a comparison of the proposals to a high level issue summary.
I was capturing the various proposals and for and against shipping address capture which provides an idea of the format I was experimenting with.

[ianbjacobs]

@msporny,

Thanks for writing up your list. (I also hope Adrian Bateman and/or Zach do so.) Here are a few comments.

Technical

Are we doing a high-level API (Checkout) AND a low-level API (Payment)? Or just a high-level API (Checkout)?

That's a good question. For the moment, I'm not sure which use cases
in our current charter require the checkout API. There is a smaller
question of whether shipping address should be in or out of the payment
API. But after shipping address, what are the topics in scope for our
charter that the checkout API would cover?

What if we get the Checkout API wrong? Should we specify APIs to get shipping address, request payment, and polyfill the rest until we can figure out the best way to do it?

I don't think "what if we get something wrong" is a question we
need to focus on. I do agree there is a question of whether
shipping addres is in the payment API.

Are we going to support "payment app" registration via the API
or is it going to remain unspecified?

Registration is in scope of our charter. We have not discussed much
lately. I agree we need to.

How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgement?

That question sounds like a reference to the HTTP API. Right now there is no question we will do an HTTP API per our charter. We've postponed expectations about FPWD until 1 June. Is there something new in your question?

What are the combinatorial issues with adding the ability to "get more payer information" to the Checkout API?

I'm not sure to understand the question.

Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.

Agree that's an important question.

Strategic

What are the goals of the Checkout API? What are the goals of the Payment API? Are they different?

That's a reasonable question (per my comment above that I'm not
sure yet what the goals of the Checkout API are).

What data do we have to study in order to see if the APIs will meet their goals?

I propose these questions instead:

• What criteria will we use to make decisions about API direction? (cf our agenda for some)
• How will we get implementation experience?

How does one extend the type of information you can ask for via the Checkout API? For example, is a WG required to add a Billing Address request to the API?

I'm not sure what that question means. It depends on the question about
goals for that API (and also what's in scope for this WG).

Operational

Who are the editors of the WG specs going to be and when are we putting the specs into the WG repo?

Personally, I hope that we make a WG decision to take up the work as of the end of the FTF meeting. Our decision will affect who the editors will be.

[adrianhopebailie]

• Are we doing a high-level API (Checkout) AND a low-level API (Payment)? Or just a high-level API (Checkout)?

I think this is a good question but will be implicitly answered by this:

• What are the goals of the Checkout API? What are the goals of the Payment API? Are they different?

There is a strong desire from the browser vendors to "streamline the checkout experience" including gathering shipping data. (Please keep me honest here @adrianba, @zkoch, @bifurcation, @nickjshearer, @haavardmolland)

The goals in our charter go beyond this which suggests other flows are needed for other use cases or a low level payment API is needed that can be used to compose other flows.

The paymentRequest API takes a different approach to the checkout API on how these two functions are exposed and we should decide which we like most.

• Are we going to support "payment app" registration via the API or is it going to remain unspecified?

+1 - We need to start defining this. The CG proposal does address registration but I think we need to answer the following question before we can tackle registration:

• How will payment apps be implemented?

Which you partly address in the question:

• How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgement?

I also think we need to decide if there is such a thing as a Web-based payment app or if we're advocating for something like a sandboxed ServiceWorker? Hence the broader question above.

• Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.

I think we're making good progress on this in the list but don't believe we can close this till we've tried to implement the UI and understood the constraints properly. To my mind there is still too much hand waving about flow of control and inter-dependancies between steps.

• How does one extend the type of information you can ask for via the Checkout API? For example, is a WG required to add a Billing Address request to the API?

We should consider this in the finer details of the design. The flexibility that the checkout API offers is my preference but we need to consider situations where a call like request('billingAddress') may be made in future in a browser that only supports returning the shipping address. i.e. Versioning

Who are the editors of the WG specs going to be and when are we putting the specs into the WG repo?

Editors chosen and WG spec in a W3C repo soon after the face to face would be my hope.

How are we going to fix the transparency issues and backchannel discussions in the group?

Are there transparency issues? There's no restriction on people have sidebars but any impact those have on the deliverables need to still be made via a proposal that gets group consensus. Think this will be related to the choice of editors and work process we define for the specs.

Is the "incubate the specs in a CG" model working?

Don't think we should tackle this at the F2F. It's a topic for the AC.

[mattsaxon]

I would like to add either to the agenda or as an issue the following;

Adoption/Transition of the API
a. Finding the relevant payment application
b. If merchant can prefer one payment app over another if there are multiple apps that can perform the same method
b. Fall-back methods when no such app exists (or the shopper doesn't want to sign-up to the terms & conditions)
c. What our expectation is for situations where the merchant wants to override the 1.0 implementations to better control the flow

[rsolomakhin]

There is a strong desire from the browser vendors to "streamline the checkout experience" including gathering shipping data. (Please keep me honest here...

That is correct.

[rsolomakhin]

We should consider this in the finer details of the design. The flexibility that the checkout API offers is my preference but we need to consider situations where a call like request('billingAddress') may be made in future in a browser that only supports returning the shipping address. i.e. Versioning

Instead of versioning, I would prefer feature detection. For example:

if (checkout.supports('billingAddress')) {
  checkout.request('billingAddress');
}

or:

if (checkout.requestBillingAddress) {
  checkout.requestBillingAddress();
}

[msporny]

What do you think of using the issue tracker to capture these in the same way we have been doing
for calls? There is already a "Resolve at F2F" milestone?

+1, although I don't have the time to triage, unfortunately. I was just trying to set this issue up as a big dumping ground for prioritized issues that are important for folks - it's up to the chairs/staff to organize them into something they think would be the most efficient wrt. making progress.

On that note, are there any of our existing proposals/questions that we should tag for the F2F?

I did a scan through them and there is some overlap here and there. I'll try to do another scan before the F2F, but honestly almost every hour of my awake time is allocated from now until the face-to-face.

[zkoch]

I think Manu has hit on most of the key questions that will need to be addressed. My hope is that we address what I see as the core issue as soon in the FTF as possible: What API direction are we going to move forward with?

There are a bunch of interesting architectural questions that have been brought up (promises, events, etc) that I think are much easier discussed in person with a whiteboard handy, but are only possible if we find agreement on a fundamental API direction.

I'm slightly less concerned with the operational issues Manu mentioned, not because I don't think they're important, but because they're easier addressed via phone calls and email. I'd rather spend the face time discussing the more nuanced issues.

[dlongley]

I think we need to discuss (though I personally won't be present):

What are the goals of the APIs?

I think we have at least two separate goals:

1. Making it possible for users to install Payment Apps and allow merchants to pass extensible payment request messages to them through the user agent to get consent to pay/perform payments. Allow innovation and competition at the end points (outside the user agent) and by payment networks.
2. Improving the checkout experience for common online commerce. Allow innovation and competition by user agents.

[rsolomakhin]

@dlongley, I think that both of your goals can be achieved in a single API.

[nickjshearer]

Same for me - I guess I don't see why those goals are necessarily separate. They seem intertwined, without Goal 1 it is difficult to implement Goal 2, and without Goal 2 there is less incentive to implement Goal 1.

I agree with Zach that we should resolve the approach and pick one, rather than keep going down two paths.

[dlongley]

@rsolomakhin,

I think that both of your goals can be achieved in a single API.

I think it's possible as well. But there is a question of whether or not we should solve it that way. And that (at least partially) has to do with whether we should create a high-level API that is composed of lower-level APIs or just one high-level API that has flags to turn things off/on. With lower-level APIs (or at least that design in mind), there is more room for merchants to access new things in the Web Platform using flows that work for them (potentially more innovation and broader adoption/reuse). If we do a high-level API without a composable design in mind, and it ends up only working for some people, we may end up having to redo a lot of work in the future in order to create something that works for everyone else.