Web Payments Working Group Teleconference
03 Dec 2015

https://lists.w3.org/Archives/Member/member-payments-wg/2015Nov/0001.html

<scribe> scribenick: Ian

Architecture

https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web

AdrianHB: I propose for next call that we adopt the terminology therein

<Zakim> manu, you wanted to note straw poll before adopting terminology.

Manu: I suggest in general we conduct a straw poll with a specific proposal

so that people know what they are agreeing to, and we record that.

scribe: let's sync with the Payments IG

AdrianHB: Nick and DavidE took an action to sync on the terminology

nicktr: Pending

<manu> and be specific w/ what we're adopting! :)

AdrianHB: I am hearing (1) Sync with the IG (2) conduct a straw poll to get sense of support. (3) be specific about the proposal

<manu> Ian: A couple of thoughts - sync'ing with the IG is useful, even more useful is to use the terms in practice. When we discussed them during the last meeting, there was support for adding examples wrt. what we mean.

<zkoch> +1 to incorporating (we’ve started this already)

<manu> Ian: We adopt them because they meet a shared understanding, we should use them - if editors of various documents can try to incorporate them into their work, see if they can, if they can, we might be able to use them.

<manu> +1 happy to charge ahead

<Zakim> AdrianHB, you wanted to mention the way issues are being discussed today

IJ: I Propose we try to use them (with examples) and see whether we have a better understanding of the documents as a result
... therefore don't need to be formal yet...let's ask the Editors to try it out and see

<adrianba> +1 to Ian's suggestion - I've been trying to use them and will have some feedback soon

<adrianba> however, it is hard to consume without examples

AdrianHB: It's hard to decide unless we try to use it..so +1 to Ij's proposal

<dlongley> +1 to examples first, then using those, can try to update specs

AdrianHB: I'm fully available (as person who edited the proposal) to assist any editors in using the terms

Summary:

* Add examples

* Try to use them

<AdrianHB> +1 to use the glossary

Manu: Can we add these terms to the IG glossary as experimental and use that mechanism to pull them in?

<ShaneM> +1 to add it to the glossary and mark as experimental

IJ: +1

<dezell> +1 to Manu's suggestion

<dlongley> +1

IJ: I see support from the IG co-Chair for incorporating terms in IG glossary as experimental

<nicktr> https://github.com/w3c/webpayments/wiki/Work-Plan-for-March-2016-deliverables

<scribe> ACTION: AdrianHB to add examples to the architecture page for each term [recorded in http://www.w3.org/2015/12/03-wpwg-minutes.html#action01]

<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

Getting to March 2016 FPWD

https://github.com/w3c/webpayments/wiki/Work-Plan-for-March-2016-deliverables

[AdrianHB reviews the proposal, which involves creating a unified (set of) spec(s) ; capturing issues and flows)

[Specific text proposals encouraged]

AdrianHB: To get specs to common spec:

a) Use common terms

b) Define evaluation criteria for the two APIs ...

scribe: how they handle flows
... how they handle specific issues

[IJ adds a third: does it satisfy all or part of its charter?]

<Zakim> manu, you wanted to mention that we may have 3 specs. and to become generally confused around how we are going to do merging of specs. and to note that we have specs to refer to?

Manu: CG has three specs in mind.
... we need to discuss whether and how to break down the work into N specs
... We do have specs to point to
... Seems like only one spec needs merging right now
... they differ in nuanced ways
... question is how to resolve those differences
... one approach is to have editors review each others' specs

<Zakim> AdrianHB, you wanted to discuss 3 specs

AdrianHB: The HTTP API 1.0 is not in our charter
... I think we need to consider what we are chartered to do.
... while I think we should produce an HTTP API 1.0 spec, we need to remain within charter.
... I like the idea of the editors reviewing the others' proposals
... and having a discussion with rationale for design directions
... but one thing that is problematic right now is that the specs are being discussed in the Web Platform CG
... I think it would be valuable to have a single stream for comparative critique

MattS: How do we structure discussions to determine scope within this timeline?

AdrianHB: I agree that discussion is somewhat unstructured right now
... I think the sooner we have a single spec the better.
... We talked about "phases" in the IG Roadmap

<Laurent__> +1 to having a single spec to discuss asap

AdrianHB: and there are issues where we should be thinking about what's in our future (even if not specified today)

MattS: We need a formal way to agree to what's in and what's out

E.g., we need formal decision on which flows to address in FPWD

https://github.com/w3c/webpayments/wiki/Flows

AdrianHB: Need people to contribute flows that they consider important

MattS: The use cases are functional (e.g., merchant scenarios) ... we have not yet dealt with technical choices

(e.g., which tokenization approach to support)

AdrianHB: I feel that we are going to get to a point where we've looked at the flows and we recognize that what we are trying to define is high enough level to accommodate a number of flows, but maybe not some due to their complexities

