See also: IRC log
-> https://github.com/w3c/webpayments/wiki/Agenda-20161006 Agenda
<scribe> scribe: Ian
-> https://github.com/w3c/webpayments/wiki/Agenda-20161006 Agenda
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)
https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0132.html
Nick: CFC closes tomorrow; only seen +1's so far
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.
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
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
<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 is 20 October (due to absences from chairs and team contact)