See also: IRC log
<scribe> scribe: Ian
-> https://github.com/w3c/webpayments/wiki/Agenda-20160407 Agenda
AdrianHB: CFC has started ->
https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0012.html
... please review them and respond by 12 April
... sorry for delay in getting this launched (but handled a few
issues in reasonable fashion)
... we'd like to hear active support or expressions of
concern
... no Formal Objections yet but have received some
feedback.
... work started on FAQ
Ian: First draft of an FAQ to accompany FPWD -> https://github.com/w3c/webpayments/wiki/PaymentRequestFAQ
<manu> Ian: Here's the first draft of an FAQ
<manu> Ian: This will accompany FPWD
Blog post draft: https://www.w3.org/2016/03/15-wpwg-blog.txt
<manu> Ian: We're anticipating a blog post as well on the WG homepage framing the publication.
<manu> Ian: Presumably on the WG site, there will be a link to a FAQ.
<manu> Ian: This is a response to Mike Smith's request - this is different from the Charter FAQ
<manu> Ian: The Charter FAQ predates our work, I wanted to revisit some of those questions in light of our progress.
<manu> Ian: We'll update the list of specs published as we know which docs are published via the CfC.
adrianhb: That looks like a useful resource
<Zakim> manu, you wanted to comment on Call for Consensus comments which may have been lost in the mailing list traffic.
<manu> https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0022.html
manu: See Digital Bazaar
comments
... including the rationale
... I suggest people read that.
<Zakim> MattS, you wanted to ask what a minus one means if it is not a formal objection
adrianhb: When people have
comments not related to the CfC, please start an independent
thread.
... to make it easier to follow the CfC thread.
MattS: Manu, what does -1 or .5 mean in your email?
adrianhb: We are looking for
consensus; this is not a majority vote.
... a Formal Objection means "there is not consensus"
... Manu's comments indicate they do not want to raise a Formal
Objection...they are indicating lack of support but don't want
to "block" the publications
IJ: Manu, does that represent what you intended?
Manu: We support the publication
of documents at a later time once concerns are addressed.
... if we see lack of support for publishing, we would expect
that input to be taken into account.
MattS: I see some organizations and some individuals have responded. What's the relationship?
<manu> Ian: The Chairs and I discussed this before announcing the call for consensus - more verbiage around organizational or individual responses. The W3C process is very explicit that when there are multiple voices speaking between the same organization, that the chairs took that into account.
<manu> Ian: We didn't feel like we needed to say "only one person per organization"
<manu> Ian: Individuals from same organization may have different opinions, we're trying to take individuals opinions into account.
dezell: NACS will respond later today. Just wanted to point out that some of Manu's concerns are not about quality of work, but about reaction of people in the payment industry
ach deze
dezell: I think that as a WG member, I'd like to request that the chairs think about how to mitigate some of these concerns without slowing things down
<manu> Ian: I'd like to speak to that directly.
<manu> Ian: I have appreciated hearing from people about that concern and what general expectations general audiences may have.
<manu> Ian: I think it's important to recognize that it's a W3C expectation to make early work available. If we publish a document that's early work, or wait a month to publish early work, that we'd have the level of maturity that some in the industry might anticipate.
https://www.w3.org/2016/03/15-wpwg-blog.txt
<manu> Ian: To mitigate this, we've created the blog post and I welcome feedback on the blog post. That's going to be one of the principal deliverables, thanks to Matt Saxon for providing feedback.
https://github.com/w3c/webpayments/wiki/PaymentRequestFAQ\
<manu> Ian: The FAQ is the second instrument - the way to can contribute collectively - bring stakeholders interests together in FAQ - there is time between now and end of CfC - two weeks in best of case - I really urge people to not just express concern, but help express it by fleshing out these materials.
<manu> Ian: Even if we were to delay, some would not find them mature - let's get these things out and provide material to mitigate these concerns.
kriske: The discussion today is about FPWDs...knowing that there are issues in the document that need to be fleshed out....what are we trying to find consensus on?
adrianhb: As someone who worked
in the payments industry for a while, I appreciate the
sentiment that this is a brave new world.
... its our job as wg participants and members to "break it
down" for people.
(...cf previous comments from NickTR )
scribe: W3C specs are not the
same as ISO standards (with legal mandates behind them)
... no obligation on people to implement W3C specs...it's our
responsibility to explain to our own orgs this process
"Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. "
<manu> Ian: What we try to do at any stage of the W3C process is indicate the level of consensus for the work.
"This draft highlights some of the pending issues that are still to be discussed in the working group. No decision has been taken on the outcome of these issues including whether they are valid. "
<manu> Ian: Earlier in the status section we highlight pending issues, and we note no decision is made on these issues.
<manu> Ian: We try to not that this is not the full set of deliverables that this group has produced.
<manu> Ian: For this set of specs and picture of architecture document, is this the right direction? The call for consensus is not that we have agreed on the current proposals, but simply whether they should be published as documents with open issues in them.
<manu> Ian: The publication is basically saying - this is the start of a conversation, we want more people looking at this.
<manu> Ian: Starting with the next call, we'll shift our attention to addressing these issues - keep logging issues, keep them coming.
<Zakim> dezell, you wanted to discuss a quick comment on content vs. signalling.
dezell: I wanted to point out
that in previous WGs I've been involved with, it's been useful
to distinguish content from signals.
... I think what we want to "worry about" ... we don't want to
lose people silently.
<manu> +1 to David Ezell
adrianhb: Occasional public
signals help keep people engaged
... since they see progress.
<manu> http://w3c.github.io/webpayments/proposals/web-payments-http-api/index.html
AdrianHB: Manu proposed the WG take up the CG's HTTP API spec -> http://w3c.github.io/webpayments/proposals/web-payments-http-api/index.html
manu: This spec gives non-browser
web clients a way to initiate payment requests and process
payments, and provide ack's back to a server.
... you can think of the HTTP API as really important for
things like automated payments, or "headless " processing
... (that is where the user is not present but has delegated
authority).
... the draft spec is simple and high-level
... [Manu summarizes flow characterized by the API]
-> http://w3c.github.io/webpayments/proposals/web-payments-http-api/index.html#payment-flow-overview
scribe: we have stripped out information related to JSON-LD.
adrianhb: How mature do you think the spec is?
Manu: It's nowhere near
done.
... the hope is that people in the WG would review it and raise
issues on the document.
... there's a lot of coordination work that needs to be
done.
... My hope is that people will raise issues on the spec over
the next few weeks.
... after gathering issues, we would then publish as an FPWD
with issue markers
... and then start to address those issues
adrianhb: In terms of logging
issues, the proposals are in the main WG repository, I would
ask that people who wish to raise issues against this proposal
(or any proposal not yet adopted by the WG), please use the
main repo.
... and tag them
kriske: With my ISO hat on, I think this one is really interesting
<ShaneM> the media type for the diagram is text/jumly+sequence. I have no idea what that is, but my Chrome browser has no idea what that is.
kriske: these are the flows that
will hit the payment service providers
... is this where interop will be key?
Manu: In general, yes, we want to
see a lot more alignment with ISO 20022
... to do that we may need to speak more about the messages
that are passed back and forth
... but it's up to the WG to determine to what degree and how
to do that.
... we have another proposal to submit to the group on payment
messages
... in the HTTP API we need a full-blown message
... question is how to express message in both worlds
Kriske: I am not speaking about
ISO20022 payment messages...but rather ISO components that
would be useful in the flow
... I assume this is a RESTful exchange
... ISO is not in the space of JSON calls, but what I'm
interested in is whether there are ISO20022 components that
could be used
... these are the same components that banks or service
providers would pick up in use in other contexts
manu: Yes
padler: (On a URL for
callback)
... I wanted to point out that there's a second main flow which
is out-of-band acknowledgment
Manu: See issue marker #2
<Zakim> padler, you wanted to ask about flow...
<manu> Ian: A few terse comments - I support bringing this specification to the WG, I support delaying attention on FPWD.
<padler> + 1 to bringing proposal into the working group..
<manu> Ian: I think in-browser and out of browser should proceed w/ their own goals in mind. It is not a requirement for them to align. I don't want to have an a-priori requirement to say messages should be shared between the two.
<manu> Ian: I don't want us to derail getting to FPWD or getting payment app registration into place.
<Zakim> manu, you wanted to ask if we should move this to a separate repo? and to not that we want to strongly support integration w/ ISO20022 and to say no, payment app registration is
Manu: I thought this group had resolved to pick up the HTTP API right after FPWD.
IJ: We also resolved earlier to delay HTTP API until June.
<ShaneM> I remember that the group agreed HTTP was next at the F2F. I don't remember a date.
iJ: ...I think payment app registration is more important
<MattS> +1 to bringing it in
Manu: Yes, payment app registration is important, but don't want to delay HTTP API discussion any longer
(To reiterate: I am +1 to bringing it in; just want to delay discussion)
Manu: Should we create a separate repo for the HTTP API spec?
AdrianHB: I am fine to do
that.
... I think we should give the group a chance to review the
proposal
<MattS> Can't we have multiple priorities, we after all have a large group of people - I would like the chairs to give a clear priority steer and make this public in the blog that accompanies FPWD
AdrianHB: raise broad issues, and encourage multiple proposals.
<Zakim> manu, you wanted to agree that we should follow a process, just don't know what the process is.
AdrianHB: ok to put it in its own repo once we've taken it on
(IJ does NOT think that this is documented in significant detail...but it is lightly documented)
https://github.com/w3c/webpayments/wiki/How-the-Working-Group-works
adrianhb: If we decide to take up a proposal, it should go into its own repo.
https://github.com/w3c/webpayments/wiki/How-the-Working-Group-works
<manu> Ian: This document is light on details, we should document these things in more detail, we'll get this updated as best we can.
https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html
Adrianhb: I started work on this,
based on the Google explainer and some info in CG specs.
... similar format as the specs
<manu> +1 to MattS
Adrianhb: at a high level it
proposes we use the AppManifest spec
... The rough lifecycle of an app is that app publishers will
publish a manifest,
... user asks Mediator to install the manifest
... this gives information about supported payment
methods
... user selects appropriate payment apps
... mediator sends payment request data to URL that is part of
the App Manifest
... and response from app could vary, from information about
how to launch something, or a payment response, or some sort of
custom response (e.g., to work with native apps)
... the goal being to enable apps of any type, but to provide a
standard for Web-based payment apps whether with or without
UI
... this spec has a lot of issue markers in it
... it also takes ideas from a project called Ballista, but
that may change
... it's an early work and probably needs and explainer and
more explicit information about lifecycle
(IJ: I sent comments about lifecycle on the list)
MattS: Does this overlap or complement Zach's explainer?
AdrianHB: It's based on the ideas
but not exactly the same
... one area where we have a point of contention...I did have a
chat with Zach yesterday
... in principle Zach seems ok with this draft spec, but there
are details to work out about browser behavior
... use of how to handle response that we need to iron
out
... the major "point of contention" is "do we map on payment
app ID or payment method?
... so can you request that a payment app be loaded?
matts: Please raise these points
of contention as issues
... so that we can contribute
adrianhb: I assume that Zach will log the issue unless I manage to persuade him.
MattS: Please note Cyril's proposal
https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html
AdrianHB: Ian has converted to respec:
https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0024.html
scribe: I want to [Thank Cyril]
and encourage this sort of input for specific payment
methods
... thanks very much to you, Matt, for connecting the flow work
to the payment method specifications
... I want to emphasize to people in the group that this is a
useful way for participants to document payment method
thoughts
... please contact the Chairs if you have questions about how
to use GitHub, or write specs
... this will help demonstrate that the API stands up to the
reality of the payments industry
AdrianHB: I would like to ask the
WG to make comments and/or make counter proposals.
... a week may be short given CFC
-1 to this proposal from AdrianHB
<manu> Ian: I would much rather say "There are concrete proposals on the table."
<manu> Ian: I don't know why we would reject another fully baked HTTP API proposal. I don't think we should stop proposals from coming in.
AdrianHB: Please review the three proposals and we'll decide whether to adopt them at the 21 April call
<manu> Adrian: The proposal is to have the discussion in two weeks and ask if we should pull them into the group. If everyone agrees that they like them, and there were no counter proposals, our ED draft specs for HTTP API will be pulled in.
<manu> Ian: I think we should treat each one independently, I think the scope should be "On 21st April, we will make decisions on whether or not to adopt the 3 current proposals"
<manu> Ian: If someone shows up a week before that date, we'll say we'll consider that additional proposal for two-three weeks.
<manu> Adrian: I think we don't want to delay making a decision on adopting proposals.
<ShaneM> +1 to AdrianHB process model
<manu> Ian: I'm happy to not discuss this further, if people propose something is taken up by the group, the group should give it consideration. That's all I mean.
<dlongley> +1 to AdrianHB (let's set a date to make a decision), then also allow any proposals at any time too.
<manu> AdrianHB: I'm trying to get us to a point that says "We have a proposal, and now we have an Editors Draft of that proposal." Setting a date let's the group know what we're attempting to do.
<manu> Ian: Setting a date for a thing that's known makes sense to him.
<manu> Ian: I don't want to commit now to make a decision about a thing I don't know about yet.
<MattS> +1 to moving on!
<dlongley> +1 to Ian
<manu> AdrianHB: So if someone else shows up with new Payment Request API, we'd consider it?
NOTE:
<manu> Ian: Yes, the group may say no, but we should consider it.
* On 21 April we will discuss the three proposals on the table, to take up:
- HTTP API draft
- Payment App Registration spec
- Cyril's SEPA payment method spec
<manu> +1 to support, no objection
<dlongley> +1 to the proposal
(No objections to that path)
<manu> Ian: One important note - we've been talking about face-to-face at end of June, but there is also a W3C workshop on blockchain around same time.
<manu> I'd like to attend the Blockchain workshop.
<manu> I'd love to see it tacked on to the beginning or end of the Web Payments face-to-face
<Brian> Ok, but only because different people from visa would probably attend each meeting
<padler> would like to attend both.. but understand if not possible to avoid conflict..
FOR NEXT TIME:
* Encouraging contributions
AdrianHB: I look forward to people's responses to the CfC
14 April usual time (noon ET)