Web Payments Working Group Teleconference
19 Nov 2015

<Kuntzv> Will join by phone in 5min

<ijmad> not working for either of us... dial in just told me to go to the web and hung up on me, helpfully

<AdrianHB> https://github.com/w3c/webpayments/wiki/Agenda-19th-November-2015-at-17%3A00-UTC

<ijmad> we are in via Skype

<AdrianHB> scribe: dlongley

AdrianHB: First up is Nick's operations discussion.

<CyrilV> Cannot connect to phone ??

<nicktr> cannot connect by phone either

<nicktr> how are folks connecting?

<AdrianHB> Skype?

<mountie> via webex

<ShaneM> I can switch to webex voip

<nicktr> i can't get into the webex

<nicktr> voip or phone

<mountie> use this https://mit.webex.com/mit/j.php?MTID=m70b2395752d7ffae145c41abd05da1f5

<CyrilV> It seems that the meeting number is wrong. Manu what number you use ?

<ijmad> webex is just failing to launch for me at all

<ijmad> i can get to the website, but it just spins

nicktr: Do people just want to call out comments that they have on operations? Fundamentally we've said that we want to work principally around github and I've tried to reflect that in what I've documented.

<nicktr> https://github.com/w3c/webpayments/wiki/How-the-Working-Group-works

nicktr: For those of you who haven't seen it previously, it's in the agenda.

<shepazu> manu++

nicktr: One of the key enablers has been some fantastic work people have done, most notably Manu, to create automagic to reflect issues raised in github back to the mailing list. The charter requires us to conduct our group principally on the mailing list so we need to reflect issues there.
... If we come down to how we see that kind of working, fundamentally, the way to contribute to the work is to review and suggest changes to the work. To do that on github you should fork that repo and make a change and issue a PR. The owner can then see it and respond to it. You can do all of that without having a local git repo via the git interface and those issues will be reflected to the mailing list. People who can't contribute via github will be

able to follow along with the mailing list.

manu: Overall the page looks good. It seems to reflect where consensus was, so thanks for that Nick. I want to point out that our work flow right now is set up so that at the very least, all you need to do is be subscribed to the mailing list and you will see what you need. If all you want to do is track what's going on and comment on issues as they go across the mailing list you can do that purely through the mailing list, no github account required. You

can just use the mailing list and that was a concern we addressed from TPAC.

<Zakim> manu, you wanted to comment on how the WG works. and to note minor errors, and will fix.

manu: The github mailing list magic should be set up so no one has to think about it. Every issue we're concerned about and every repo the group is concerned with will be reflected to the mailing list. There's one correction ... that says people need to watch particular repositories, and people don't have to do that to be notified of the issues and the discussions. I just want people to know that ... the work flow we set up doesn't require you to do anythi

ng (other than follow mailing list).

Mountie: I cannot distinguish on github who commented. Can that be added to the github notifications?
... Maybe the mailing list at W3C is getting commented name from github, just the name is described, maybe I can ... the name. If the company name in the email address is included that would make me happy.

manu: We can't easily do that now unless someone will volunteer to write a non-trivial amount of code.
... Doing that is not easy, the stop gap measure for that is to just look up the person's name in the mailing list to figure out which organization they are from.

<AdrianHB> +1

manu: It's not easy to implement that, it would require a decent bit of work to do that and you can do it anyway by looking at a webpage with the person's name.

shepazu: You can make it so your github name reflects your company, but that's up to each individual.

Mountie: Most names I know, but other people who are newer ... I have a hard time identifying them.

<manu> You can look the information up here: https://www.w3.org/2004/01/pp-impl/83744/status

nicktr: It sounds like there isn't an easy technical solution to this and as Manu says maybe the stopgap is to look at the person's name in the mailing list. I'll grab the URL and include it in the wiki.

<manu> sorry, this is the correct list of participants for the group: https://www.w3.org/2000/09/dbwg/details?group=83744&public=1

nicktr: I'll note a couple of other things in the article or we can have comments in the article itself or on the mailing list or raise an issue. We will be using the mailing list for announcements, things that aren't in github, new artifacts in github, etc. communications that people who haven't yet interacted with github.

<nicktr> https://github.com/w3c/webpayments/wiki.atom

nicktr: The rest of the document is a copy and paste of the policies in place for the IG. I dont' see why we wouldn't work in the same way for the most part as the IG, but I'd love to hear any other proposals if so desired. Wiki changes won't be reflected on the mailing list but you can follow an atom feed.

AdrianHB: If you are going to make major changes on the wiki you should send a mail to the mailing list.
... That's useful for everyone to know what's going on on the wiki.

nicktr: If people want to think about it and get back to me send something to the mailing list or edit the wiki directly and I'll pick those things up.

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

