See also: IRC log
<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
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.