W3C

Web Payments Working Group Teleconference

06 Oct 2016

Agenda

See also: IRC log

Attendees

Present
Ian, AdrianHB, Pascal, Manu, adamR, MaheshK, zkoch, nicktr, AndreL, dezell, AdrianBa, Ken, dlongley, ShaneM, Shane
Regrets
Roy
Chair
Nick
Scribe
Ian

Contents


-> https://github.com/w3c/webpayments/wiki/Agenda-20161006 Agenda

<scribe> scribe: Ian

-> https://github.com/w3c/webpayments/wiki/Agenda-20161006 Agenda

Post TPAC priorities

Close issues on PR API and PMI (etc.) (led by Editors). What issues require WG attention over the next few weeks?

Review and advance payment apps API to FPWD (led by Payment Apps task force)

Push payments proposal (led by Roy)

Advance test suite (led by Shane)

<manu> Ian: [Reviews priorities listed in Agenda]

<Zakim> manu, you wanted to note issues raised w/ Rouslan/Zach at F2F and more (minor) issues forthcoming - only one sizeable one - digital signatures.

manu: We reviewed PR API....
... before the FTF and I chatted with Rouslan about some concerns
... we have a decent list of mostly editorial/minor issues
... one sizable issue around the use of digital signatures
... Rouslan and I worked out something but we need to get it into the issue tracker.
... and one other issue related to algorithms.
... we are hoping to do PRs on editorial issues in the next week
... so the only major concern we have after review is around digital signatures

<zkoch> ASAP

IJ: Editors, any preferred timing re: issues?

<zkoch> :)

zkoch: ASAP

AdrianHB: Let's set a target date for issues

<manu> Ian: I think having a date is good, but from a broader process perspective, we need to solicit wide review with groups from whom we have dependencies.

<adrianba> not too worried about editorial issues - they can be added at any time - need to prioritise normative changes

<manu> agreed, editorial is less of a concern - just wanted to give the editors a heads up that we have some coming their way and want to do PRs for them, but having trouble finding the time.

<manu> Ian: We have gotten some review, but need more.

<Zakim> AdrianHB, you wanted to propose that at a minimum we set a date in the near future to publish a new revision that we send for wide review

IJ: We have a process requirement to get wide review...need to determine when we are ready to call for that

AdrianHB: So let's aim for a publication date for a spec to get wide review

<adrianba> we can publish at any time

IJ: Editors, got a date when you'd like to have a draft and call for wide review

<manu> Ian: Editor's, what's the date for a draft for wide review?

<manu> Ian: Are you saying we shouldn't ask for wide review before we get Payment Apps in place? Or are you saying we need wide review independent of Payment Apps?

nicktr: Surely we would not want to go to wide review if we think there are changes to come out of payment apps
... so I think they are linked.

<Zakim> manu, you wanted to note that wide review is fine, even if we think there might be normative changes.

Manu: Wide review is fine, even if we think there might be normative changes
... we can at a later date, if there are normative changes, ping people who did reviews to get updated review

<manu> Ian: I think that the topic at hand is not the one that I imagine other groups reviewing the spec will focus on. For a11y and i18n, that coupling is not a substantive point. I'm hearing the Chair say let's move on and we can come back.

Nick: Any other comments on articulated priorities?

(No other comments)

Reminder -CFC for Overview doc

https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0132.html

Nick: CFC closes tomorrow; only seen +1's so far

Reviews of payment apps spec

There were actions from FTF on Max, Zach, Shane to review the spec.

Shane: I looked over the spec and submitted PRs...mostly editorial
... I think it's an interesting direction...I think the payment options component is confusing and possibly overengineered

(Ian has some actions to edit those bits)

<zkoch> I can go

zkoch: I reviewed the specification this morning!
... I can post individual issues
... here are some high-level notes:
... I am still a bit confused about recommended payment apps, their value, their role, and how it will work in practice
... the primary thing that concerns me is UX challenges - opening a new window
... I think that will be one of our biggest issue
... there's a mention of "extension points" in the spec
... I also want to run Service Workers part of the proposal through Jake Archibald
... it seems like it makes sense but I'd like to get Jake's view
... from an implementation perspective, I am not excited by payment app options
... in section 9.1 there are a number of MUST statements that are "no go"
... I think the option ID in payment should be optional
... it's my understanding that service workers are registered without the user knowing...I would not want service workers to be registered silently
... overall it seems like a sane direction
... I need to have someone review it internally..on the whole it doesn't seem "too bad"
... but my overwhelming concern would be UX
... I am intrigued enough to get wider review in the Chrome team

nicktr: Thank you for the review (coffee or not)

<manu> Ian: One high level comment - good to get feedback now on Payment Options so we can take it to Github

<manu> Ian: I have to edit the spec so maybe we can chat offline about that

<manu> Ian: Regarding the "MUST" statements - we wanted to have functional requirements, not specific implementation guidance. For example - UA MUST display all matching options - the UA MUST NOT play a role of filtering things arbitrarily - it's a functional requirement, not a display requirement.