nicktr: AdrianHB you wanted to talk about your architecture.

AdrianHB: It's a bunch of wiki pages, not sure if people have had a chance to look at it. There's a custom side bar down the side with links to other pages. The purpose of putting this together was to try and address what felt like to me was a real challenge in specifying the components we're using here. We're using terminology that has some baggage that has existing meaning for people here. Some of those people aren't comfortable with us changing to suit

what we mean. I spent time trying to figure out other names. I give credit to others who saw this coming a year ago and came up with Payment Agent, but in the end I think that was too generic and I broke up the architecture into smaller components.

AdrianHB: I dont' know if we have time to get into a deeper discussion now, probably not so. I wanted to describe components without any deployment considerations, so the same components will work on a mobile platform to a desktop platform or even IoT. It's very basic and excludes players outside of scope, like PSPs. It's assumed they'd be able to communicate as needed.
... The first previously defined component I've renamed is "Payment Instrument". Some people viewed it as a bit of data, others as something more elaborate and executable. And it depended on the deployment scenario. I've called it a Payment App. And the thinking is you'd register that with whatever agent you have like a browser. The whole point is to pick a Payment App to handle a payment.
... A PaymentApp is something put there by the payer and they have one or more of them and it interacts with the user and does everything necessary for a payment when a request comes in and produces a response back to the payee website.
... The other thing I've used now is "Payment Method" instead of "Payment Scheme"

<Zakim> manu, you wanted to raise concern over terminology and mapping (discussion may need to be in IG) and to mention that abstract architecture seems fine, but overlaps w/ capabilities

AdrianHB: When you get a payment request it lists a set of ways the payee would like to be paid and these are Payment Methods.

manu: In general I agree with the abstract architecture you've put together.
... I have a couple of concerns, there is new terminology so we need to get that straight and it seemed like something the IG was going to do and not this group. The other concern is that we're talking about an abstract architecture here which has overlap with capabilities doc which again this group doesn't work on. It's good what you've put together but I'm worried some of this is IG work and not WG work.
... I'm wondering what your thoughts are on where the rest of this work should happen.

<Zakim> dezell, you wanted to +1 on terminology.

<ShaneM> +1 to letting the IG be the keeper of the architecture & terminology so that they can coordinate with all the moving parts

<nicktr> can't hear dezell

dezell: I wanted to +1 what Manu was saying and more in the form of an offer. If you're feeling some changes need to be made in the terminology please push that back to the IG so we can keep that as the space for terminology. We may fail in that but we should at least try.

<jyrossi> +1

<Laurent> +1 to Zach's point

zkoch: I'm a bit fan of the new terminology. I respect the IG stuff, but as a WG we just want to get stuff done and this allows us to do that. With respect to the IG we have a right and obligation to define this stuff in the WG and a big +1 that it's clear what it means.

<davidillsley> +1 to comments from zach

nicktr: I think these are good terms and if we as a WG are comfortable with them, we can work with them. We can talk about how to socialize them back to the IG. As long as the WG is comfortable with this as a working language that's helpful.

<ijmad> +1 zach / nicktr

<zkoch> FWIW, I’ve already started modifying our proposal to use this language :)

dezell: The IG doesn't want to be a [some idiom] of technology, if we end up standing in the way of the WG we'll get out of the way, but for now let's get the terminology back to the IG and do that as long as we can.

<Zakim> dezell, you wanted to clarify

<Zakim> manu, you wanted to echo financial industry concerns and how to address those.

<nicktr> ACTION: nicktr to work with dezell to socialise the terminology in Adrian HB's architecture with WPIG [recorded in http://www.w3.org/2015/11/19-wpwg-minutes.html#action01]

<trackbot> Created ACTION-7 - Work with dezell to socialise the terminology in adrian hb's architecture with wpig [on Nick Telford-Reed - due 2015-11-26].

manu: We've gone through this whole trying to set terminology thing before because the financial industry was pretty loud because we're inventing terms no one is using there. We could assert that we need to create specs for Web developers and I'm guessing that there are far more Web developers out there than financial people working on standards and we need to map terminology to that and if we do that I can see using the terminology Adrian has come up with

. But we can't do that without addressing the key reasons why we didn't invent new terms in the first place.

manu: So we need to address that.

<Laurent> +1 to having a common language that we can easily map on the financial industry terms

AdrianHB: The purpose of this is two-fold. We want common terminology as a WG, as Zach said, we want to make sure we're talking about the same thing. We spend a lot of cycles debating something when we have different perspectives on what something means. The second is that these are intended to be names for components in an architecture and I don't think the financial industry does that. We're appealing to a very specific audience. I echo what Manu says, w

