14:53:12 RRSAgent has joined #wpwg 14:53:12 logging to http://www.w3.org/2016/12/01-wpwg-irc 14:53:14 RRSAgent, make logs public 14:53:14 Zakim has joined #wpwg 14:53:16 Zakim, this will be 14:53:16 I don't understand 'this will be', trackbot 14:53:17 Meeting: Web Payments Working Group Teleconference 14:53:17 Date: 01 December 2016 14:53:33 Ian has changed the topic to: Conference Call 1 December -> https://github.com/w3c/webpayments/wiki/Agenda-20161201 14:53:38 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161201 14:53:42 Chair: nicktr 14:53:45 Scribe: ian 14:57:05 jenan has joined #wpwg 14:58:05 alyver has joined #wpwg 14:59:11 zkoch has joined #wpwg 15:00:40 present+ Andre 15:00:42 present+ Ian 15:00:44 present+ Zach 15:00:47 present+ Jenan 15:00:51 present+ Alan 15:00:54 Max has joined #wpwg 15:00:59 regrets+ AdrianHB 15:01:27 oyiptong_ has joined #wpwg 15:02:48 present+ AdamR 15:02:51 present+ Max 15:03:33 -> Agenda 15:03:37 https://github.com/w3c/webpayments/wiki/Agenda-20161201 15:03:49 present+ ShaneM 15:04:38 Topic: Meetings 15:04:43 rouslan has joined #wpwg 15:04:48 Upcoming calls: 8 Dec, 15 Dec. No calls 22 and 29 December. Next call 5 Jan 2017. 15:05:02 [FTF update] 15:05:16 Ian: I am still working on a meeting venue in Chicago 23-24 March 2017 week before the IETF meeting 15:05:24 present+ nick 15:05:30 present+ rouslan 15:05:57 https://github.com/w3c/webpayments/wiki/Agenda-20161201 15:06:08 present+ Jason 15:06:11 present+ Olivier 15:06:20 jnormore has joined #wpwg 15:06:23 topic: Issue 311 15:06:29 https://github.com/w3c/browser-payment-api/issues/311 15:06:41 https://github.com/w3ctag/spec-reviews/issues/147#issuecomment-262427149 15:07:03 Should we use .allowPaymentRequest and anticipate migration to Feature Policy? 15:07:24 zkoch: This is about the iframe thing 15:07:43 ...background is that we wanted iframe support, so we proposed an attribute 15:07:52 ..there was pushback on this due to emerging "feature policy" 15:07:59 ...and some discussion about how to spec this out. 15:08:12 ...and interim proposal came from Chrome developers working elsewhere on the web platform 15:08:26 ...goal is short-term compromise with migration path to Feature Policy 15:08:41 q+ 15:08:54 q? 15:08:59 ...the short-term proposal is to "allow" and then we say in the spec when feature policy is available, to defer to that. 15:09:18 ack rouslan 15:09:23 ack ro 15:09:59 rouslan: Now we know that Feature Policy in chrome is coming soon 15:10:28 ....that is preferable to monkey patching....but then we heard from Marcos (Mozilla) that they are not planning to implement the full Feature Policy in the same time frame 15:10:37 ...so that makes it harder to do Feature Policy sooner 15:11:10 ...idea was to allow=paymentRequest in iFrame and Mozilla is on board with that 15:11:29 q? 15:11:31 ...so the consensus view right now is allow=paymentRequest on iFrame and plan for migration to Feature Policy 15:11:39 ..now the question is: will Edge support this? 15:11:51 present+ Roy 15:11:57 ...and same question to other browser vendors 15:12:07 present+ adrianba 15:14:36 to allow=paymentRequest 15:14:47 IJ: Can edge support that? 15:15:03 Rouslan: either allow= or enable= 15:15:09 present+ dlongley 15:15:13 ..it's the shorthand attribute from the Feature policy work 15:15:41 adrianba: We don't currently have a Feature Policy plan; that doesn't mean we won't do it; we need to re-review 15:15:45 q+ 15:16:08 Rouslan: Question is whether to make the iframe attribute future-compatible to Feature Policy 15:16:14 ...and use "=" rather than shorthand 15:16:24 adrianba: Is it really forward compatible or are we just guessing? 15:16:36 Rouslan: Should we continue discussion on GitHub? 15:17:06 adrianba: I believe we currently implement what's in the spec and are not likely to change the implementation soon; I will double check and we can continue discussion on GitHub 15:17:31 ...can we really make it forward-compatible? We need to specify parsing rules; handling unrecognized tokens 15:18:16 ...if we support it and expect only a single value, when people provide multiple values in the attribute, if we didn't allow that in our code today then we will not have accomplished anything, and may be even more damaging as they can't actually use the other Feature Policy features and do payments in a backwards-compatible way 15:18:30 ...so seems risky unless we understand how the attribute will evolve 15:18:32 stan has joined #wpwg 15:18:43 q— 15:18:44 q- 15:19:14 nicktr: Sounds like we need to bring back 15:19:25 Topic: Detecting Payment Method Availability 15:19:30 https://github.com/w3c/browser-payment-api/pull/316 15:20:10 zkoch: Mahesh wrote a pull request for canMakeActivePayments...there was good feedback 15:20:28 ..one of the larger issues was on "active" as being both technically difficult and raising privacy implications 15:20:45 ...my proposal to Mahesh was to take the algorithm as written but remove the "active" part 15:20:58 ..that will make it an implementation decision on whether something is "active" or not 15:21:03 ..so there's a new pull request from Mahesh 15:21:13 q? 15:21:16 https://github.com/w3c/browser-payment-api/pull/316/commits/b87613d1d4411dfa31ca6462f85a2c09c658141b 15:22:17 nicktr: Question - what's to stop a bad actor just having lots of different domains from which they launch requests, and you aggregate them?: 15:22:46 zkoch: the short answer is that nothing prevents that, but that's logistically very difficult; a person would have to visit all those sites 15:23:19 ...we need to ack that this is a compromise - between the requirements of different players 15:23:22 q+ 15:23:40 nicktr: on the one hand you have a privacy issue, and on the other you have a functionality that merchants already have today 15:24:03 zkoch: I would challenge the notion that this functionality exists today - whether user has support for a payment method 15:24:19 nicktr: Yes, that's true, but you can start by saying 'I only accept X" one at a time 15:24:38 ...merchants can nudge people as well since the merchant controls the experience 15:25:02 zkoch: Those seem like separate issues. I think that ways that you can poke into the system today are still available via PR API 15:25:05 q? 15:25:17 nicktr: I think this is a hard sell for merchants 15:25:36 present+ 15:26:19 present+ Ken 15:27:12 nicktr: I think the overall concern is the passing of control to someone else; this is one feature we are providing to ameliorate that but the concern is more general 15:27:15 q? 15:27:30 q? 15:27:42 ack Ian 15:28:08 q? 15:28:18 IJ: Has there been implementer discussion about user configurability (and impact on scope) 15:29:14 "`example.org` wants to see what payment methods you have available, allow/deny?" 15:29:24 adrianba: If user can configure off then the merchant might (1) disable use of API or (2) create a bad UX 15:30:11 q+ 15:30:34 ack zkoch 15:30:44 IJ: My thought was that function would be "off" until first specification of creds and it would be on by default 15:30:51 zkoch: Apple has a flag 15:31:02 ...I think we've thought about adding a similar thing in the UI 15:31:10 ..it's a way to disable PR API (in some way) 15:31:19 ..and merchants would fall back to traditional flow 15:31:22 q+ 15:31:31 ..the question for me was whether to be in the spec or not 15:32:06 q? 15:32:14 ack adrianba 15:32:20 IJ: Usually I would push this to the browser, but it might be interesting to connect to "scope" of this function if it's configurability 15:32:45 adrianba: there's a question about user opting out of the payment request ecosystem...and what that means (e.g., removing something from the type system so make it look like the browser does not support PR API) 15:33:03 ...if you turn off the "detection" piece there's a question about what impact will that have on the merchant ecosystem. 15:33:29 ...we are hearing from merchants that they want to hear whether there is some level of support for a payment method 15:33:47 ..we are hearing that the request is there because people want to avoid sending people into a browser UI if the user has never used it before 15:33:53 ..or if the user may not be able to make a payment 15:34:09 ..if you allow the user to turn that off (or not work the first time) then you defeat the reason people are calling for this functionality. 15:35:23 nicktr: Sounds like there is consensus among implementers that this is the way to go 15:35:50 PROPOSAL: Merge the updated Mahesh PR https://github.com/w3c/browser-payment-api/pull/316/commits/b87613d1d4411dfa31ca6462f85a2c09c658141b 15:35:55 q? 15:35:56 what are the updates? 15:36:20 1) New name 15:36:31 2) Date / time algo gone 15:37:07 zkoch: I suggest we endorse the concept and accept that there will be edits (e.g., with adrianB and Marcos) to get the PR right 15:37:15 +1 to what zach said 15:37:21 +1 to zach 15:37:25 ...so let's propose the spirit of the pull request 15:37:50 adrianba: Is the spirit that the spec allow variability around mentions of "active" 15:38:07 zkoch: Yes, the algorithm will say "payment method available" and allow some flexibility 15:38:23 adamR: As written, you can call this once per TLD per universe. 15:38:30 ...it doesn't talk about the quota resetting 15:38:36 ...is there a frequency expectation? 15:38:44 q+ 15:38:54 zkoch: There might need to be mention of resetting in the algorithm. 15:39:16 ...however, we have left it intentionally vague so that implementers can differentiate according to privacy preferences (e.g., 30 mins or 24 hours) 15:39:30 AdamR: I am fine with leaving that undefined; let's just say clearly in the text that it is undefined. 15:39:34 sounds good 15:39:35 ack rouslan 15:39:56 IJ: I Hear that the algo should (1) talk about resetting and (2) say explicitly that reset timeout is defined 15:40:14 rouslan: There is some text in there already to that effect 15:40:26 nicktr: I hear no objections to this direction and that some polishing is in order 15:40:28 +1 15:40:39 +1 15:40:41 +1 15:40:42 +1 15:40:50 +1 15:40:56 does this include consensus on "active" vs not? 15:41:04 +1 15:41:43 q+ 15:41:45 ack jen 15:41:58 MaheshK has joined #wpwg 15:41:59 Jenan: It didn't seem to me we had consensus yet on dropping the "active" part 15:42:22 ...some class of merchants will want to allow just in time registration of payment (apps) 15:42:29 ...some class will want instant checkout without registration 15:42:41 ...can we have both of these options? 15:42:47 `.requiresRegistration` ? 15:42:49 we can't support active in our implementation 15:43:10 q+ 15:43:12 present+ nickS 15:43:17 `.enrollmentRequired?` 15:43:43 the proposal currently uses the term "available" but doesn't define it 15:44:12 ack zk 15:44:30 zkoch: I think that you are right there is ambiguity here 15:44:40 ...the original idea was "true if IMMEDIATE way to pay" 15:44:56 ...there was pushback 15:45:15 ...the compromise is to drop "active" and allow implementers to implicitly make it active 15:45:24 q+ 15:45:45 zkoch: Even if we separated this into two calls, we will run into the same issue - some browsers may not support the call 15:45:59 ..over time, if market forces are strong enough in either direction I think you will see browsers normalize 15:47:09 adrianba: Our implementation relies on Windows underlying, and that functionality opens UI, so we cannot implement this without presenting UI 15:47:48 q? 15:47:50 ack me 15:47:50 q? 15:48:43 q? 15:48:54 IJ: does "not detecting" solve this? (IJ is not sure) 15:48:56 semantics aren't clear to merchants ... so how do they use the method? 15:49:19 Jenan: It's about ambiguity...harder to optimize checkout if you don't know whether you are going to get one-click or whether you want to enable registration 15:49:19 q+ 15:49:33 ack Ian 15:50:18 ack me 15:50:27 IJ: What about a flag from the merchant as input like "allowRegistration" 15:50:41 ..and implementations can prompt user if they want 15:50:51 zkoch: I agree with Jenan's point that there is ambiguity. 15:51:18 ..at this point we either accept the compromise and let market/merchant forces drive consistency, 15:51:23 ...or we scrap the conversation 15:51:29 q? 15:51:52 q+ 15:52:06 Jenan: I am ok with the spirit of the proposal right now and would not block forward progress 15:52:06 ack dlongley 15:52:25 dlongley: Ian's suggestion that the merchant signal could cause this to be a simpler API 15:52:48 ...where you don't have to make a separate call..instead you just make the payment request call with your preference and the UA can decide whether to reject the request 15:53:10 zkoch: It feels like it pushes the problem out 15:53:27 I don't think that solves the problem. canMakePayment true -> show payment request with noRegistration -> nothing available 15:53:32 q? 15:53:45 dlongley: I don't know what they plan to do in this situation in Edge 15:53:55 ..would they say "yes' or "no" when they can't tell? 15:54:15 nicks has joined #wpwg 15:54:21 adrianba: We understand what payment methods are supported. What we can't tell without unlocking the store is whether someone has already provided credentials. 15:54:47 q+ 15:54:59 q+ 15:55:29 ack me 15:55:52 q- 15:55:56 i'll say in IRC... 15:56:01 nicktr: I think there is more to do here. Let's have one more go around 15:56:02 i think this sounds like it may be really specific to basic card 15:56:22 zkoch: I see +1 to the direction. What more concretely needs to be addressed? 15:56:48 and perhaps the real solution is that merchants just provide their own payment app for that case and go with the API? 15:58:12 sgtm 15:58:18 IJ: Propose we resolve "yes" to the direction and give 1 week for updated PR 15:58:21 I think it would be good for us to update the pull request and maybe include more explanation 15:58:36 then we can merge after discussion next week 15:58:37 SO RESOLVED: Support direction of canMakePayment and will review updated PR next week 15:58:54 topic: Quick return to Feature Policy with NickS 15:59:37 nicks: I managed to pin down David Singer for discussion of Feature Policy; I don't think we have an ETA yet. I would assume that we would not be implementing it in parallel with payment request API. 16:00:29 ..I would be comfortable saying that if the browser does not support this feature then iframe payments are not permitted 16:00:38 ...that is current Apple functionality 16:00:44 ..I will talk to webkit team further 16:00:59 topic: Push payments 16:01:09 https://github.com/w3c/browser-payment-api/issues/224#issuecomment-263995469 16:01:10 I have to go I’m afraid! Late for next meeting! Thanks, bye! 16:01:22 https://github.com/w3c/browser-payment-api/pull/292/files 16:02:00 https://w3c.github.io/webpayments/proposals/method-practice/#network 16:02:19 IJ: Please review those so we can merge those next week 16:02:21 Topic: next call 16:02:24 8 Dec 16:03:42 maybe we need a concept of "temporary payment apps"... 16:04:18 to get the merchant checkout flow into the payment request UI when basic card is used 16:04:38 rrsagent, make minutes 16:04:38 I have made the request to generate http://www.w3.org/2016/12/01-wpwg-minutes.html Ian 16:04:41 rrsagent, set logs public 16:14:30 or just give the user the option to checkout on the website ... so they can click that instead of doing registration 16:14:32 then it's a user decision. 16:15:30 so when the site submits the payment request, they can say "we support checkout on our site" ... and the user can make that selection in the UI which will cause it to close and the merchant site can show their checkout page 16:16:12 it's an additional step, but it puts the user in control -- and removes all the user probing stuff 16:22:44 Max has joined #wpwg 17:02:06 Max has joined #wpwg 17:14:09 stan has joined #wpwg 17:45:00 stan has joined #wpwg 18:07:56 Zakim has left #wpwg 19:08:07 Adam__ has joined #wpwg 19:42:24 stan has joined #wpwg 21:35:56 stan has joined #wpwg 21:40:46 Adam__ has joined #wpwg 22:48:32 Adam__ has joined #wpwg 23:39:48 Adam__ has joined #wpwg 23:54:22 stan has joined #wpwg