W3C

Web Payments Working Group Teleconference

18 Feb 2016

See also: IRC log

Attendees

Present
dlongley, Rouslan, zkoch, Manu, dlehn, AdrianHB, nicktr, VincentK, Ian, shepazu, ShaneM
Regrets
Chair
Nick Telford-Reed
Scribe
Ian

Contents


<scribe> scribe: Ian

Preparing for issue discussion at FTF meeting

Nick: Thanks, manu, for starting the conversation

<nicktr> https://github.com/w3c/webpayments/issues/89

<Zakim> manu, you wanted to note AdrianB's issue.

manu: Chatted with AdrianBA yesterday
... he has one to add
... We should do technical things first (before strategic or operations)
... I agree with Zach we should deal with the hard issues where nuance is important
... first issue is are we doing low level, or both low and higher level?
... there's also a question around shipping address...I think that there is agreement among editors to support the shipping use case.
... question around payment app registration. What is an app? How are they installed?
... answering that question will then help us answer question about how to communicate with payment apps.
... Question "5" will be about "how will we do things like feature detection" in API (e.g., does it support billing address)?
... question 6 is about use of events/promises...what is the interaction pattern (if we do a checkout API)

<Zakim> AdrianHB, you wanted to discuss Zach's comment as a first step

AdrianHB: We should order these questions so we can build on them
... manu said "there is consensus among editors to support shipping." So I think we should put that to the group and move on from there, accepting that as a requirement.
... I think we need to put pins in some requirements
... I think we have a spectrum of options (from "just payment" to checkout)...and in the middle we have "everything in one API but with some additional features"
... let's nail down the requirements and then answer some of the questions on the back of that

IJ: Let's tease out requirements as AHB has started to do

<Zakim> manu, you wanted to note AdrianB's concerns about having discussions at too high of a level.

IJ: e.g., developer usability

Manu: I agree that some conversations are happening at "too high a level"...

<adrianba> i'm fine with making sure we agree on what problems we want to try to solve

manu: It may be hard for us to come to ground on requirements quickly at FTF meeting

<adrianba> my criticism was more about arguments about the type of technology we might use

Manu: The specs have developer code we can look at

(as far as comparing code as a way to pick most dev-friendly design)

<AdrianHB> +1 to getting agreement on the goals/requirements up front (and quickly if we can)

IJ: You need to articulate the requirement (e.g,. "performance") before making some design decisions.

<Zakim> AdrianHB, you wanted to request that we see some example developer code

AdrianHB: Regarding developer code, one of the requirements we should consider in how we look at our approaches is: what will it look like when a developer writes a site that uses this API?
... we should take common use cases and write the code that a developer would have to write to use the APIs...and compare them
... this suggestion from W3C staff
... it would be good to have such examples going into the meeting...or can choose them on day one
... On the question of "what is a payment app"...I think that we are not all in agreement about how an app will materialize...
... e.g., is it a native app on mobile?
... or a native app on desktop or iframe or browser extension or service worker?
... we should talk about what that thing is going to be

<Zakim> manu, you wanted to ask if he should try restating the questions as questions around goals?

Manu: we could frame questions about goals

Some ideas:

<dlongley> https://github.com/w3c/webpayments/issues/89#issuecomment-185819392 <-- i put some suggestions here for high-level goals w/respect to APIs

Nick: Helpful for people to express what they think the goals are

adrianhb: I think chairs need to structure discussion (which you've touched on on your thread)
... we need to do more work
... I expect we will need to iterate
... It hasn't been mentioned yet, but we will need to go back and look at horizontal review stuff
... we should iterate through those requirements quickly (security, privacy, accessibility)
... and how our design decisions to date reflect those requirements
... e.g., not sharing payment method information with merchant

<mountainhippo> ack

IJ: Personally I think that those topics are really important but our decisions right now seem unrelated; but later let's absolutely add sections to the spec on various considerations.

<Zakim> manu, you wanted to agree with Ian, we may want to cover this stuff if we start having awkward silences on day 2

(e.g., privacy, security, i18n, accessibility)

+1 to not "forgetting" to do these things

[Strategic questions]

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


.e.g., what data do we have to back up that API choice will reduce cart abandonment

[IJ thinks we will not get some data until later]

Manu: Another topic is how to extend API without breaking implementations?

nick: Flows help us ground discussion in real payments

<Zakim> manu, you wanted to note that we may want to have a spec update at the beginning of the meeting.

manu: I would like the editors to frame "where we our with specs" when we start meeting.
... some people may not be able to read specs before meeting

IJ: I would rather use time for looking at code side-by-side rather than edit history

nick: We will have new participatns
... although I am not advocating a full edit history, I think there is value in:

* Reiterating how to prepare for the meeting (which materials available)

* Introducing people to the specs

nick: so I support a (not long) contextualization

<Zakim> manu, you wanted to not that we don't have demos for some of this stuff, only spec code examples and to note that he only meant introducing people to the specs.

(IJ still feels it would be important to look at code as a better way to understand the specs)

manu: I did not mean edit history...I meant intro to the spec

<mountainhippo> +1 to manu's suggestion

manu: we are talking about 3 specs

IJ: I can live with 15 mins to intro 3 specs

adrianHB: Manu and Ian surfaced something we should clarify

<Zakim> AdrianHB, you wanted to clarify the focus for the f2f

adrianHB: that we will focus on the browser API
... we will consider then how that work affects other specs we've talked about doing
... but the focus for this FTF is to get us to a FPWD of browser spec

<Zakim> manu, you wanted to say he's not comfortable, but doesn't feel there is support to look at other specs.

manu: I am not comfortable that we are pushing off other specs but understand people want to focus on browser API

<ShaneM> +1 to getting something done. whatever that something is. We need "points on the board"

manu: if we have extra time we can talk about HTTP API and others

<Zakim> mountainhippo, you wanted to note that he is going to bring a short demo of HTTP api use case and some docs

nick: I will bring a short demo of an HTTP API
... something that might be useful for HTTP API discussions to come

<AdrianHB> +1 to other API discussions if we have time (even if the editors break out for a short session)

[Operational topics]

+1 to CG discussion at AC meeting as AHB suggested

Manu: I think that there are questions like who the editors are and mechanics of getting specs into repo
... I am concerns about transparency in this group

-1 to CG discussion at our FTF meeting

<VincentK> * VincentK has to leave for another meeting

I *totally* agree technical work needs to be done in public.

And having access to all the information avoids silos of understanding

nick: I take Manu's concerns seriously.

<manu> +1 to that - we all want the same thing

<dlongley> +1

<manu> we haven't been executing in that way.

Totally ready to blame NickTR to speed things up

Issues

<manu> https://github.com/w3c/webpayments/issues/89#issuecomment-185171992

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

<manu> +1 this is an important point to discuss

<AdrianHB> +1

matt: We have too many places where agenda is being developed

(Yes, we need to consolidate)

<manu> +1 to consolidate

<manu> (someone needs to take an action on that)

(I hear AHB will drive that)

Testing

Shane: With my test czar hat on...very important but haven't done anything yet since nothing to test yet.

<Zakim> ShaneM, you wanted to mention that we need to start making progress on testing too

<Zakim> zkoch, you wanted to mention some quick logistical things about FTF at google

FTF logistics

Zach: Remember elevator story ... get there before 9am or you will need to check in

shepazu: Parking?

zkoch: Nothing special; public parking

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/18 18:02:15 $