See also: IRC log
trackball, start meeting
trackbot, start meeting
<scribe> agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160804
<AdrianHB> Call in should be working now
<zkoch> (on IRC, will call in in a bit, conflict this AM)
<Laurent> présent+ laurent
Adrian: Sorry I did not send out the agenda to the list; that was an error
https://github.com/w3c/webpayments/wiki/Agenda-20160804
AdrianHB: We have received 10 replies to the call for input
https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/0147.html
scribe: unfortunately the
responses are pretty mixed, but by a thin margin the group
prefers the earlier slot
... The time would be 2pm UTC (which right now is 7am PT, 9am
Chicago)
IJ: Will it change with daylight savings time?
<manu> Ian: There is a question about if this is going to change if it becomes 6am when DST stops, we should be transparent on which way it's going to go.
<dlongley> 10 ET
<manu> Ian: What I have done on the WGs page is write the UTC time and change the UTC time when the meeting changes.
PROPOSED: New meeting time is 10am ET on Thursdays
AdrianHB: Matt S, unfortunately,
cannot make either time
... I will pick this up with him separately
<manu> +1 to new time
<manu> (but sad to hear that MattS won't be able to join us)
AdrianHB: Any objections?
<maheshk> +1 for 10am EST
<ShaneM> In an ironic twist, I actuallky have a new conflict with that time. every other week. oh well. it is payments related. I will work it out.
<kriske> +1
RESOLUTION: Start 10am ET meeting time effective 11 August 2016
<scribe> ACTION: Ian to update the WebEx information and inform the group [recorded in http://www.w3.org/2016/08/04-wpwg-minutes.html#action01]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
AdrianHB: Please register
https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login
NOTE: fee goes up 2 September 2016
AdrianHB: We are starting to
build the agenda
... one idea is to have a dedicated agenda on first day, and
use day 2 for breakouts and editing sessions
<manu> +1 to workday for specs
AdrianHB: So we will put in draft agenda the plan to leave a lot of time for editing and breakouts; with more structured day 1
<Zakim> ShaneM, you wanted to talk about virtual f2f meetings
ShaneM: Other groups I work in organizes longer sessions for editing; we could do that too
AdrianHB: Yes, editors can do
this
... and invite others to work with them
<ShaneM> virtual break out sessions
AdrianHB: might not happen between now and Lisbon
Manu: Re TPAC, we are waiting for AdrianHB...
<Zakim> manu, you wanted to ask about HTTP API and Core Messages and Browser API comments and when to do PRs / questions?
Manu: I've been holding off
sending in issues to align with WG priorities
... I don't know what to propose at TPAC
AdrianHB: I discussed with Ian
and Nick on Tuesday. My concern at the moment is that there are
streams of work that are happening that are not getting
participation from everyone in the group
... don't want to have to unwind work
... I'm concerned with Core messages and HTTP API that only a
small set of people in the WG are giving that work
attention
... we want work in parallel but also need to prioritize our
time
... don't want to get too far down a path and then have to
unwind previous decisions....that's my worry
... personally I don't think we should publish Core Messages
yet...I would object
... so if we do a CFC now I am going to object
... for the reason that I don't think that WG has not yet had
enough input from the WG....we can't merely change by changing
the spec; we need to get people more engaged, and I don't think
we can do that until we have dealt with the higher priority
stuff
<manu> Ian: I don't think this is related to our TPAC agenda, please raise Browser API issues as soon as possible.
<Zakim> Ian, you wanted to ask people to raise issues
IJ: Please let's close this (non-TPAC agenda item) by bottom of hour
AdrianHB: Ok 8 mins
<Zakim> manu, you wanted to state specifically that we want to implement payment apps that support HTTP API and Browser API - we don't know how to do that right now.
<zkoch> (I’m on the call now)
Manu: Here's the specific issue
we have: digital bazaar spec would like to write apps that
conform to the payment request API and the payment app
spec.
... from a company perspective we are trying to write products
that implement both the HTTP API and the payment request
API
... in order to do that, we need the spec to at least be
published
... we can take core messages spec and put in the HTTP API
spec
... we need a way forward..can't just block the work
<Zakim> ShaneM, you wanted to say that I would rather stop starting and start
ShaneM: Suggest we do the CFC and get input
kriske: There is also an interop
question - are HTTP API and core messages taking into account
flows (e.g., cards standards, SEPA flows)
... in that sense I am wondering whether it's appropriate to
send out the CFC at this time
AdrianHB: In terms of next steps,
my issue is not with HTTP API. It is around core messages and
positioning as a common data model; that's not what it is. We
are sending the wrong message if we say that we are saying we
designed the APIs to work off a common data model; that's not
what has happened in practice
... if we just published HTTP API independently and down the
line are able to extract a common data model, that's great.
<manu> Yes, but we can put in an issue marker calling that out in Core Messages... we're not there yet
<dlongley> we can always add an issue to the core messages spec that says that the browser API doesn't comply with/use the core messages spec at this time (and may never) ... but other APIs will
adrianHB: I have not started CFC yet because there would be a known objection (from me).
<dlongley> the first set of specs we published in this group were very rough and filled with issues in this same manner.
AdrianHB: Kris, regarding divergence in messaging ... we are focused on initiation ...and want to interop well with existing protocols and standards
<ShaneM> Exactly! But the messages that ultimately need to go into the payment network must have the required information...
kris: I agree with that. The
issue with cards is slightly different..the cards issue is more
about an overlap...the concern is that some flows may overlap
what is going on in this group
... For sure what is happening in web payments wg space will
'get into" iso space and so we need to take into account what's
there already ... in both directions
... there are some requirements from the banking space we need
to be taking into account
AdrianHB: I suggest Kris and I
speak offline
... I also suggest Manu and I chat offline about http api and
core messages...but I am concerned that the group is moving
forward even if lower priority
<manu> AdrianHB: Happy to talk offline about it.
<dlongley> +1 to AdrianHB+Manu on issue markers possibly being the way to go
https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0035.html
<manu> Ian: Do not talk about patents in this WG
<manu> Ian: The PAG will meet, the lawyers will deal with it, meanwhile the WG can continue its work.
https://github.com/w3c/webpayments/blob/gh-pages/proposals/zach-pmi.md
Adrian's issue logged:
https://github.com/w3c/webpayments/issues/170
zkoch: I read minutes and saw
issues we'll address
... next steps is to turn proposal into spec text
IJ: AdamR, status of looking into what the right practice is if we use URNs.
Adam_: I will have something by 11 August meeting
AdrianHB: Do you want to update explainer before spec text to address issues?
zkoch: Yes.
... I will send a diff for people to look at
... will work on that early next week
<zkoch> Were there any other major issues that people wanted to bring up while we’re talking about this?
AdrianHB: This is key work to finalize ASAP because it affects everything else
<manu> I brought up the issues that we found last week, none of them were major, thanks for putting this together zkoch.
AdrianHB: Next week I would like to give Zach the go-ahead to write the spec text
IJ: Will (some of or all) of the spec text will go into PMI spec?
zkoch: Yes
IJ: Are there other issues needed for implementations?
zkoch: I think this is the last
big blocking thing.
... we have a list of feedback from merchant
conversations
... but PMIs is the last big "blocking thing"
... after we have the update, we'll circle back with a new set
of issues
<zkoch> (manu, remind me what your major issues are just so I make sure they’re addressed)
AdrianHB: The proposal talks
about two types of PMIs
... we've called them "open" and "proprietary" (or
similar)
... are you having conversations with implementers of both
types?
... e.g., Alipay or Paypal [IJ: or Samsung Pay or Yandex Money,
etc.]
zkoch: We have had a number of
conversations with orgs of closed systems ... both types (1)
1:1 relationship between method/payment app but also (2)
proprietary method is delegated to other parties
... so the spec reflects both of those types
AdrianHB: Other comments from
other implementers welcome
... The next question is - what do those parties think about
payment apps...we'd like to have those people close to payment
apps discussions
<manu> zkoch, no major issues - just 1) how do we manage the URN space (AdamR's looking into that), and 2) whether or not we can make the matching algorithm more "tag-based" - meaning, making this not only for cards, but payment methods in general (but this one is far lower concern/priority) - both can wait until after it goes into ReSpec
zkoch: I encourage that people
participate directly in the work, but I also bring back their
feedback.
... i think we are on the right track with payment apps having
both web and native apps
... I don't think we are yet at the state of surfacing specs
related to third party payment apps to app developers
... but there is a lot of interest in being part of this
ecosystem
AdrianHB: I think that we are at
a point where iteration over prototypes would help us with
payment app direction
... it would be useful to get people who are planning to
implement this commercially building this
<manu> To clarify - Digital Bazaar plans to implement this commercially.
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#design-considerations
<zkoch> sg!
<AdrianHB> Manu - sorry, did not mean to imply you didn't. I meant to say that we'd like to see prototypes from existing payment processors
IJ: Engaging at the design considerations a good entry point
<zkoch> ::insert thumbs up emoji::
https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?pli=1#
IJ: I need to sync up with AdamR and Jonny on next steps
https://github.com/w3c/webpayments/wiki/Security-and-Privacy-Considerations
IJ: Not sure our plans for filling out / using the security considerations
AdrianHB: My understanding is
that we would put wiki page together as a place to aggregate
people's comments
... it's difficult to say "we need to encrypt fields" if we
can't say why
... so I believe the document is intended to justify design
decisions like that
... goal at this point is to document issues
<Zakim> manu, you wanted to make comments on the document, since he wrote a good chunk of it.
AdrianHB: and we might use this document in different ways (e.g.,content for security considerations in a spec, or change spec)
manu: IETF has sections you look
at...I put those sections in this document
... I tried to think of specific attacks against of payment
request API
... typically you can take this and migrate this into a
security considerations part of a spec
<dlongley> https://www.w3.org/TR/security-privacy-questionnaire/
manu: I am overloaded and cannot
spend more time on this
... I hope some of our engineers at d.b. can come back in a few
months
AdrianHB: So I think we've
summarized the intent; whether we get to it will come down to
the will of the WG
... to do work
IJ: Any concrete volunteers to do work on this for 2 weeks from now?
[No volunteers]
AdrianHB: I will ask again for volunteers next week ... if you can find someone in your org to help, that would be great
Conference mention iX Payment 2016, 30 Nov 2016 in Darmstadt
<zkoch> We’ve already announced support
<zkoch> But can chat further
11 August at 10:00 ET
(IJ will update webex info TOMORROW)