<manu> Zach: I still fundementally disagree with that.

<manu> Ian: I want to give confidence to people that the UA is not hiding things that the merchant or the user wants - we can find other language for that- not trying to tell UAs HOW to do things, just trying to keep the ecosystem fair.

<Zakim> AdrianHB, you wanted to respond to some of the feedback

<manu> Ian: It would be helpful to raise issues and we'll take them into account.

AdrianHB: Quick feedback on two of the other points....
... on extension points...I think that's becoming a common pattern in algorithm where you are extending an interface
... rather than people having to write monkey patches
... you give people a place to "run your code here"
... I've seen it in other specs like web app manifest
... regarding "payment options"...Rouslan suggested we take it out in v1..but everyone in the call yesterday felt it had value...we need to have that discussion (with you and Rouslan)
... it would probably be useful to join the payment apps call next week
... arguments for - allow user agent to surface payment instruments up front to the user (for usability, and efficiency). This lets user select a thing in the mediator without having to click multiple times
... the other reason is that merchants have been saying they want to put logos against those options (e.g., a card graphic) to show you are picking a visa card

[Arguments against: complexity]

AdrianHB: I think it would be helpful for Rouslan, Zach, AdrianBa could join the payment apps call next weds

<Zakim> adamR, you wanted to ask zkoch for more details about payment window, clarify registration and consent.

adamR: Regarding UX...I'd like to hear a bit more about concerns around windows....is it the prospect that the apps will need any UX at all? Or the UX to invoke them?

zkoch: We definitely need to open up something for the user to interact with...I think authentication is one of those things that will have to take place
... it's not clear to me how we would do this yet...we would not simply open a new window (e.g., closed accidentally, hidden behind other windows, etc.)
... it's come up in other contexts like Web Intents
... it's been difficult in the past...not insurmountable, but a known issue

adamR: I was trying to confirm the objection is not about the proposal in the document...e.g., they can use the most recent event to discriminate "this is a payment window"
... when I realized there is an affordance in service workers,

zkoch: I agree with you...seems fine to make use of that mechanism; I still want to get internal review

adamR: I think you agree we don't want to specify UX behavior in the spec...mostly an implementation challenge

zkoch: Yes

adamR: Regarding silent registration, we added something on top of service workers where I anticipated permission should be sought
... +1 to mentioning this explicitly in the spec

zkoch: Yes, adding that language makes sense.

<nicktr> q

<zkoch> /me is a big fan of frolicking

IJ: I am hearing consensus between zkoch and adamR that consent is desirable

nicktr: The chairs will reach out to Max for his feedback.
... Regarding payment apps, I am hearing at a high level "directionally ok" and zkoch will reach out within google re: service workers

zkoch: I think there are big issues we need to talk about ... I will log issues for discussion ... want to discuss those before any thumbs-up

<nicktr> ?

<manu> Ian: From an editorial perspective, I have some stuff in my todo list today regarding that.

<manu> Ian: Zach, question for you - do you want to log issues and have discussion/clarification around first review?

<manu> Zach: That's not a blocking dependency - I'm more concerned around Service Workers and stuff like that.

<manu> Ian: Ok, then log your issues at any point. Thanks for the review.

Issue 287 - transactionID

https://github.com/w3c/browser-payment-api/issues/287

https://github.com/w3c/browser-payment-api/issues/287#issuecomment-249231673

adamR: Topic is a shared ID between requestor and app (for tracking, e.g., help with network failures)
... seems the cleanest solution is for mediator to generate it, put it in the object and hand to payment app
... if there are things that either side has that are unique to their usage, they can simply map them between themselves...and if payment methods have internal IDs, those are part of opaque data blobs

adrianba: Right now I don't support this proposal. Primarily it feels like guessing at something we might need but we don't have details yet.
... e.g., coming up with an ID using a format that is controlled neither by merchant nor payment app.
... also I think the ID could be created in the Web page
... I would prefer to not add things until we have use case details
... we know for certain some payment methods do not need this
... we are assuming that there are many payment methods that need this .... and payment method independent format

<Zakim> AdrianHB, you wanted to agree with adrianba's comments but disagree with his conclusions :)

AdrianHB: I agree with AB's comments...but why I still think it's worth putting in there - it's low cost now and big cost to add this later.
... if everyone has had to figure out ways to get around this problem, we add no value later by adding it.

<adrianba> if we add it in and nobody uses it because it's the wrong format or an unpredictable format then it is even worse

AdrianHB: but if we add this from the start, if you can make an assumption that there will be an ID available, that changes a lot of assumptions for how you will work with the API

<Zakim> nicktr, you wanted to mention push payments

nicktr: For me, I think this will be a requirement for anybody who is accepting a push payment.

<Zakim> manu, you wanted to note that we should have a dependency on transactionId w/ another spec we're putting out there (like a push payments spec), otherwise I agree with adrianba.

