See also: IRC log
<scribe> scribe: Ian
https://github.com/w3c/webpayments/wiki/Agenda-20160331
<manu> NickTR: Thanks all for joining - lots to talk about - agenda is in IRC.
<nicktr> https://github.com/w3c/webpayments/wiki/Agenda-20160331
<manu> nicktr: Ian, I think you wanted to start by giving a brief update on staff resources.
<manu> Ian: I'm pleased to know that Mike Smith will be dedicating some of his W3C time to this WG.
<manu> Ian: I think I'll be the primary team contact, Mike will be second, Doug will remain in group in some capacity.
IJ: Welcome Mike Smith!
<manu> Ian: Mike will provide good input from browser knowledge, welcome Mike!
Mike5: I live in Tokyo.
<manu> Mike: Glad to be here, I'm in Tokyo - timezone is a bit different, have other late night calls, this won't be much of a hardship when there is some agenda item that the Chairs would like me on the call for. Glad to be here, looking forward to getting some great stuff done w/ all of you.
shepazu: I'm splitting off my
time and will focus on blockchain
... which is not directly related to this WG, but we are
looking at organizing a blockchain and the Web Workshop
... so contact me if you are interested!
<nicktr> nick is interested
<manu> Doug: I'm going to be concentrating on Blockchain, not directly related to stuff in this group, but planning Blockchain workshop in next 3 months - if anyone is interested, feel free to contact me.
<manu> nicktr: Great, let's move on to next item on agenda.
<scribe> scribe: Ian
-> https://lists.w3.org/Archives/Public/public-payments-wg/2016Mar/0170.html Call for Consensus Plan
nicktr: Took longer to get to the
CFC than we thought
... thanks to editors and participants
... we will have imminently an improved set of specs for the
CFCF
... as soon as I have the URLs of the specs, I'll issue the
CFC
(draft text is here: https://github.com/w3c/webpayments/wiki/Call-for-Consensus-FPWD)
scribe: will trigger a 7-day period for comments
<manu> Ian: one question - this morning Manu issued a PR to move content from one document to another, that one is a source of concern to me and affects which documents are a part of the CfC - we may need a few minutes here.
<zkoch> For reference: https://github.com/w3c/browser-payment-api/pull/110
Manu: that PR was not meant to
block the CFC...apologies
... the last one was spoke about the docs I suggested we move
some of the text from the arch doc into the payment request API
doc
... and just put that one out.
... that's what that PR is trying to do
AdrianHB: This is a question for
Manu - are you saying that you would be happy for the FPWD to
go ahead without this PR?
... or this is something that you are going to consider before
FPWD?
Manu: From our company's perspective: if the PR is taken account, we would be +1 to publishing both arch and API, otherwise -1
<Zakim> AdrianHB, you wanted to clarify
IJ: Should we call it "overview" instead of "architecture"? Would that get more consensus?
<Zakim> manu, you wanted to mention that I don't think we're going to be able to resolve this on the call.
Manu: We won't be able to resolve
this on the call. I think the discussion is more involved than
just changing a word or two
... it has to do with people reading the document and not
understanding the nuance
<dlongley> +1 for rename to Overview, make very clear that this is not a vision document for Web Payments
IJ: I agree the state section
should state clearly "this is not all we are doing"
... but I don't want to muddy the API document by including
more material in it that could be better outside in a separate
spec
AdrianHB: There is no clarity today about how payment apps will be implemented
<ShaneM> +1 - there is handwaving about payment apps in the spec. We need detail about the flow of messages and control.
AdrianHB: e.g., the complete()
method talks about sending data
... but I'm concerned that there is not shared understanding
today about apps will work
<Zakim> manu, you wanted to note that we SHOULD have an architecture specification, and the current "architecture" specification is not that.
AdrianHB: For me, that's why there is a need for more architectural language in the normative specification that is specific about how the pieces tie together
<dlongley> +1 to AdrianHB -- another point is that Payment Apps should be discussed in an architecture doc, and merely referenced by any particular API like the Browser API or the HTTP API.
Manu: My goal was not to derail
conversation today. Could we continue this discussion in the
CFC?
... the interplay between these docs is nuanced and
complex
... I do not think we will make headway today
... let's move to the CFC discussion
<dlongley> where an architecture doc encompasses many APIs and how they interrelate and so forth (I also made this same point in the related issue on github)
<Zakim> rouslan, you wanted to talk about payment apps
rouslan: I didn't want to give the impression that browser vendors are not opening up their cards. From my perspective there will be several types of payment apps.
<AdrianHB> +1 for moving on but I am concerned that the CfC will have formal objections based on what we're discussing here
rouslan: one type is "info stored
in browser"
... another type of app is "what is built into the OS"
... that might not be uninstallable
... if we are able to use it we will
... finally, there will be third party apps, which will be
different on different platforms (e.g., web sites on desktop,
native on mobile, etc.)
... I simply have not figured out how this will work but it's
ongoing
... I have expressed some thoughts on how the Android-specific
stuff might work
... so those are all my cards. :)
<manu> I appreciate Rouslan's comments on being as open as possible.
<AdrianHB> Thanks Rouslan but that's not standardizable because your proposal won't work on all mobile OS :(
<ShaneM> (I think AdrianHB meant that people have ideas they have not articulated, not that anyone was being secretive)
IJ: understand then that we will go to CFC and then people can weigh in on the PR request
<manu> I'll also highlight that a number of people are very concerned about unlevel playing field wrt. browser-based architecture.
NickTR: So I will start CFC today and people can weigh in during the CFC
<manu> not saying anyone is trying to create unlevel playing field, but when we don't know how we're going to create a level playing field, it makes people jittery.
NickTR: It's important as a WG
that we process issues and that there is clarity on how we are
doing that
... I expect a lot of new issues as a result of FPWD
... Matt Saxon has proposed some categories and priorities:
https://github.com/w3c/browser-payment-api/issues/105
MattS: This is a proposal, I
welcome suggestions and changes
... there are three sets of categorizations in the payment
request api repo
1) Which doc the issue pertains two
2) Type categories
3) Prioritization
<manu> +1 for working on extensibility/versioning.
<ShaneM> all good MattS !
MattS: So there are 16 high-priority issues where I suggest we get started
<AdrianHB> +1 thanks MattS
Nicktr: Thanks for doing this; the chairs and wg appreciates this
+1 thanks MattS
<manu> Yes, thank you Matt for working on this!
Manu: "Native support" and
"Functionality" are broad.....
... they don't give me a sense of what goes in those
buckets.
... maybe there's a "New Features" bucket
... also, I don't know whether "Native Support" is helpful.
(I'm not saying "Not helpful" just not sure if helpful)
<zkoch> for those playing along at home: https://github.com/w3c/browser-payment-api/milestones/Priority:%20High
<manu> ShaneM: Yes, we're using waffle.io - https://waffle.io/w3c/webpayments
<AdrianHB> +1 that the chairs will run with this
<manu> or rather, we're supposed to be using it (I rarely find myself on that site because I don't think of it)
<ShaneM> https://waffle.io/w3c/browser-payment-api
NickTR: I think management of this responsibility of co-Chairs
<manu> +1 to the Chairs organizing priorities w/ input from the group.
<AdrianHB> based on the group's input
NickTR: I expect to use this to organize weekly agendas
<Zakim> manu, you wanted to ask if we could break functionality down into categories... maybe call it Features?
<manu> Ian: In the HTML working group, there was a somewhat elaborate process for getting through issues.
<manu> Ian: AdrianB and I had a brief chat where we could take the best of that process and find something well suited for this group.
Dashboard?
NickTR: Is the dashboard useful?
<manu> I don't use it :(
<zkoch> I had forgotten all about waffle.io
<manu> Ian: The dashboard could be a helpful way for chairs to get a good idea of high-priority issues, relevant actions, etc.
<manu> Ian: The question is whether the chairs are finding this useful for agenda building?
<manu> Ian: That's the primary utility.
<manu> Ian: The secondary utility is for the rest of the WG members.
IJ: Is this useful for chairs?
AdrianHB: Two comments
1) waffle.io is great; Kanban board
scribe: if we want to follow a
process that can be easily modeled with that tool, then the
dashboard will be useful to us
... what that suggests is that we need to use labels to
indicate issue state
... that's one approach
2) An alternative dashboard was built in another w3c wg
scribe: that's been taking on by
the tooling team
... using github APIs and try to render them onto a page
... Doug and I were going to look at that and see if there were
better templates we could use
... that was probably more appropriate when we were looking at
proposals/resolutions
... so if we prefer that process, we can do more there.
... I also spoke with some people at Ripple (design team) who
could help with better UI on tool
... they need to know our requirements (and assuming the
project is not huge)
<nicktr> q
shepazu
shepazu: I agree with
AdrianHB...if the tool is useful then I am happy to spend time
on it (but I have other priorities currently)
... W3C systems team is taking on a part of this question...so
longer we wait easier it will be to do something
nicktr: I suggest that AdrianHB
and I will take a look at refactoring the waffle.io dashboard
for the spec repo
... and we'll bring that back to the WG....
... I would encourage people in WG to let us know their desires
re: tooling
<Zakim> manu, you wanted to mention a simpler way of how some of the other WGs handled this.
<shepazu> AdrianHB, yes, and the write-capable aspect is being generally picked up by W3C systems team
manu: Simple lists also powerful.
<Zakim> AdrianHB, you wanted to mention the w3c tool is read only
adrianHB: The W3C tool is currently READ-ONLY
<MattS> +1 to manu
(It's not a spec)
<AdrianHB> correction: there is a registration explainer proposal
Starting point for discussion -> https://github.com/WICG/paymentrequest/blob/gh-pages/docs/registration.md
<Zakim> zkoch, you wanted to comment
<AdrianHB> has been pulled into group repo: https://github.com/w3c/webpayments/blob/gh-pages/proposals/registration.md
zkoch: The explainer mostly
raises issues...lots of open questions
... this is my plea to the rest of the group that we welcome
more thought son this topic.
... please make thoughts known, even if not fully known
nicktr: I echo Zach's plea
<Zakim> manu, you wanted to ask about HTTP API and when work on that can start
Manu: We also said that the HTTP
API is a next priority
... when should that happen?
(IJ did not list since that's coming in June to my recollection)
<AdrianHB> Submit as PR to WG repo?
Nick: Matt has proposed next
priorities security and extensibility; we said "HTTP API
next"
... are there people prepared to work on the HTTP API
today?
... and to do so ahead of prioritizing extensibility?
<AdrianHB> I think MattS priorities are specific to the browser api
<MattS> Note, registration is a subset of the Extensibility/Versioning category, perhaps we should split this out
<Zakim> manu, you wanted to would work on HTTP API today and do so ahead of prioritizing extensibility work in parallel and to note that the http api may have strong effects on the browser
<MattS> Note, there were few issues that pertained to HTTP API, though I don't necessarily think that means it is low priority as the issues pertain to existing specs
IJ: I think we said previously
that we wanted to get consensus on JS API first, and then align
HTTP API with it
... I think registration is higher priority
Manu: I think HTTP API may affect
browser discussion
... the longer we push off HTTP API, the more we will have to
revisit the browser API later
<ShaneM> HTTP API will also inform messaging (potentially) and the way handshaking and interchange need to be supported.
<dlongley> +1 to work in parallel as they do have things in common like Payment Apps.
NickTR: Adrian suggests a pull
request to include HTTP API in the WG repo
... that seems like an excellent way forward.
... then we will seek editors for that work.
... I would do the PR with the CG's text
<AdrianHB> put it in the proposals folder in the Wg repo
<manu> ACTION: Manu to submit a PR for HTTP API into the proposals folder for the WPWG repo. [recorded in http://www.w3.org/2016/03/31-wpwg-minutes.html#action01]
<trackbot> Created ACTION-17 - Submit a pr for http api into the proposals folder for the wpwg repo. [on Manu Sporny - due 2016-04-07].
<scribe> Postponed:
- Using the group's general issues list
- Facilitating participation
<AdrianHB> +1
Nicktr: I am keen to encourage participation by more WG participants
<zkoch> I have to drop off to make a 10am meeting that’s in another buidling. Thanks all!
Nicktr: one way to do this is to turn flows task force work into payment method specs
VincentK: Currently we have been
focused on card payments...
... we need to look at a larger set of payment methods (via
payment method specifications)
... to help test the API
<AdrianHB> +1 to publishing as many payment method specs as we can put together as long as we don't favour quantity over quality
NickTR: Yes, the more we do the greater the chances of adoption of the API
MattS: We had a FTF meeting in
London with myself, Cyril, Jean-Yves, and Frederic
... we reviewed the work and the flows work.
... we ended up spending a lot of time on extensibility and
versioning in the following sense: documenting addition payment
methods
... we checked with Ian on process
... so that while we are NOT chartered to write payment specs
for these payment methods, we are not prohibited from creating
WG Notes
... so we could have WG Notes for multiple payment methods (not
just cards)
... so I think the flows task force will contribute multiple
specs
... this is not only for the flows task force...others
encouraged to submit payment method specs
... we have commitments already for SEPA Credit Transfer, Union
Pay, 3DS
(IJ: +1)
<MattS> not 3DS
<MattS> SEPA CT, SEPA DD, UnionPay
ok tx
<MattS> We have no people volunteered so far for 3DS, but I would welcome such as proposal, is anyone up for this?
PROPOSED DATES FOR FTF: 27-29 June in London (with an IG meeting)
scribe: I will send out an email
Next meeting: 7 April
Shepazu: Risk of overlap with blockchain WG workshop