e should say this is how this Web architecture works and what they are and then say how they relate to financial industry terminology. We can say a Payment App runs in different environments and so on but most of the time it relates to a single payment instrument.

<nicktr> +1 to AdrianHB's approach: let's agree on some working labels in the WG and then manage the translation back to the financial industry terminology

AdrianHB: I think that's the piece of work that Nick and David are talking about doing and we should push some of this back to the capabilities document.
... We should put preference on developer friendly.

+1 to Adrian's comments.

<dezell> Adding comments here - not to hog time... my only request is that as the WG departs from existing terminology (which will happen inevitably) please make sure we have an organized way to pipe that back to the IG. The IG will try really hard not to disrupt progress.

CyrilV: To come back on terminology and the financial industry... I think it's important to take this new terminology to the IG so make sure we aren't indifferent to them. We want the IG to be part of this to avoid bad relationship/issues.

<AdrianHB> The purpose of using these terms (and how I chose them) was to explicitly avoid using terms that are already in use

manu: I wanted to focus on the architecture and the components you've laid out. I think they are good. We've got the functional bits out there. There is a lingering concern around registration and who is operating the Payment Mediator in this. One way we could do this is that it's a completely decentralized process and a user gets to choose much like they choose their browser and OS.

<Zakim> manu, you wanted to focus on architecture - registration concerns - X as the center concerns.

<zkoch> I think this a decision to be made my implementors

manu: There is another approach which I've heard which is the OS will take care of who the mediator is and registration is out of scope and that approach raises a huge number of concerns. That means MS Windows will ship with a certain Payment Mediator and Chrome OS another one and it's unknown if you change or share information, there's concern over lock or defaults being presented so that they don't know their choices, etc.

AdrianHB: I know you're not really going into that in your architecture but it's a concern. I don't think we've written those concerns down in the issue tracker and we had a doc we worked on at TPAC and registration is one concern. Adrian and Nick are you going to move those issues to the tracker any time soon?

<manu> +1 move them to Github

<manu> -1 to W3C issue tracker

nicktr: Yes, thanks for the prompt and I will move those issues... that's a question for the group actually, do we want them in github or the issue tracker.

<ShaneM> +1 to github

+1 github

<AdrianHB> +1 github

<nicktr> ACTION: nicktr to move google docs list of issues to github wiki [recorded in http://www.w3.org/2015/11/19-wpwg-minutes.html#action02]

<trackbot> Created ACTION-8 - Move google docs list of issues to github wiki [on Nick Telford-Reed - due 2015-11-26].

AdrianHB: I thought about this, but my decision was to not talk about it yet. I just wanted agreement on components and to see if people are happy with them. The Payment Mediator has a "manifest database" and if we like that we can discuss how things get into that database. Is that an implementation detail or do we care more, etc.?
... I think we can agree on standard components and then there are things to discuss later on.
... If everyone is happy with that, if we can agree on high-level components and names for a week or two and then we can start to decide what we need to build on top of that to get to the deliverables we have in the charter.

<nicktr> This BTW is the list of issues that I will be moving: https://docs.google.com/document/d/1yJEba_BCUK0Q1nCaD2sGM4h6HxxxEcT15ruRlvowr7o/edit

<Zakim> MattS, you wanted to ask about payee's PSP

MattS: In general I'm pretty happy on this so far. I want to know if we should have a specific discussion around that on github.

<CyrilV> * Zach, please anticipate to speak for foreigners ;-)

AdrianHB: Manu has already started one issue thread around this stuff, we can use that and if that's insufficient start another. On the next call or the following weekend I'll propose we adopt this set of terminology and basic component list we can move forward with that. There are many layers to build on top of that, but we can start using the terminology in the flow diagrams, and the proposals can be tweaked to use the same terminology and we may find th

ey are actually quite similar at that point.

<Ian> (This suggests to me the arch doc might benefit from examples!)

zach: I'm for the terminology as I've said. I want to do a quick example to see if I understand it. A Payment App would be something like Apple Pay and a Payment Method would be a Bank of America Card inside Apple Pay and a Payment Mediator would be [missed (sorry)].

<nicktr> +1 to Ian

<Zakim> zkoch, you wanted to do a very fast example to confirm on the same page

<Ian> (IN particular examples where a given thing in the world (e.g., google pay, apple pay, samsung pay) has different roles in the architecture in different scenarios)

<manu> +1 to Ian - we need examples in the components doc.

<KuntzV_> +1 to Ian

AdrianHB: The Payment Method is something the merchant advertises they can say "I accept Visa, Mastercard, Apple Pay". And the flip side of that is that the Payment App can support Apple Pay or just Visa cards they can do that as well.

Zach: +1 to Ian for examples on the page.

+1 to examples.

Laurent: Payment Method would be Visa and we might have Visa card number as well, for example