Manu: I think the argument we will need this is strong, but I also agree with AdrianB that if we haven't seen any implementation experience it's premature

IJ: Is the primary use case here push payment management?

<manu> Ian: Trying to guage interest here - is the primary interest here push payment?

adamR: Yes, I think that was the primary use case

<manu> AdamR: Yes, that was the primary motivating use case.

adamR: I think that there were other thoughts beyond push payments.

<manu> Ian: I'm bundling this with Roy, principly, perhaps we can put a hold on a concrete proposal here until we hear from Roy.

<manu> Ian: Roy took an action, we should lean on him to provide that input.

<manu> ShaneM: I'll get the use cases, I took an implicit action to do that.

<manu> To be clear, I'm very supportive of transactionId - we just need a concrete usage of it.

IJ: I am happy to have heard the proposal and suggest we bundle it with Roy's action

Review action items (from FTF meeting)

Manu to prepare Overview document for CFC (Done)

AdamR to propose text about why the API can reduce need for card data storage; without any recommendations

adamR: Ian suggested some editorial changes

IJ: Are editors ok with the proposal?

adamR: I can update the PR with some edits from Ian

https://github.com/w3c/webpayments-methods-card/pull/17

- Roy to revise the tokenization specification based on today's feedback

(No status update)

- Ben to organize review of tokenization spec from EMV perspective

(IJ: I will ping Ben/Ken)

- Ian to clarify the language around consent (to say more about WG thinking) for security and privacy considerations

<zkoch> I have to drop off early to make a meeting in another building, but my update: i will get to my actions next week (unless adrianba beats me to it ;))

<adrianba> https://github.com/w3c/browser-payment-api/issues/229#issuecomment-249937391

- zkoch to remove the diagram from basic card

<adrianba> i removed the diagram

- Ian to clarify the language around consent (to say more about WG thinking) for security and privacy considerations

- Ian to clarify the language around consent (to say more about WG thinking) for security and privacy considerations

adamR: Can we send a pointer to the PING? If they are happy with it I'll withdraw my objections

IJ: I will do that.

- Ian to work with AdamR on feedback (and question) to the TAG about ambiguity around what to do re: private browsing mode (IN PROGRESS)

IJ: No response from TAG yet
... but not blocking for us

- MaheshK to work with Ben Smith on a proposal to handle merchant query for specific payment methods

<MaheshK> https://github.com/maheshkk/webpayments/wiki/Detecting-if-payment-app-is-available

<scribe> (Done and on the agenda)

- Shane to write a pull request on what might change around error handling re: addresses

Shane: Still working on that

- Zach to work with Max to revise the payment manifest proposal

<scribe> (Pending)

nicktr: Thanks everyone

FTF meeting schedule 2017

<AdrianHB> +1 thanks for all the work done since Lisbon

nicktr: How often do people want to meet? Any host volunteers

IJ: Next TPAC is 6-10 Nov 2017 in California
... Feb/Jul/Nov

Q: Three meetings?

manu: Do we have enough for 3 meetings?

<Zakim> Ian, you wanted to say "yes"

Manu: Three thinks like a bit too much

<ShaneM> I would be open to trying a virtual F2F too!

IJ: Our charter expires Dec 2017

<manu> Ian: We may want to discuss rechartering mid-year. I'm confident that 3 meetings will provide good opportunities.

dezell: I understand what Manu is saying, but it's practical to have a 3-meeting schedule
... if you meet in Feb/Mar and get stuff done, you can cancel the July one

nicktr: I hear a suggestion to start with one in Feb/Mar and then deciding whether we need a summer meeting

+1 to Feb/Mar next meeting

<dezell> "earlier than February" is early indeed!

Adrian-HB: I suggest we look in the range of "end feb" up to "april" and find dates that work

adamR: If we are struggling with dates to find, I suggest avoiding MARCH and JULY when the IETF meetings
...adamR: Feb and April sound good

<Zakim> ShaneM, you wanted to ask that we dont schedule the IG on a different conteinent this time

https://www.ietf.org/meeting/upcoming.html

---

March 2017 - IETF 98

March 26-31, 2017

Host: Please contact iad@ietf.org for hosting opportunities.

Location: Chicago, IL, USA

---

nickTR: So I am hearing we should find a meeting in Q1 2017

<scribe> ACTION: nicktr to work with chairs/team contacts on a Q1 2017 FTF meeting [recorded in http://www.w3.org/2016/10/06-wpwg-minutes.html#action01]

<trackbot> Created ACTION-38 - Work with chairs/team contacts on a q1 2017 ftf meeting [on Nick Telford-Reed - due 2016-10-13].

<ShaneM> I like Chicago in March.

Next meeting

Next meeting is 20 October (due to absences from chairs and team contact)

Summary of Action Items

[NEW] ACTION: nicktr to work with chairs/team contacts on a Q1 2017 FTF meeting [recorded in http://www.w3.org/2016/10/06-wpwg-minutes.html#action01]
 

Summary of Resolutions

[End of minutes]

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