MattS: There's a key principle
... I'm not clear if we are trying to encourage the existing flows or effectively
... trying to define a new spec, and we expect PSPs and others to adopt a new spec.
... as well as schemes, issuers, wallet providers...
... the heart of the question is 'pure flows' v "impure flows"
... (read: existing)

AdrianHB: I think fundamentally we are not trying to change the whole landscape, rather do something small that we think can have a large impact.
... and that's facilitate comms between PSPs of payer and payee
... the people who will make that work will be sites, browser vendors, PSPs
... there are a number of people who can make existing flows work with the standards we build
... but I think the idea is ALSO to create a flow for emerging flows

<Zakim> manu, you wanted to mention that I thought we had the flexibility to split up specs as we saw fit? and to mention that raising issues in webpayments group was an attempt to get

AdrianHB: we are standardizing a generic comms channel

<dlongley> notes that the charter states that an API spec needs to cover: "User agent to server-side wallet communication: Where request messages are passed to a server-side wallet service, for example via HTTP, JavaScript, or some other approach."

Manu: I think we have flexibility on number of docs
... I would object to ONLY doing browser-based APIs in version

<dlongley> which seems to indicate a potential need for HTTP and Browser APIs

Manu: we need to think about the HTTP case (for automated payment scenarios)

AdrianHB: I think you've made two points:

a) 2 or 3 specs? That's a decision for the group: should we have an HTTP API spec

(if we do three, all together or stagger?)

b) then there's the design of the API

Manu: The comments around the google proposal look different from the ones on the payment cg spec
... I am trying to capture CG comments in the WG tracker
... to help pros/cons discussion
... I think we need to consolidate into a single issue tracker

IJ: I would not do fewer than 2 specs (per charter) but more ok and editors should just do the structuring they think is useful and provide to group as input

nicktr: Regarding Matt's question about designing pure v. impure, I would strongly urge us to create something that is very easy for incumbents to support.

<dezell> Want to say that it's important not to go "nose down" into the browser API, where all kinds of UI issues will entice trouble.

Flows

Flows info in wiki

https://github.com/w3c/webpayments/wiki/Flows

MattS: There are 12-13 flows there
... I've organized a 2-weekly meeting (Fridays)

"11:00 UTC for 1 hour every 2 weeks Conducted via GeneSys meeting centre IRC channel #wpwg"

MattS: So I want to see if others are planning to contribute

<nicktr> i think direct debit is also missing an assignee

<manu> http://wicg.github.io/web-payments-browser-api/#flows-addendum

<Zakim> manu, you wanted to note flow diagrams elsewhere.

Manu: there's a set of flows in the web payments cg browser API

MattS: I'd like to work from one source of flows

<manu> +1 for collapsing into one repository

<Zakim> Ian, you wanted to ask about viewing flows

IJ: What is the status of making easier to view?

MattS: I think we have the docuements in the right place for now, with the people working on them able to easily access them

<Zakim> manu, you wanted to mention that we have that, kinda.

Manu: I'm working on another approach generating diagrams from text
... in a browser
... we could have a document that links to the flow sources

<AdrianHB> There is a service that will dynamically render them but they need to be renamed to .puml files

<AdrianHB> http://uml.mvnsearch.org/github/w3c/webpayments/blob/gh-pages/PaymentFlows/Card/MerchantHosted-CardPayment-CGProposal.pml

Manu: and when you refresh page, you have idea of what flows look like.

<manu> http://wicg.github.io/web-payments-browser-api/#flows-addendum

<Laurent> http://plantuml.com/plantuml/ is also able to generate short url s to link to

https://github.com/w3c/webpayments/wiki/Flows

<manu> +1 for Matt, Ian, and Manu getting together to do that work.

<scribe> ACTION: Ian to work with Matt and Manu on creating a page that links to sources so you can click to render [recorded in http://www.w3.org/2015/12/03-wpwg-minutes.html#action02]

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).

Issues list

AdrianHB: We need to go from three issues list to 1
... Propose:

- If an issue refers to proposals, in the issue you reference the relevant section of the spec

<zkoch> +1

<manu> +1

<dlongley> +1

<Zakim> manu, you wanted to clarify

<Laurent> +1

Manu: I am hearing:

* All issues go in the github tracker, with refs to specific sections

AdrianHB: yes

<nicktr> https://github.com/w3c/webpayments/issues

<ShaneM> +1 to keep the issues in the wpwg issue tracker.

<zkoch> If you want particular attention, github supports @ replies :)

<manu> +1 to keep issues in wpwg issue tracker and ref spec sections.

AdrianHB: for existing issues, people who have raised them should clarify whether applies to one or both proposals

nicktr: I will double check the issues list against what we discussed at TPAC

https://github.com/w3c/webpayments/wiki/TPAC-2015-issues-list

IJ: Heads-up I edited lightly (e.g., to organize issues)

AdrianHB: Once we have a single issues list this should become much easier (e.g., pull request to get a change, that becomes threaded comments)

TAG election

IJ: Just a heads-up here; talk to your AC rep if you think your organization should be nominating someone!

Next call

17th December at 17:00 UTC