AdrianHB: The Payment Mediator is the only thing not covered that Manu alluded to. It receives a bunch of Payment Methods that are supported and it looks in its manifest database for all the Payment Apps it has available and uses an algorithm, potentially with user interaction, and it picks one to handle the payment. It could use a bunch of rules to pick it automatically or ask the user, it's an implementation detail. We may provide guidance on a suggested

algorithm later, but here we're just talking about components.

AdrianHB: I don't want to get into much more because we're down to the last 10 minutes. Look at the wiki, edit the wiki, add more pages if you think there are additional examples required. I'm happy to chat with anyone or answer any questions.
... Let's get to some consensus over the next week or two going forward.

nicktr: Let's talk about moving forward on evaluating the proposals.

Zach: A quick update: We're in the middle of making a series of modifications based on discussion. I have a lot of time blocked off for tomorrow. After Thanksgiving we should have a much more fleshed out proposal then. So that's a good time to talk. I don't think the fundamentals are drastically changing and please bring up issues on github/wiki page.

<zkoch> Sorry if that was fast!

<AdrianHB> Google: https://github.com/WICG/paymentrequest/

<AdrianHB> Web Payments CG: https://github.com/WICG/web-payments-browser-api

<AdrianHB> Two complimentary specs from Web Payments CG:

<AdrianHB> https://github.com/web-payments/web-payments-messaging

<AdrianHB> https://github.com/web-payments/web-payments-http-api

manu: Effectively the same thing is going on here, we're going to be hammering out some of the details on these specs over the next few weeks. We can then get into pros/cons of the various proposals. I think "paymentrequest" is focused on how the browser handles this stuff and the web payments browser API deals with browser API. But there are two other specs that we haven't really talked about to date. One of them is about whether messaging should be pulle

d out and be its own spec. We expect that maybe these messages flow over purely HTTP APIs.

manu: And to that end, the CG proposal splits these concepts into multiple specs. The messages spec talks about how to express instruments and payment requests and responses.
... Then there are two other specs that use them. One for browsers, a browser API, and one for HTTP APIs.
... They are still works in progress and we'll try and hammer them out a bit more by the end of next week.

<AdrianHB> +1 for defining vocabulary, message schemas and flows separately to deployment specifics (such as browser API)

manu: The question to this group is "what are we doing about the messaging and the HTTP API stuff." I think it's on our deliverables. I don't know if, Zach, you are primarily focused on the browser API.

Zach: We're mainly concerned with the browser API at this point.

nicktr: Given that we have two proposals that look at the browser API, we only have one to look at the HTTP API. Would it be sensible for us to look at alignment on the browser API?

+1 to finding alignment

manu: Starting there is always a good discussion because we can compare the two. The HTTP API people will have to raise issues because there's nothing to compare. We will naturally over time end up talking about it as a side effect if we focus on the browser API for now.

kris_: When you're talking about the HTTP API will you be talking about if you'll be using RESTful design or SOAP, etc.?

manu: Yes, the assertion is that the HTTP API will be RESTful, not SOAP, just simple JSON-based messages. We'll be talking about all of those things when discussing the HTTP APIs.

kris_: Is there a link with the browser API?

<manu> dlongley: Quick comment - messaging spec ties the HTTP API spec and Browser API spec together. That's where some of the focus may be.

<manu> Are we ready to do testing: No :P

<manu> Are we ready to talk about testing: Probably not :P

manu: Yes, you should be able to do the same things with both APIs they are just for different arenas.

<rouslan> +q

nicktr: Just because we can't start testing doesn't mean we can't start talking about it.

ShaneM: I think we can start any time.

<rouslan> -q

ShaneM: There are two sides to this testing issue, I'd love to have people come play with me. We'll be testing two things: browser API and messaging. We'll be exercising a server and using the existing W3C infrastructure. We'll be using a server to emulate. If there are RESTful APIs we can use those. If you want to talk about the approach we can do it offline.

<manu> +1 to what ShaneM said - let's focus on testing architecture if we're going to talk about testing now.

<Ian> CONCRETELY:

<Ian> * 3 Dec

<Ian> * 17 Dec

<Ian> * 7 Jan

<Ian> (Next meetings)

nicktr: Next week is Thanksgiving in the US which why we met today. For the remainder of 2015, we meet every other week from this week. And once we get through the Christmas holidays, we'll revert and have this meeting on the first Thursday of 2016. I'll put that into the mailing list and the wiki.
... We'll send out invites.

<manu> Thanks all - great call!

<manu> we actually got around to talking about design and technology! :P

AdrianHB: Please be aware that the IG and th WG have different meeting numbers and different logistics and please let us know where you found the wrong meeting number if you did because we need to fix it.