<zkoch> present+ zkoch
— manu Ian - ShaneM got it
— Ian tx :)
→ AjayR joined (~AjayR@public.cloak)
→ Laurent_ joined (~Laurent@public.cloak)
→ Max joined (~textual@public.cloak)
<manu> Topic: Introductions and Agenda Bash
<Ian> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29
<Ian> scribe: Ian
<Ian> [We review updated agenda]
→ VincentK joined (~VincentK@public.cloak)
<MattS> present+ MattS
<Ian> present+ Ian
<alyver> present+ alyver
<VincentK> present+ VincentKuntz
<nick> present+ nick
<VincentK> present+
→ jyrossi joined (~jyrossi@public.cloak)
<nicktr> q?
— Zakim sees no one on the speaker queue
<manu> present+ Manu
<ShaneM> present+ ShaneM
<nicktr> present+ nicktr
→ Roy joined (~Roy@public.cloak)
<adamR> r+
<AdrianHB> present+ AdrianHB
→ lbolstad joined (~lbolstad@public.cloak)
<conorhackett_wp> present+ conorh_wp
<lbolstad> present+
<rouslan> present+ Rouslan
<Nicolas_A_> present+
<Roy> present+ Roy
→ sebsg joined (~sebsg@public.cloak)
→ faraz joined (~Mutter@public.cloak)
<AndreaF> present+ AndreaF
<sebsg> present+ sebsg
⇐ MaheshK quit (~maheshkk@public.cloak): Ping timeout: 180 seconds
<lbolstad> present+ lbolstad
→ Fawad joined (~Fawad@public.cloak)
→ ben joined (~ben@public.cloak)
→ brian_s joined (~brian_s@public.cloak)
<adamR> present+ adamR
<Fawad> +1
<Dongwoo> present+ Dongwoo
→ CyrilV joined (~CyrilV@public.cloak)
<CyrilV> present+ Cyril Vignet
<Ian> Topic: Explainer doc
<Ian> https://w3c.github.io/webpayments/proposals/wparch/
<MattS> note for those that didn't know what a collaboration diagram was from my question in my session yesterday, this is one
<ShaneM> MattS: thanks!
— Ian notes there are 2 diagrams
— Ian assumes figure 3 is the one
<nicktr> q?
— Zakim sees no one on the speaker queue
<nicktr> q?
— Zakim sees no one on the speaker queue
<ShaneM> note that plantuml DOES have some support for this: http://plantuml.com/component.html
— MattS there are 3, the subsequent ones are Sequence diagrams
<Ian> nickTR: I think there is some language alignment that needs to be done.
<Ian> ...by taking it up as a work item we agree we'll work on it
<Ian> ..I'd be interested in getting the perspectives from those relatively new to the group
<Ian> ...was it useful?
<Max> q+
— Zakim sees Max on the speaker queue
<Ian> ...for those of us who would be talking to clients, would this be a useful artifact?
<Ian> ack m
— Zakim sees no one on the speaker queue
<nicktr> q?
— Zakim sees no one on the speaker queue
→ MaheshK joined (~MaheshK@public.cloak)
<Ian> Max: Clarification question - payment options/details/methods are shown as "layers" ... is layering intentional?
<Ian> Manu: No, it was intended as a container
<fdold> q+
— Zakim sees fdold on the speaker queue
<Ian> ...happy to clarify that if desired
<Ian> ack fdold
— Zakim sees no one on the speaker queue
<Ian> Florian: I'm missing here the relationship between the payment request API and the HTTP API
<Ian> Manu: I don't go into that detail in the diagram
<Ian> (In figure 3)
<Ian> ...HTTP API or payment request API can be used to send messages.
<ShaneM> q+ to affirm that an intro like this would be helpful for me when promoting our work
— Zakim sees ShaneM on the speaker queue
<Ian> ...are you saying you'd rather see it mentioned or not?
— nick wonders if we have awoken Cthuhlu from the basement of the Visa building
<Ian> ack sh
<Zakim> ShaneM, you wanted to affirm that an intro like this would be helpful for me when promoting our work
— Zakim sees no one on the speaker queue
<Ian> ShaneM: I talk about our work a lot; I find this useful.
<nicktr> q?
— Zakim sees no one on the speaker queue
<AdrianHB> q?
— Zakim sees no one on the speaker queue
<Ian> ...I would like to use it ... but only if blessed by the group
<AdrianHB> q+
— Zakim sees AdrianHB on the speaker queue
<Dongwoo> +1 to ShaneM
<manu> q+ to suggest strongly as a NOTE in W3C space
— Zakim sees AdrianHB, manu on the speaker queue
<nicktr> Q?
— Zakim sees AdrianHB, manu on the speaker queue
<ShaneM> REQUEST: can we update this https://w3c.github.io/webpayments/
→ huwby joined (~huwby@public.cloak)
<Ian> q?
— Zakim sees AdrianHB, manu on the speaker queue
<Ian> ack AdrianHB
— Zakim sees manu on the speaker queue
<Ian> IJ: I could see this as a Note, or web page, or slide deck
<Ian> ...also, needs to be summary of what we have done, and not claim to be an architecture. Should reflect what we've done.
<Ian> AdrianHB: Agree with Ian on that point
<Ian> ...my concrete proposal is that the WG adopts this as an ED of a Note
<Ian> PROPOSED: Take up the explainer as an ED of a NOTE
<manu> q-
— Zakim sees no one on the speaker queue
<Ian> AdrianHB: It's important to change the title to something like "Web Payments Overview"
<AdrianHB> +1
<manu> +1
<adamR> +1
<AndreaF> +1
<fdold> +1
<conorhackett_wp> +1
<alyver> +1
<Roy> +1
<ShaneM> +1 and I am open to a title
<lbolstad> +1
<rouslan> +1
<Laurent_> +1
<Max> +1
<Dongwoo> +1
<zkoch> +1
<Ian> +0
<Ian> Editors: Nick, Roy, AHB, Manu, Dapeng
<Ian>
<Ian> topic: Payment Method Identifiers
<Ian> PMI spec -> https://www.w3.org/TR/payment-method-id/
⇐ faraz quit (~Mutter@public.cloak): Client closed connection
<Ian> AdrianHB: We want effective matching of PMIs so that the user experience is good and people don't find in practice that there is not a match
<jyrossi> present+ Nicolas_A
<Ian> ...so we are looking at augmenting matching to satisfy these use cases:
<Ian> ===
<Ian> The merchant accepts both Visa Credit and Visa Debit. Merchant wishes to state a different total (what I think I've heard people refer to as "differential pricing") for specific types, most commonly credit vs debit.
<Ian> BigShop accepts many forms of Visa payment except one sub-brand (due to terms and conditions). Merchant wishes to decline a setoff card sub-types, commonly Corporate and high-value purchasing cards.
<Ian> ===
<jyrossi> present+ pirouz
<Ian> AdrianHB: MattS and Ian and I have been looking at this closely; have contemplated a variety of proposals
<Ian> ...various proposals involving more computation by the browser, and other options forcing payment apps to do the work
<nicktr> q?
— Zakim sees no one on the speaker queue
→ faraz joined (~Mutter@public.cloak)
<Nicolas_A_> q+
— Zakim sees Nicolas_A_ on the speaker queue
<nick> q+
— Zakim sees Nicolas_A_, nick on the speaker queue
⇐ brian_s quit (~brian_s@public.cloak): "Page closed"
<AdrianHB> q+ to make a further observation
— Zakim sees Nicolas_A_, nick, AdrianHB on the speaker queue
→ brian_s joined (~brian_s@public.cloak)
<adamR> q+ to comment about “addressing different totals”
— Zakim sees Nicolas_A_, nick, AdrianHB, adamR on the speaker queue
<zkoch> -1 to needing to support second use case right now
<manu> q+ to assert that the current approach supports these use cases and what we're really saying is we want to make this easier for developers.
— Zakim sees Nicolas_A_, nick, AdrianHB, adamR, manu on the speaker queue
<nicktr> q?
— Zakim sees Nicolas_A_, nick, AdrianHB, adamR, manu on the speaker queue
<AndreaF> Issue is that until the card number is entered, you won't know if credit, debit, consumer, commercial... requires a BIN table look-up
— trackbot doesn't understand that ISSUE command.
<brian_s> q+
— Zakim sees Nicolas_A_, nick, AdrianHB, adamR, manu, brian_s on the speaker queue
<Ian> ack Nicolas_A_
— Zakim sees nick, AdrianHB, adamR, manu, brian_s on the speaker queue
<manu> q+ to propose a potential solution
— Zakim sees nick, AdrianHB, adamR, manu, brian_s on the speaker queue
<Ian> Nicolas_A_: On the use cases, the lines of separation between those cards is not debit/credit...could be consumer/commercial, origin of the card,
<zkoch> q+
— Zakim sees nick, AdrianHB, adamR, manu, brian_s, zkoch on the speaker queue
<Ian> ack Nick
— Zakim sees AdrianHB, adamR, manu, brian_s, zkoch on the speaker queue
<Ian> nick: These two use cases aren't quite the same ... the first use case (credit/debit) are two distinct payment instruments
<Ian> ...they are processed differently...
<Ian> ...the second use case (accepting cards from a particular country, or a corporate)
<Ian> ...they are not being processed differently...it's more a property of the card
<Ian> ...I think Manu is right that today these are supported (via payment method identifiers)
<Ian> ...we may not know whether a card is corporate / personal
<Ian> ...I think one is achievable, one is much harder
<AdrianHB> Q+ Huw
— Zakim sees AdrianHB, adamR, manu, brian_s, zkoch, Huw on the speaker queue
<Ian> ack AdrianHB
<Zakim> AdrianHB, you wanted to make a further observation
— Zakim sees adamR, manu, brian_s, zkoch, Huw on the speaker queue
<Ian> AdrianHB: I wanted to observe that a lot of complexity that we are seeing is specific to cards...none of the other payment methods seem to require the same sort of filtering
<Ian> ..for that reason, we may not need to come up with a generic solution today; just solve for cards today and then if other payment methods show similar complexity we deal with it as it arises
<Ian> ...so we may be able to address just cards today and learn for future use cases
<Ian> AdamR: +1 to supporting different total use case
<AdrianHB> q?
— Zakim sees adamR, manu, brian_s, zkoch, Huw on the speaker queue
<Ian> IJ: Support here means "augmented mediator matching algorithm"
<AdrianHB> ack AdamR
<Zakim> adamR, you wanted to comment about “addressing different totals”
— Zakim sees manu, brian_s, zkoch, Huw on the speaker queue
<Ian> Manu: I think we support this now but it's difficult. The sticking point is how to do this. I like what AHB said about focusing on cards for now.
<Ian> ...I am wondering whether all that's missing now is a way to say "not"
<nick> q+
— Zakim sees manu, brian_s, zkoch, Huw, nick on the speaker queue
<ShaneM> q?
— Zakim sees manu, brian_s, zkoch, Huw, nick on the speaker queue
<ShaneM> ack manu
<Zakim> manu, you wanted to assert that the current approach supports these use cases and what we're really saying is we want to make this easier for developers. and to propose a potential
<Zakim> ... solution
— Zakim sees brian_s, zkoch, Huw, nick on the speaker queue
<AdrianHB> Ian: to have not, you need groups
<AdrianHB> q?
— Zakim sees brian_s, zkoch, Huw, nick on the speaker queue
<Ian> Manu: You can define the groups in the card specs
<Ian> ...maybe you can get by with "not" and grouping semantics defined in the spec
<Ian> IJ: You would need the spec to be able to expand over time to catch all the groups
<Ian> Zkoch: I agree with Nick that there are two use cases here (1) credit/debit (2) various branding / subclassing
<Ian> ...I think we should support (1); I am less concerned about (2)
<Ian> ...payment request may not be able to support all the use cases at the tart
<Ian> s/tart/start
→ kriske joined (~kriske@public.cloak)
<Ian> q?
— Zakim sees brian_s, zkoch, Huw, nick on the speaker queue
<kriske> present+ kriske
<Ian> ack brian_s
— Zakim sees zkoch, Huw, nick on the speaker queue
<alyver> +1 to Zach (and Nick)
<Ian> ack zkoch
— Zakim sees Huw, nick on the speaker queue
<Ian> ack Huw
— Zakim sees nick on the speaker queue
<Ian> ack nick
— Zakim sees no one on the speaker queue
<Ian> Nick: Manu asked if we could do this in the basic card spec...I don't think it works for the spec..it doesn't allow for these fields to be identified.
<Ian> ...not sure how we would list different charges
<Ian> ...this comes into play in cases of other payment methods where more information is known up front
<Ian> ...I think this is going to be needed for tokenized schemes
<Ian> NickTR: The payment app could be doing that
<Nicolas_A_> s/origin of the card,/origin of the card, because regulation in the EU gives right to the merchant to decide to surcharge or to refuse such cards. Therefore it is a must have, not a wish have/
<Ian> NickTR: BIN lookups are hard
<Ian> IJ: how are implementers doing this?
<Ian> Nick: For apple pay we get additional information from the network
<Ian> ...we don't get all the information that we've talked about today
— AdrianHB notes that not having in the API doesn't mean it won't work (it just may result in total changing mid flow or the app rejecting the request and the user needing to pick another app)
<AdrianHB> q?
— Zakim sees no one on the speaker queue
<Ian> ..so we'd have to show the different totals in brute form, and that list might be lengthy
<ShaneM> https://en.wikipedia.org/wiki/Payment_card_number
<Ian> NickTR: We will have a breakout on this at noon
<Ian> adrianhb: It sounds like for basic card, as much as we'd like to be able to differentiate on a bunch of dimensions it's not practical due to complexity of analysis.
<Ian> ...so we might only be able to do rudimentary lookup (e.g., of network)
<Ian> ...and we can fall back to the existing behavior which is the payment is rejected after some processing
<AndreaF> I believe this is the domain of the PSPs/ Processors, not the browser's responsibility... BIN tables have to be constantly kept up to date, and be 100% reliable
<nick> …even rudimentary lookup might be wrong. I expect a fair few sites to break when MasterCard moves to the “2” BIN in the fall
<Ian> NickTR: Some sophisticated pages are doing dynamic lookup
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<Ian> Topic: HTTP API/Core messages
<manu> https://docs.google.com/presentation/d/1a3oiG8H4DMTwhC37BnkA-1OJ90NB2WcZQb12VphqVOo/edit#slide=id.p
<Ian> Core messages -> https://w3c.github.io/webpayments-core-messages/
<Ian> HTTP API -> https://w3c.github.io/webpayments-http-api/
<Ian> Manu: Goal is to get to FPWD, or understand concerns
<Ian> manu: Purpose of core messages spec is to understand what messages flow through the system
<nicktr> q?
— Zakim sees no one on the speaker queue
<Ian> ...payment request API is for interactive payments, HTTP API is for non-interactive payments
<Ian> ...core messages spec is split in two: general data model; then some different serialization options
<nicktr> q+
— Zakim sees nicktr on the speaker queue
<kriske> q+
— Zakim sees nicktr, kriske on the speaker queue
<AdrianHB> q?
— Zakim sees nicktr, kriske on the speaker queue
<Laurent_> q+
— Zakim sees nicktr, kriske, Laurent_ on the speaker queue
<AdrianHB> q+ to discuss 402
— Zakim sees nicktr, kriske, Laurent_, AdrianHB on the speaker queue
<Ian> Demo -> * [7 July](https://www.w3.org/2016/07/07-wpwg-minutes)
— Ian s/Demo -> * https://www.w3.org/2016/07/07-wpwg-minutes)
<Ian> /
<Ian> demo -> http://http-mediator-demo.web-payments.io/
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<Ian> Manu: Do we want to publish these documents as FPWDs?
<ShaneM> q?
— Zakim sees nicktr, kriske, Laurent_, AdrianHB on the speaker queue
<Ian> ...one critique of these specs is that they've not had as much attention on them
<Ian> ...an FPWD does not imply agreement to the content by the WG
<Ian> ack ni
— Zakim sees kriske, Laurent_, AdrianHB on the speaker queue
<Max> q+
— Zakim sees kriske, Laurent_, AdrianHB, Max on the speaker queue
<Ian> nickTR: Who was aware of this spec?
<Ian> (just about everyone)
<Ian> NickTR: Who has read it
<Ian> (fewer people)
<Ian> NickTR: Who thinks that there are valuable use cases?
<Ian> (@@ was typing and did not see show of hands for that one@@)
<Ian> ack kriske
— Zakim sees Laurent_, AdrianHB, Max on the speaker queue
<faraz> q+
— Zakim sees Laurent_, AdrianHB, Max, faraz on the speaker queue
<AdrianHB> q+ Faraz
— Zakim sees Laurent_, AdrianHB, Max, faraz on the speaker queue
<Ian> q?
— Zakim sees Laurent_, AdrianHB, Max, faraz on the speaker queue
<Ian> Kriske: How close is message to ISO20022?
<Ian> Manu: That is a "native payment message" so it would be whatever is called for
<Ian> Kriske: How will the resource be defined? As an ISO20022 structure? Or something proprietary?
<Ian> Manu: This diagram is just one example; you can have other flows
<Ian> ...the question is for steps 9 and 10, who is defining and executing that?
<nicktr> q?
— Zakim sees Laurent_, AdrianHB, Max, faraz on the speaker queue
<Ian> I think 9 and 10 are out of scope for this group
<nicktr> q+
— Zakim sees Laurent_, AdrianHB, Max, faraz, nicktr on the speaker queue
<Ian> Manu: I would expect it would be native to whatever payment network it's submitted to
<Ian> Kriske: The reason I ask is that there are constraints imposed by the payment network
<Ian> ...if these pieces of information are not properly structured, the payment will fail
<Ian> ..it would be interesting for this proposal to take into account those requirements
<Ian> ...ISO20022 has taken that into account
<AdrianHB> q?
— Zakim sees Laurent_, AdrianHB, Max, faraz, nicktr on the speaker queue
<Ian> Manu: The assumption here is that the payment method that is used will ensure that it collects the right pieces of information so that when it hits the payment network it is ready to go
<Ian> ack Laurent
— Zakim sees AdrianHB, Max, faraz, nicktr on the speaker queue
<Ian> Laurent_: Do you take into account payment method extensibility?
<Ian> ...also do you have a push model for message 3 and 4?
<Ian> q- nicktr
— Zakim sees AdrianHB, Max, faraz on the speaker queue
<Ian> Manu: We don't have a push use case and have not focused on it...but we could put it in there.
<AdrianHB> q?
— Zakim sees AdrianHB, Max, faraz on the speaker queue
<Ian> ...regarding extensibility, we handle it the same way the browser API spec does; there is a catch-all bucket for extra params
<Ian> Laurent: Do payment methods have to define something beyond what they do today to work with this API?
<Ian> Manu: By design it should just work
<jyrossi> q+
— Zakim sees AdrianHB, Max, faraz, jyrossi on the speaker queue
<nicktr> ack AdrianHB
<Zakim> AdrianHB, you wanted to discuss 402
— Zakim sees Max, faraz, jyrossi on the speaker queue
<jyrossi> q-
— Zakim sees Max, faraz on the speaker queue
<Ian> AdrianHB: I made the comment yesterday that we should pursue payment request API and HTTP API independently and as we see opportunities to align we do that. Is it your expectation that Core messages will be the vehicle for keeping up to date?
<Ian> Manu: Yes
<Ian> AdrianHB: The HTTP 402 use case is interesting.
<nicktr> q?
— Zakim sees Max, faraz on the speaker queue
<Ian> ...we should decide whether we want to use this spec as a way to respond to 402
<Ian> ...other activity in this space e.g., cryptocurrency folks
<Ian> Manu: Had some discussion with Mark Nottingham about this...some pushback
<AdrianHB> q?
— Zakim sees Max, faraz on the speaker queue
<Ian> ...there would be need for more discussion with IETF
<Ian> q+
— Zakim sees Max, faraz, Ian on the speaker queue
<Ian> Max: What is the security mechanism?
<Ian> Manu: I assume it would be the same as used by the browser; right now seems to be HTTPS
<Ian> ..the HTTP API is following browser API (currently no signatures)
<Ian> Max: What payment methods can you use?
<Ian> Manu: Whatever payment method you want, as defined by the payment method specs
<Ian> Max: Step #5....select payment app...is that interaction?
<Ian> Manu: It's meant to be non-interactive...you could imagine some interaction (e.g., from the command line) but in general the HTTP Api is intended for non-interactive use cases...so #5 takes place automatically based on previous configurations
<Ian> Max: In step #11, what happens if message does not reach the mediator?
⇐ nick quit (~nick@public.cloak): nick
<Ian> Manu: Right now that's out of scope
<AdrianHB> q?
— Zakim sees Max, faraz, Ian on the speaker queue
<Ian> ...up to mediator...different approaches might be taken
<AdrianHB> ack max
— Zakim sees faraz, Ian on the speaker queue
<Ian> ...I think that group has this question for the work we are doing
<Ian> ack faraz
— Zakim sees Ian on the speaker queue
— Ian rrasgent, make minutes
<Roy> Is it a fair summary that the HTTP API is the same as the PaymentRequest api spec, but where we have truly generalized payment mediator to just anything that can speak HTTP?
<AdrianHB> yes
<Ian> faraz: You are saying the HTTP API spec should support payment methods ... how would something like paypal work non-interactively?
<Ian> Manu: Good point; if the payment method itself does not support automatic payments, then you could not achieve fully automatic payments
<Ian> faraz: The same applies to entry of PAN
<Max> q+
— Zakim sees Ian, Max on the speaker queue
<Ian> ....I am hearing you say that unless PAN has been previously entered, this would not work
<Ian> Manu: Correct
<ShaneM> q?
— Zakim sees Ian, Max on the speaker queue
<Roy> q+
— Zakim sees Ian, Max, Roy on the speaker queue
<Ian> NickTR: PISPs in europe are leading us toward APIs for initiation of payment...you will be able to store credentials to allow transactions to be initiated
<AdrianHB> q?
— Zakim sees Ian, Max, Roy on the speaker queue
<ShaneM> q+ to point out that there is an opportunity to use this even in a paypal model via "subscriptions"
— Zakim sees Ian, Max, Roy, ShaneM on the speaker queue
<AdrianHB> ian: what is the current state of implementor interest?
<faraz> q+
— Zakim sees Ian, Max, Roy, ShaneM, faraz on the speaker queue
<AdrianHB> manu: I can't talk abotu some implementors (we are under NDA) but I hope that if we put this out to FPWD I hope they will come forward
<AdrianHB> nicktr: WorldPay are working on this in our IoT architecture
<AdrianHB> q?
— Zakim sees Ian, Max, Roy, ShaneM, faraz on the speaker queue
<Ian> ack Ian
— Zakim sees Max, Roy, ShaneM, faraz on the speaker queue
<Ian> ack Max
— Zakim sees Roy, ShaneM, faraz on the speaker queue
<faraz> Support for Tokenisation plus trid in core messages
<Ian> Max: For the paypal use case, in this diagram I think the payee and the payment network are together
<Ian> ...so the message #3 and #4 will be very payment method specific
<Ian> ...3 and 4 may not be able to be simple HTTP POST...might require some additional parameters (e.g., credentials)
<Roy> q-
— Zakim sees ShaneM, faraz on the speaker queue
<Ian> NickTR: Note that 3 and 4 is simply the creation of the payment request...the problem with the diagram in the spec is that it just represents pull payments
<Ian>
— Ian rrsagent, make minutes
→ nick joined (~nick@public.cloak)
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<AdrianHB> q?
— Zakim sees ShaneM, faraz on the speaker queue
<Ian> ack shane
<Zakim> ShaneM, you wanted to point out that there is an opportunity to use this even in a paypal model via "subscriptions"
— Zakim sees faraz on the speaker queue
<Ian> zakim, close the queue
<Zakim> ok, Ian, the speaker queue is closed
<Ian> ack faraz
— Zakim sees no one on the speaker queue
<Ian> faraz: The diagram shows a tokenized response...I wanted to raise a point that the diagram as shown today does not support tokenization...
<Ian> Manu: That's an aspiration; not enforced by the spec
<AdrianHB> q?
— Zakim sees no one on the speaker queue
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<Ian>
<AdrianHB> ian: to go to FPWD we trigger a formal patent policy process. Because it will become listed in a more formal register of docs it will have more links to it. There are some procedural issues the WG must follow to publish.
<Ian> q+
— Zakim whispers to Ian that the speaker queue has been closed
<AdrianHB> zakim, open the queue
<Zakim> ok, AdrianHB, the speaker queue is open
<AdrianHB> ian: I want to talk about relative priority of this vs other work. We have agreed that the priority of this sits below Payment Request and Payment App. Given the implementation state I want to make sure, even though this is in scope we need to make sure we do still assign our time appropriately
<Ian> zakim, open the queue
<Zakim> ok, Ian, the speaker queue is open
<Ian> NickTR: Show of hands whether you would likely be supportive of a call for consensus
<Laurent_> +1
<Ian> (Which will happen formally with a 1-week window)
<AndreaF> +1
<adamR> +0
<conorhackett_wp> +1
<ShaneM> +1 and agree that the chairs need to manage priorities
<AdrianHB> +1
<kriske> +1
<alyver> +1
<zkoch> +0
<manu> +1 to issue call for consensus on HTTP API and Core Messages
<Roy> 0, still working to understand how it fits in
— manu for publishing
<nick> +0
<rouslan> +0 does not seem to affect browsers
<jyrossi> +1
<Nicolas_A_> +0
<MattS> +1
<Ian> (No +1's or -1's by hand in the room)
<Ian> +0
<VincentK> +1
— adamR (I’m slightly more negative than just a 0, as I worry that, even with our priorities, this will take unnecessary cycles right now)
<MaheshK> +0
<AndreaF> Yes, useful to clarify push payments too
<Ian> AdrianHB: I am hearing there is a desire for more clarity around push payments, and also a fix to the tokenization ambiguity
<pirouz> +0
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<ben> +1
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
⇐ Nicolas_A_ quit (~Nicolas_A_@public.cloak): "Page closed"
→ Nicolas_A_ joined (~Nicolas_A_@public.cloak)
⇐ Nicolas_A_ quit (~Nicolas_A_@public.cloak): "Page closed"
<AndreaF> Could we please clarify the breakouts? Seems you have combined a few?
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
→ alyver joined (~andrelyver@public.cloak)
⇐ zkoch quit (~zkoch@public.cloak): "zzz..."
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
⇐ Max quit (~textual@public.cloak): "My Mac has gone to sleep. ZZZzzz…"
⇐ faraz quit (~Mutter@public.cloak): Client closed connection
⇐ fdold quit (~fdold@public.cloak): Ping timeout: 180 seconds
⇐ adamR quit (~adamR@public.cloak): "AFK"
⇐ sebsg quit (~sebsg@public.cloak): Ping timeout: 180 seconds
→ adamR joined (~adamR@public.cloak)
⇐ Roy quit (~Roy@public.cloak): Ping timeout: 180 seconds
⇐ lbolstad quit (~lbolstad@public.cloak): Ping timeout: 180 seconds
⇐ pirouz quit (~pirouz@public.cloak): Ping timeout: 180 seconds
⇐ ben quit (~ben@public.cloak): Ping timeout: 180 seconds
→ sebsg joined (~sebsg@public.cloak)
⇐ nick quit (~nick@public.cloak): nick
⇐ MaheshK quit (~MaheshK@public.cloak): Ping timeout: 180 seconds
→ MaheshK joined (~MaheshK@public.cloak)
⇐ MattS quit (~MattS@public.cloak): Ping timeout: 180 seconds
⇐ CyrilV quit (~CyrilV@public.cloak): Ping timeout: 180 seconds
→ nick joined (~nick@public.cloak)
→ faraz joined (~Mutter@public.cloak)
⇐ faraz quit (~Mutter@public.cloak): Client closed connection
→ alyver joined (~andrelyver@public.cloak)
⇐ rouslan quit (~5190e1d6@public.cloak): Ping timeout: 180 seconds
<ShaneM> AdrianHB: does this address your push concern? https://w3c.github.io/webpayments-http-api/#h-issue10
<AdrianHB> shanem - I think we should show a push flow. The current use case flow is being interpreted as the overall flow
<ShaneM> AdrianHB: I agree - I just wanted to capture the issue for now.
<AdrianHB> works for me
→ Max joined (~textual@public.cloak)
<ShaneM> (I will go off and try to draw a pretty picture - or invite Max to help!)
<Max> Glad to help.
<AndreaF> Could you please add the link to the photo here? Thanks :)
<nick> +1 for photo
→ MattS joined (~MattS@public.cloak)
<nicktr> scribenick: nicktr
→ zkoch joined (~zkoch@public.cloak)
→ ben joined (~ben@public.cloak)
→ CyrilV joined (~CyrilV@public.cloak)
<nicktr> subject: Testing strategy
<CyrilV> present+ Cyril_Vignet
<nicktr> shaneM: we're writing tests that should run 'forever'
<nicktr> ...CR means we have to show our specification can run in at least two implementations
<nicktr> ...payment request API is important as it has the momentum
<nicktr> ...core messages and vocabulary
<nicktr> ...HTTP API
<nicktr> ...app registration
<nicktr> ShaneM: introducing web platform tests framework
<nicktr> ...one of the nice bits is automated reporting
<nicktr> ...but I need help to develop a stubbed payment applicatoin
<nicktr> ...so that we can test flows
<nicktr> ...the way to do this is -manual.html files which are automatable via webdriver
<nicktr> ...for the .js api
<nicktr> q?
— Zakim sees no one on the speaker queue
<Max> q+
— Zakim sees Max on the speaker queue
<nicktr> ...HTTP API is easily automatable
<AdrianHB> scribenick: adrianhb
<AdrianHB> shanem: The WPT framework is very customizable
<AdrianHB> ... allows backend comms to check message integrity
<AdrianHB> [talking through helpful diagram]
<AdrianHB> ... automateable through Selenium or Webdriver
<nicktr> ack Max
— Zakim sees no one on the speaker queue
<AdrianHB> ... we should right enough to get good coverage but not too many so that its onerous to maintain
<AdrianHB> max: we are working on testing. In the CG we are trying to add the concept of API versioning. Is that a feature we are interested in?
<Ian> https://www.w3.org/community/awpat/
<Ian> Advancing Web Platform Application Testing Community Group
<AdrianHB> shanem: yes, would great
<AdrianHB>
— Ian sees Max in that CG
— Ian and JiaJia
<AdrianHB> ... really is simple
— Ian ah no, wrong
<AdrianHB> ... built in support for taking in WebIDL and test interfaces
<Ian> q?
— Zakim sees no one on the speaker queue
<Ian> q+
— Zakim sees Ian on the speaker queue
<Max> ADVANCING WEB PLATFORM APPLICATION TESTING COMMUNITY GROUP
<AdrianHB> ... WPT has recently been extended to support testing JSON messaging which we need
— Ian tx
<Max> https://www.w3.org/community/awpat/
<AdrianHB> [The Plan]
<adrianba> Example of testharness.js tests
<AdrianHB> shanem: ceating the buckets that the tests will go into (a framework)
<AdrianHB> ... need help developing a skeleton payment app
<Ian> q-
— Zakim sees no one on the speaker queue
<AdrianHB> ... longer term we will work app and API devs to ensure the tests are ready when we get tp CR
<AdrianHB>
— nicktr didn't realise specs could go backwards
<AdrianHB> ... tests should have clear explanations
<AdrianHB>
<AdrianHB> ... shows javascript behind test
<AdrianHB> ... this example shows an async test
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<AdrianHB> ... test calls done() when it's finished
<AdrianHB> ... lots of primitives for us to use
<AdrianHB>
<AdrianHB>
<Ian> agenda?
— Zakim sees 2 items remaining on the agenda:
— Zakim 1. Bootstrapping the ecosystem
— Zakim 2. PMIs (grouping and bootstrapping)
<Ian> zakim, clear agenda
<Zakim> agenda cleared
⇐ MattS quit (~MattS@public.cloak): Ping timeout: 180 seconds
<AdrianHB> shanem: there is a PR to add more output meta-data
<AdrianHB>
<AdrianHB>
<AdrianHB> ... for each test there are sub tests which show sub test results from each tested implementation
<AdrianHB> ... this is pushed up by the implementors (presumeably from their CI)
→ Roy joined (~Roy@public.cloak)
<nicktr> q?
— Zakim sees no one on the speaker queue
<AdrianHB> ... we need 2 passing implementations to get to CR
<AdrianHB>
<AdrianHB> ... stable spec means less changes to tests
<AdrianHB> ... need peer reviews of tests
<AdrianHB> nicktr: analogous to a spec editor?
<Max> q+
— Zakim sees Max on the speaker queue
<AdrianHB> shanem: no, it's enough to understand the test (i.e. not just being an editor)
<AdrianHB> ... my job is manage the infrastructure. I hope we get volunteers to write tests
<AdrianHB> q?
— Zakim sees Max on the speaker queue
<manu> q+ to ask how we tie in different merchant and payment app servers?
— Zakim sees Max, manu on the speaker queue
<AdrianHB> max: I volunteer to review tests!
<AdrianHB>
→ rouslan joined (~5190e1d6@public.cloak)
<AdrianHB> nicktr: I suspect that testing needs some people on the ground to do work, are there any other volunteers?
<AdrianHB> manu: DigitalBazaar will provide some resources
<AdrianHB> zkoch: we already have some tests in Chromium. We'll port them over
<AdrianHB> roy: We will also help review
<AdrianHB> shanem: after we have finalised payment apps we'll have a better idea of what to test
<AdrianHB> ... if there isn't wide support for payment apps then this architecture obviously won't work
<AdrianHB> ... if that's not true I'd appreciate help on correcting my assumptions
<Ian> q?
— Zakim sees Max, manu on the speaker queue
<AdrianHB> nicktr: thanks Shanem
<Ian> ack max
— Zakim sees manu on the speaker queue
<AdrianHB> ack max
— Zakim sees manu on the speaker queue
<AdrianHB> manu: general question. It looks like we have a number of conforming systems to test (app, mediator, etc) Do we plan to allow testing of all systems?
<nicktr> link to this presentation: -> https://docs.google.com/presentation/d/1zxqJfXcJR6hH74wYlBTzwNMSoQFUFYmqqeKlFec4LNM/pub?start=false&loop=false&delayms=3000&slide=id.g1156a10a0d_0_107
<AdrianHB> shanem: we are testing the interfaces we standardize. How we do this is interesting
<nicktr> today's agenda -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda
— nicktr I'll edited into existing F2F page
<AdrianHB> ... some systems in this architecture have non-standard interfaces so we'd not expect to test those interfaces but we could include these in end-to-end tests
<AdrianHB> q?
— Zakim sees manu on the speaker queue
<nicktr> q?
— Zakim sees manu on the speaker queue
<AdrianHB> ack manu
<Zakim> manu, you wanted to ask how we tie in different merchant and payment app servers?
<nicktr> ack MaheshK
— Zakim sees no one on the speaker queue
— Zakim sees no one on the speaker queue
→ fdold joined (~fdold@public.cloak)
→ faraz joined (~Mutter@public.cloak)
<manu> q+ to note that failure during pull payment is still bad.
— Zakim sees manu on the speaker queue
→ MattS joined (~MattS@public.cloak)
<zkoch> q+
— Zakim sees manu, zkoch on the speaker queue
→ lbolstad joined (~lbolstad@public.cloak)
<lbolstad> present+ lbolstad
<Max> q+
— Zakim sees manu, zkoch, Max on the speaker queue
<Ian> Discussion of -> https://github.com/w3c/browser-payment-api/issues/224
<Ian> scribe: Ian
<faraz> +1 on a correlation id
<Ian> Roy: You can solve this on a per payment app basis, but the additional complexity from the merchant perspective
<Ian> ...I hope a driver of adoption is that I can do a small number of integrations and let apps evolve without a lot more integration
<Ian> ..if we have no structure around this, we will end up with one implementation by the merchant per payment app and that's not ideal
<Ian> q
<Ian> q/
<Ian> ack z
— Zakim sees manu, Max on the speaker queue
<manu> ack manu
<Zakim> manu, you wanted to note that failure during pull payment is still bad.
— Zakim sees Max on the speaker queue
<Ian> zkoch: We run into a problem that once you've handed control to the payment app , you don't have a consistent channel for handling this...that complicates implementation (e.g., on mobile platforms)
<Laurent_> q+
— Zakim sees Max, Laurent_ on the speaker queue
<Ian> ...I think payment request API is to help with UX and bring new payment methods to the web.
<Ian> ...it is the channel for more secure payment methods
<Ian> ...but it's not been the case that this would mean there's no backend integration
<Ian> ...I understand your point about easier merchant integration, but I don't think we'll see that quickly
<Ian> ...I think the architectural limitation is something we need to consider if we were to adopt something like this
<nicktr> q?
— Zakim sees Max, Laurent_ on the speaker queue
<Ian> Max: I support this idea.
<Ian> ack Max
— Zakim sees Laurent_ on the speaker queue
<nicktr> ack Max
— Zakim sees Laurent_ on the speaker queue
<AdrianHB> q+ to get some clarity on the value of a generic push payment method
— Zakim sees Laurent_, AdrianHB on the speaker queue
<Ian> Max: This is an interesting problem and I think the WG should spend time thinking about it.
⇐ Max quit (~textual@public.cloak): "My Mac has gone to sleep. ZZZzzz…"
<Ian> ..I'm happy to work with Roy on this
<Ian> ack L
→ Max joined (~textual@public.cloak)
— Zakim sees AdrianHB on the speaker queue
<Ian> Laurent: In the SEPA payment method, we identified the same issue
<Ian> ...we were leaning toward a slightly different solution...to use an out-of-band HTTP callback (identified via a URL in the payment request)
<Ian> ...this allows the server or payment app to provide confirmation to the merchant directly
<Ian> Roy: That could work too. Mainly what I am looking for is something in the spec instead of proprietary solutions in each app
<Ian> q?
— Zakim sees AdrianHB on the speaker queue
<Ian> ack AdrianHB
<Zakim> AdrianHB, you wanted to get some clarity on the value of a generic push payment method
— Zakim sees no one on the speaker queue
<Ian> adrianhb: The idea of a generic push payment spec that could be used by multiple third-party payments (e.g., Alipay) where the app (or server) processes the payment....it sounds like a good idea but I haven't figured out whether it would be useful.
<Ian> ...if we decide there's a common way to do this (e.g., callback, signature, transaction id)
<Ian> ...what value is there in these payment methods sharing a common payment method identifier.
<manu> q+ to say they don't need to share an identifier - there is benefit in sharing the mechanism and spec'ing that out.
— Zakim sees manu on the speaker queue
<Ian> ack manu
<Zakim> manu, you wanted to say they don't need to share an identifier - there is benefit in sharing the mechanism and spec'ing that out.
— Zakim sees no one on the speaker queue
⇐ faraz quit (~Mutter@public.cloak): Client closed connection
<Ian> AdrianHB: Should this be "best practice" or in the spec?
<Ian> NickTR: We could learn from specific instances
<Ian> AdrianHB: But it doesn't solve the problem of "one payment method per payment app" that Roy raised
<Ian> Manu: I think there's an incremental step we could take.
<Laurent_> +1 to not sharing the identifier but standardizing the mecahnism
<Ian> ...I think there's value in standardizing the mechanism...e.g., best practice
→ faraz joined (~Mutter@public.cloak)
<faraz> q+
— Zakim sees faraz on the speaker queue
<Ian> ...spec it out "If you want to verify the payment went through, do this"
<Ian> AdrianHB: So that does not solve the fragmentation issue
<Laurent_> q+
— Zakim sees faraz, Laurent_ on the speaker queue
<Ian> Manu: That's ok (for now)
<AdrianHB> q+ to mention open schemes
— Zakim sees faraz, Laurent_, AdrianHB on the speaker queue
→ porouz joined (~porouz@public.cloak)
<manu> q+ to mention that you could do both, see what the market decides
— Zakim sees faraz, Laurent_, AdrianHB, manu on the speaker queue
<manu> q-
— Zakim sees faraz, Laurent_, AdrianHB on the speaker queue
<Ian> zakim, close the queue
<Zakim> ok, Ian, the speaker queue is closed
<Ian> ack faraz
— Zakim sees Laurent_, AdrianHB on the speaker queue
→ Lauren_Jones joined (~Lauren_Jones@public.cloak)
<Ian> Faraz: I want to echo what Manu said..instead of creating a generic spec or collecting various payment methods...I think a concrete example is better.
<Ian> ..make it a non-mandatory guidance
<Ian> q?
— Zakim sees Laurent_, AdrianHB on the speaker queue
<Ian> ...or any status information...
<Ian> ack L
— Zakim sees AdrianHB on the speaker queue
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<Ian> Laurent: The problem is not so much fragmentation on the payment app side, the problem is integration cost for merchant
<Ian> ...so you help the merchant if you provide a generic way to handle the response
<Ian> ack AdrianHB
<Zakim> AdrianHB, you wanted to mention open schemes
— Zakim sees no one on the speaker queue
<Ian> adrianhb: I think what's great about this conversation is that it's crystalized some water cooler discussion
<Ian> ...we've treated payment methods as "universal" to date but we recognize that there are also 1-1 mapping of payment method to payment app
<Ian> ...compare those with the "open" payment schemes, where there are standards that enable anyone to write a payment app
<nicktr> q?
— Zakim sees no one on the speaker queue
<Ian> ...I think that one of the things that might have spurred this is the cryptocurrency world...there will be a bunch of payment apps
<Ian> ..there is an incentive to create a standard to be able to do bitcoin payments from a variety of apps
<Ian> ...I think the bottom line is that we support both of these use cases
<Ian> ...that is "open" and "proprietary" payment methods
<Ian> ...this connects to the comment zach made yesterday about user protection ... and whether we provide a way for browsers to protect users against apps from non-mandated distributors
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<Ian> [Break]
⇐ zkoch quit (~zkoch@public.cloak): "zzz..."
⇐ adamR quit (~adamR@public.cloak): "AFK"
⇐ nick quit (~nick@public.cloak): nick
⇐ faraz quit (~Mutter@public.cloak): Client closed connection
⇐ Lauren_Jones quit (~Lauren_Jones@public.cloak): Ping timeout: 180 seconds
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
→ alyver joined (~andrelyver@public.cloak)
→ adamR joined (~adamR@public.cloak)
⇐ fdold quit (~fdold@public.cloak): Ping timeout: 180 seconds
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
⇐ Max quit (~textual@public.cloak): "My Mac has gone to sleep. ZZZzzz…"
⇐ Roy quit (~Roy@public.cloak): Ping timeout: 180 seconds
⇐ Laurent_ quit (~Laurent@public.cloak): Ping timeout: 180 seconds
→ Max joined (~textual@public.cloak)
→ alyver joined (~andrelyver@public.cloak)
⇐ jyrossi quit (~jyrossi@public.cloak): Ping timeout: 180 seconds
⇐ Max quit (~textual@public.cloak): "My Mac has gone to sleep. ZZZzzz…"
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
→ alyver joined (~andrelyver@public.cloak)
⇐ AjayR quit (~AjayR@public.cloak): Ping timeout: 180 seconds
⇐ ben quit (~ben@public.cloak): Ping timeout: 180 seconds
⇐ MattS quit (~MattS@public.cloak): Ping timeout: 180 seconds
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
⇐ lbolstad quit (~lbolstad@public.cloak): Ping timeout: 180 seconds
⇐ CyrilV quit (~CyrilV@public.cloak): Ping timeout: 180 seconds
→ alyver joined (~andrelyver@public.cloak)
⇐ huwby quit (~huwby@public.cloak): "Page closed"
⇐ nicktr quit (~nicktr@public.cloak): Ping timeout: 180 seconds
⇐ adamR quit (~adamR@public.cloak): "AFK"
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
→ alyver joined (~andrelyver@public.cloak)
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
⇐ conorhackett_wp quit (~conor@public.cloak): conorhackett_wp
⇐ brian_s quit (~brian_s@public.cloak): Ping timeout: 180 seconds
⇐ VincentK quit (~VincentK@public.cloak): Ping timeout: 180 seconds
⇐ porouz quit (~porouz@public.cloak): Ping timeout: 180 seconds
→ zkoch joined (~zkoch@public.cloak)
→ lbolstad joined (~lbolstad@public.cloak)
<lbolstad> present+ lbolstad
→ conorhackett_wp joined (~conor@public.cloak)
→ fdold joined (~fdold@public.cloak)
→ adamR joined (~adamR@public.cloak)
→ nick joined (~nick@public.cloak)
→ Max joined (~textual@public.cloak)
⇐ nick quit (~nick@public.cloak): Client closed connection
⇐ kriske quit (~kriske@public.cloak): Ping timeout: 180 seconds
→ ben joined (~ben@public.cloak)
→ Roy joined (~Roy@public.cloak)
→ nick joined (~nick@public.cloak)
→ MattS joined (~MattS@public.cloak)
→ faraz joined (~Mutter@public.cloak)
— Ian Mahesh, we are getting you a dial-up
→ nicktr joined (~nicktr@public.cloak)
<manu> Topic: Breakout Review
<manu> scribe: manu
→ CyrilV joined (~CyrilV@public.cloak)
<manu> AdrianHB: We redid how apps initiate payment - add listeners, receive payment request, we're going away from HTTP-based invocation. We will probably use postMessage-like mechanism to POST back to browser.
→ brian_s joined (~brian_s@public.cloak)
<Ian> q+
— Zakim whispers to Ian that the speaker queue has been closed
<manu> AdrianHB: Within Javascript you can achieve most anything else - what we didn't answer, what happens when Javascript is not downloadable at the time that PaymentRequest is made. We may not specify that, but we didn't actually get into discussing that. That's invocation.
<Ian> zakim, open the queue
<Zakim> ok, Ian, the speaker queue is open
<manu> Ian: Why give a link to Javascript instead of Javascript?
→ alyver joined (~andrelyver@public.cloak)
<nicktr> conference call is now open
⇐ faraz quit (~Mutter@public.cloak): Client closed connection
→ pirouz joined (~pirouz@public.cloak)
<nicktr> international calling numbers can all be found here -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda
— Dongwoo nicktr, thanks
<nicktr> sorry - wrong paste buffer
<manu> AdamR: WebRTC is a derived URI - use the domain portion to form a URL on a .well-known path - it's not exactly the same thing, you're not literally passing the javascript.
→ AjayR joined (~AjayR@public.cloak)
<nicktr> international calling numbers can all be found here -> https://www-emea.intercallonline.com/listNumbersByCode.action?confCode=875114&area=viewNumber
<manu> AdrianHB: We had another discussion around display options - current proposal talks about what payment apps support without enrollment, already have ability to process payment w/o enrollment.
<nicktr> conference number is 875114
<Ian> q+
— Zakim sees Ian on the speaker queue
<manu> AdrianHB: Designed to be able to prompt user to provide cards that may be enrolled. We decided to split between "active payment methods" and "enrollable payment methods"
<manu> AdrianHB: If browser knows that you have an enrollable payment method, it could provide it as an option. If user has to go through enrollment flow - merchant can decide to not give customer the option.
<nicktr> ack Ian
— Zakim sees no one on the speaker queue
<Ian> Ian: We should consider all these states together: (1) ready to use (2) installed but needs credentials (3) not yet installed
<nicktr> agenda -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda
<manu> Ian: It may be worth considerting 3 states of payment app - ready to use, ready to add credentials to, ready to be installed. If site says "I take PayPal", and browser knows that payment app could enroll.
<manu> s/enroll./enroll, then PayPal could be enrolled./
<manu> AdrianHB: Proposal is for group to take this up - proposal for payment apps API in browser
<manu> AdrianHB: The spec will be adopted as an editor's draft in its current form, with issues and new editors added.
<Ian> Editors to add: Lauren, Ian
<Ian> PROPOSED: Take up the payment app spec as a WG deliverable (with current editors + Laurent + Ian)
<ShaneM> +1
<conorhackett_wp> +1
<manu> +1
<lbolstad> +1
<AndreaF> +1
<adamR> +1
<MattS> +1
<Ian> +1
<MaheshK> +1
<Roy> +1
→ Laurent_ joined (~Laurent@public.cloak)
<Dongwoo> +1
<Laurent_> +1
<rouslan> +1
<zkoch> +…0
<Ian> (No signs of hand in the room; just IRC +1s)
<pirouz> +1
→ kriske joined (~kriske@public.cloak)
<manu> Topic: Payment Method Identifiers Breakout
<kriske> present+ kriske
→ jyrossi joined (~jyrossi@public.cloak)
<CyrilV> present+ Cyril_Vignet
<jyrossi> present+ jyrossi
<manu> Ian: There is more work to do, problem statement was trying to accommodate things like different totals, payment method identifiers. The sense from the ad-hoc conversation was that it is going to be important to provide constraints, strong agreement wrt. credit/debit switch - clear agreement on that one, figuring out how to express those so that browser can take into account what merchant says they accept.
<manu> Ian: How can payment apps express those things on their end, there are more conversations that need to happen. A second piece was a deeper problem of merchant adoption of the API.
→ adamR_ joined (~adamR@public.cloak)
⇐ adamR quit (~adamR@public.cloak): Client closed connection
<manu> Ian: For some payment methods, merchants know enough about the PayPal experience to trust passing off the experience to that third party. it's possible to have an open ended ecosystem of apps that provide responses for a given payment method and that may raise trust issues for merchants. That may lead to bad experiences or conversation problems.
* adamR_ is now known as adamR
→ AndreaF_ joined (~AndreaF@public.cloak)
<manu> Ian: One thought, in the same way that merchants could express what they like as payment apps, those preferences could take that into account as well. if Merchant says "I will take the Wells Fargo payment app"
<manu> Ian: The more complex the constraint algorithm and ecosystem, the harder time apps will have to be able to do that well.
<manu> Ian: Concretely, what would need to happen in the PaymentRequest API to have a constraint-based mechanism. I would assume people that have been working on this - people will meet to work on this.
<manu> NickTR: Aggregated payment session - good robust conversation.
⇐ AndreaF quit (~AndreaF@public.cloak): Ping timeout: 180 seconds
<manu> NickTR: When we took a step back, we came to an insight on 3 pieces of information: scheme identifier, payer identifier, payee identifier. Why is it possible to do cards, but not possible to do push as generic payment methods. Fundamentally, there is a controlling organization for the payer identifier - it's ISO - they give out BINs, BIN controllers can issue identifiers in those namespaces
<manu> NickTR: What happens when things break? What's the behavior, whose left holding the problem? Where does the problem lay when things break. Cross product of apps and methods - how do you solve for that - how do you know if app can support the method - multiiple apps to support. The only way you can initiate a PayPal payment without going through a PayPal app. You can initiatie a Visa payment through a multitude of apps.
<manu> NickTR: It took us a long bit of time to synthesize those items - we were wondering about best practice - how to form payment method specifications - write something generic or abstract like cards - and when are we going to need specific instances - good news is that we have good volunteers to work on this. Define some things that need to be there, for example, you could build Visa payment method w/ cards interface. You could do it that way, or you could do it con
<manu> crete implementations - actually implement basic card as a spec, then apply restrictions - covers a multitude of specific payment methods.
<manu> NickTR: All of these are legitimate approaches, what are the pros and cons - we need to be able to bootstrap this ecosystem - describe an interface for multiwallets - but you'd never be able to send 3rd party payment wallet to something else - we need pros and cons and then try to get guidance on when to use those things.
<manu> AdrianHB: We have a good chunk of volunteers for this work - don't know if this is orthogonal to payment identifiers - we're sort of circleing around the same sort of issues.
→ jiajia joined (~uid173101@public.cloak)
<manu> Ian: My sense is that they're mostly orthogonal, if we want to establish best practice - if there are cases we want to solve real fast right now. Since we've identified a weird problem, we don't need to work on best practices for those.
<AdrianHB> q?
— Zakim sees no one on the speaker queue
<manu> Ian: There had to do with payment app identification - don't know if that's a best practice thing.
<manu> NickTR: We have a coalition of the willing to work on these items right now.
— Ian rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<manu> Ian: My expectation on payment method identifiers, we'll try to work with everyone to figure out what this would look like practically speaking - with Microsoft, Google, and Apple.
<MattS> q+
— Zakim sees MattS on the speaker queue
<manu> Adrianba: Our conversation was broader than this - had to do with how to converge.
<nicktr> Coalition of the willing on that payment methods "best practice" task force included Dapeng, Lauren, Nick TR, Matt S, Faraz, Jean-Yves
<nicktr> q?
— Zakim sees MattS on the speaker queue
<nicktr> ack MattS
— Zakim sees no one on the speaker queue
<nick> q+
— Zakim sees nick on the speaker queue
<jyrossi> q+
— Zakim sees nick, jyrossi on the speaker queue
<manu> MattS: I'm wondering, since we're trying to solve the same problem here - two groups - how to serve the long term and how to serve the short term. I'm concerned that we have a large group and it'll be hard to make progress.
<AdrianHB> q+ to suggest concrete progress for cards
— Zakim sees nick, jyrossi, AdrianHB on the speaker queue
<nicktr> ack nick
— Zakim sees jyrossi, AdrianHB on the speaker queue
→ Lauren_Jones joined (~Lauren_Jones@public.cloak)
<manu> NickS: One of the concerns that we had was that we could come up with a short term approach that's not sustainable for long term - we want to be able to share payment method descriptions between types - I wan't to find a singular approach that works for everyone (as hard as that might be)
<nicktr> ack jyrossi
— Zakim sees AdrianHB on the speaker queue
<manu> JeanYves: I don't understand - if we need a best practice, I don't see why it's orthogonal - if we need to be involved in this process, why exclude us?
<manu> NickTR: There is plenty of opportunity for collaboration - anyone is welcome to collaborate with this work.
<nicktr> q?
— Zakim sees AdrianHB on the speaker queue
<nicktr> ack AdrianHB
<Zakim> AdrianHB, you wanted to suggest concrete progress for cards
— Zakim sees no one on the speaker queue
<MattS> q+
— Zakim sees MattS on the speaker queue
<manu> AdrianHB: That we're cirleing the issue of PMIs, we don't have a mechanism that is acceptable for everyone. Are we saying that this is not how we want to proceed - he thinks we need to have a single method for card.
<CyrilV> q+
— Zakim sees MattS, CyrilV on the speaker queue
<manu> AdrianHB: I'd like some clarity on whether or not the group agrees with the current direction.
<zkoch> q+
— Zakim sees MattS, CyrilV, zkoch on the speaker queue
<nicktr> ack MattS
— Zakim sees CyrilV, zkoch on the speaker queue
<manu> MattS: I don't think what we have is sufficient at the moment - we had a number of ideas on the table, specs are in conflict with each other.
<manu> Ian: We've looked at different ways to modify those ways, but we have not put a final proposal to the group - when we put it forward to the group, we were asked to work on it more. We haven't come up with the right set of changes to make everyone happy with that.
<manu> AdrianHB: We can't progress, this is a blocking issue.
<manu> q+ to understand why this is a "blocking issue"
— Zakim sees CyrilV, zkoch, manu on the speaker queue
<manu> CyrilV: We need a payment method identifier that works for SCT, Bitcoin, etc.
<Ian> q+
— Zakim sees CyrilV, zkoch, manu, Ian on the speaker queue
<manu> ack CyrilV
— Zakim sees zkoch, manu, Ian on the speaker queue
<Ian> ack Cyr
— Zakim sees zkoch, manu, Ian on the speaker queue
<ShaneM> q+ to ask that we keep testability in mind when designing this scheme
— Zakim sees zkoch, manu, Ian, ShaneM on the speaker queue
<manu> NickTR: We're not just talking about cards.
<manu> zkoch: When we talked about implementation difficulties - we have hard coded strings, we have visa / mastercard - From where we're at, how we'll identify payment methods is the biggest issue. I think we have some thoughts on paper - this is the last blocking issue.
<manu> AdrianHB: The people that have been tasked by the group to solve this are not the implementers, we need both involved.
<manu> zkoch: That's not being proposed
<manu> q-
— Zakim sees zkoch, Ian, ShaneM on the speaker queue
<MattS> ?
<Ian> ack zk
— Zakim sees Ian, ShaneM on the speaker queue
<AdrianHB> +1 let's do this together as a priority
<Ian> q-
— Zakim sees ShaneM on the speaker queue
<Ian> ack S
<Zakim> ShaneM, you wanted to ask that we keep testability in mind when designing this scheme
— Zakim sees no one on the speaker queue
<manu> ShaneM: There are a couple of things you're looking at - keep testability in mind when doing it - if it becomes difficult to filter, it's going to be hard to test to be sure it works if it's really complex.
<manu> NickTR: I'm hearing Payment Method Identifiers - that's the main blocker for implementation - we could spend half an hour to do it.
<manu> AdrianHB: Let's try to create a concrete proposal for PMIs? It's also late in the day - if we want to delay, that's fine.
<Roy> Let's do it!
<zkoch> Beer!
<zkoch> I mean...PMI
— manu would like to beer.
<manu> Manu: Why can't you just do negation?
⇐ brian_s quit (~brian_s@public.cloak): "Page closed"
<manu> Ian: You can't do different totals with just negation.
→ brian_s joined (~brian_s@public.cloak)
<manu> Manu: Yes, you need two things... negation and ... *cliffhanger!*
<adrianba> I would like to understand if people have issues against PaymentRequest API that are not filed but they think need to be resolved prior to CR
⇐ ben quit (~ben@public.cloak): Ping timeout: 180 seconds
<manu> Ian: For tokenized card spec, nick, faraz, and laurent.
<manu> adrianba, yes
<manu> adrianba - there are some questions about arguments, core messages, etc.
⇐ zkoch quit (~zkoch@public.cloak): "zzz..."
⇐ alyver quit (~andrelyver@public.cloak): "This computer has gone to sleep"
⇐ Max quit (~textual@public.cloak): "My Mac has gone to sleep. ZZZzzz…"
⇐ fdold quit (~fdold@public.cloak): Ping timeout: 180 seconds
⇐ nick quit (~nick@public.cloak): nick
⇐ adamR quit (~adamR@public.cloak): "AFK"
<Ian> rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
<Ian> rrsagent, set logs public
<RRSAgent> I have made the request, Ian
⇐ Roy quit (~Roy@public.cloak): Ping timeout: 180 seconds
→ alyver joined (~andrelyver@public.cloak)
<Ian> zakim, this log spans midnight
<Zakim> I don't understand 'this log spans midnight', Ian
<Ian> zakim, this log spans midnight.
<Zakim> I don't understand 'this log spans midnight', Ian
<Ian> zakim, this spans midnight.
<Zakim> I don't understand 'this spans midnight', Ian
<Ian> rrsagent, this log spans midnight.
<RRSAgent> I'm logging. I don't understand 'this log spans midnight.', Ian. Try /msg RRSAgent help
<Ian> rrsagent, this log spans midnight
<RRSAgent> I'm logging. I don't understand 'this log spans midnight', Ian. Try /msg RRSAgent help
⇐ MattS quit (~MattS@public.cloak): Ping timeout: 180 seconds
⇐ lbolstad quit (~lbolstad@public.cloak): Ping timeout: 180 seconds
<Ian> rrsagent, this meeting spans midnight
<RRSAgent> ok, Ian; I will not start a new log at midnight
<Ian> rrsagent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
[We review options]
Max: May be worth just having 1 meeting so all people only have to come to 1 meeting
Zach: 7am is ok
<scribe> ACTION: Chairs to look at 7am PT teleconf start time [recorded in http://www.w3.org/2016/07/08-wpwg-minutes.html#action01]
<trackbot> Error finding 'Chairs'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
TPAC 2016
Payment method good practice: Dapeng, Matt, nick, Faraz, Jean-Yves, Lauren, Andre, Shane, AdrianBateman
Payment app spec volunteers: Conor
(in addition to those already involved)
Testing volunteers: Dapeng, Roy, Manu, Shane, Rouslan already has tests
Volunteers to work on tokenized card spec (after good pratice)
NickTR, Faraz, Laurent
* Resolved to take up the payment app spec
* Resolved to take up the overview doc
(cf list of editors
<faraz> Ian just to document our discussion in relation to the point above where differential pricing is mentioned the Amex team stopped participating in this discussion and have raised the point that once we receive the context and the groups definition of this term we will seek guidance from our internal teams on how we can proceed - thanks
* Action chairs to issues CFC to publish HTTP API and Core messages for FPWD
ADJOURNED