16:00:04 RRSAgent has joined #wpwg 16:00:04 logging to http://www.w3.org/2016/05/19-wpwg-irc 16:00:06 RRSAgent, make logs public 16:00:06 Zakim has joined #wpwg 16:00:08 Zakim, this will be 16:00:08 I don't understand 'this will be', trackbot 16:00:09 Meeting: Web Payments Working Group Teleconference 16:00:09 Date: 19 May 2016 16:00:20 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160519 16:00:25 regrets: NickTR 16:00:26 chair: AdrianHB 16:00:58 alyver has joined #wpwg 16:01:38 brianS has joined #WPWG 16:02:21 present+ dlongley 16:02:27 present+ alyver 16:02:46 present+ jnormore 16:02:48 present+ AdamR 16:02:50 Agenda https://github.com/w3c/webpayments/wiki/Agenda-20160519 16:03:15 present+ ShaneM 16:03:39 present+ AdrianHB 16:03:41 roy has joined #wpwg 16:04:13 Web AUth 16:04:27 (We have not mentioned CGs here, including hardware security which I believe is very relevant to tokenization discussion) 16:04:45 dezell has joined #wpwg 16:04:51 present+ dezell 16:04:52 MattS has joined #wpwg 16:06:47 I can attempt to scribe...is it just jotting down notes in IRC? 16:07:08 Yes 16:07:20 sure thing 16:07:25 scribe: Roy 16:08:23 There are 3 issues related to addresses which we will try to get though 16:08:40 1) issue 186, adding a careOf field to shipping address, PR 197 16:08:57 not many comments on PR so far 16:09:26 any strong objections to PR 197...crickets, decided to merge 16:09:28 We agreed not to keep changing address fields - hopefully this is the last time 16:10:21 issue 2) PR 198, changes a few shipping address field names, regionCode -> country, etc 16:10:57 Adam: the way region is used is confusing, this is the most important field to update 16:11:02 "locality" is a bit more international than "city", but i'm not going to complain 16:11:07 Adrian: any objections? 16:11:21 +1 to editors picking something not crazy 16:11:26 no objections at this time, moving on 16:11:35 q+ 16:11:42 topic: Issue 27 16:11:48 present+ MattS 16:11:48 Should API support billing address capture (for tax computation)? 16:11:49 q? 16:11:51 present+ Ian 16:12:21 issue 27) billing address capture, no proposals yet, the issue is going to sit on the backlog until a proposal is made 16:12:35 q? 16:12:37 q? 16:12:38 ack adrian 16:12:44 Adrian: we should move to settle an address fields asap so implementers can get started 16:13:38 AdrianB: trying to explore whether the billing address can be associated with the payment method itself 16:13:59 +1 that billing address is prob something that's part of the payment method 16:14:14 zakim, who's here? 16:14:14 Present: dlongley, alyver, jnormore, AdamR, ShaneM, AdrianHB, dezell, MattS, Ian 16:14:16 On IRC I see MattS, dezell, roy, brianS, alyver, Zakim, RRSAgent, jnormore, collier-matthew, dlongley, manu, ShaneM, adamR, slightlyoff, mkwst, Ian, hober, schuki_, wseltzer, 16:14:16 ... trackbot, dlehn, Mike5, AdrianHB, adrianba, davidillsley, dwim_ 16:14:25 ...billing address is important for tax computation particularly in europe 16:15:26 ...maybe there can be an optional flag for billing address, but better requirements are needed to fully understand the problem 16:16:16 Adrian: we need feedback from those familiar with tax calculation and what the requirements are there 16:16:34 ...agree that if address is required for use of a payment method then it makes sense to place the address there 16:16:36 q+ 16:17:19 Jason: european tax calculation on digital goods are taxed based on customer location, IP alone is not enough 16:17:44 i think these requirements support the idea of a lower-level API/components to allow websites to get this information as needed based on their own requirements. 16:17:55 q+ 16:17:56 Adrian: should we expect websites to capture billing address before calling payment request api or do we want the api to support it during its flow 16:18:25 ...we need a concrete proposal on how this might work 16:18:40 ack ad 16:18:40 ack jnor 16:18:48 queue+ jnormore 16:18:56 q+ to be a wet blanket 16:19:11 Adam: concerned about the user experience when the merchant gathers one type of address and the api gathers another, address acquisition should be in one context 16:19:36 ack jnormore 16:19:39 +1 to what Adam said.. 16:19:48 ack dl 16:19:48 dlongley, you wanted to be a wet blanket 16:20:01 (on the other hand, I won't ever use this part of the API) 16:20:25 Dave: second with Adam, not sure we can capture all use cases in our flow, its a moving target, new regulations can produce new uncaptured requirements 16:20:27 q+ 16:20:52 +1 to dlongley 16:20:58 ...concerned about being reduced to abandoning the flow completely if merchant requirements are not captured, as opposed to using some of the functionality 16:21:23 Ian: the api can always be used without data gathering, so base functionality won't go away 16:21:36 q+ to say some things may changes other things likely will not 16:21:38 q+ 16:21:47 ack ian 16:22:07 Adrian: *summarizing* where do we draw the line 16:22:43 ack dlongley 16:22:43 dlongley, you wanted to say some things may changes other things likely will not 16:22:45 maheshk has joined #wpwg 16:23:01 Dave: I think we have well-defined abstractions for payment/payment apps/etc 16:24:01 ...we need to be careful how hard we try to capture the last 20% of user experience 16:24:37 How? We get feedback! Including through discussions and experimental implementations 16:24:59 Adrian: agreed, start small and gather feedback 16:25:01 ack jnormore 16:25:30 Jason: agree, clarifying on digital goods case, its a low-usage use case, shopify does not support this for their merchants 16:25:35 RRSAgent, make minutes 16:25:35 I have made the request to generate http://www.w3.org/2016/05/19-wpwg-minutes.html Mike5 16:25:52 ...its up to merchant to verify customer location, as an example of the edge-case-ness of some of these scenarios 16:25:54 RRSAgent, make logs public 16:26:37 Adrian: we need to make a good case for adding in new use cases to our considerations 16:26:55 brianS has joined #WPWG 16:27:21 ...no resolution for issue 27, but proposal in the works by Zach and AdrianB 16:27:22 +1 to getting feedback ... we may find that providing low-level APIs/some components to capture this data in an iterative way may be a better design 16:27:33 Andrew has joined #wpwg 16:27:58 AdrianB: the digital goods examples supports our idea, but not yet hearing a resounding case for the idea 16:28:14 ...maybe just leave the proposal and wait for more feedback 16:28:20 +1 16:28:22 +1 16:28:29 +1 to having nothing on billing address and changing if we get market feedback 16:28:33 PROPOSAL: no change to api for billing address until we get feedback 16:28:39 +1 16:28:40 +1 to having nothing on billing address and changing if we get market feedback 16:28:44 +1 — I agree, in paritcular, that we need good use cases, since they’ll impact the design 16:29:09 RESOLVED: Postpone issue 27 with no change to the specification 16:29:27 issue 27 not closed, but de-prioritized 16:29:31 Topic: Issue 187 16:30:38 AdrianB: when a shipping address change event occurs you can tell the user agent that you plan to update the payment details 16:31:10 ...the issue is about what happens when instead of resolving the promise to update payment details, the promise is rejected, what happens 16:31:29 ...the spec says do nothing, the argument is that the spec should dictate the UI reverts to the previous state 16:32:32 q? 16:32:40 q+ 16:32:45 ...since the webpage is in control, it can decide how to handle the case 16:34:07 ...I think doing nothing is good because it is less work and the problem does not seem obvious 16:34:50 ...the user might not notice the failure occurred and UI state reverted, so there is no clear solution 16:35:19 ...suggesting to wait for industry examples before we decide on best practice 16:35:48 q? 16:35:49 Adrian: the other part of the comment is handling the case where the website rejects the user input, ex) unable to deliver to selected address 16:35:54 ack adamr 16:36:07 Adam: that's a good summary of my concern 16:36:52 ...I want to give the webpage additional control to be able to revert the UI, ie, tell the api to notify the user of the failure 16:36:57 adrianHB: I am hearing "notify the user" capability 16:38:02 AdrianB: should we be able to provide a message that gets displayed in the UX when the user picks an address the merchant cannot handle 16:38:07 if we don't want to pass text from the website to show to the user for some reason, another option is to define an error type like "ShippingAddressNotSupported" and the user agent can figure out what to say about that to the user 16:38:17 ...mixed feeling about such a message in the UX 16:39:03 Adrian: let's continue discussion of this topic on the issue list 16:39:24 notes that if we provided a component for collecting this info instead we could avoid the problem :) 16:39:33 q? 16:39:34 q? 16:39:48 present+ 16:39:51 Topic: Issue 16 16:40:07 +1 to leaving as-is for now 16:40:09 AdrianHB: Adrian Bateman made case for leaving as-is 16:40:40 AdrianB: spent some time attempting a PR, unable to find something that felt similar 16:40:55 [Key concept is "lightweight object creation"] 16:40:59 q+ 16:41:11 ...nothing happens apart from argument validation 16:41:14 [Real work happens when method is called later] 16:41:45 adrianba: Also other specs taking this approach. 16:41:47 adrianhb: +1 16:42:01 Dave: agree with adrian's argument, will we need a namespace? 16:42:21 dlongley: +1 for as-is (with namespace comment) 16:42:24 IJ: +1 16:42:41 RESOLVED: Issue 16 closed with no change to the spec. 16:42:42 Adrian: closing issue 16 16:43:02 topic: PR 179 16:43:06 https://github.com/w3c/browser-payment-api/pull/179 16:43:07 q+ 16:43:11 q- dlongley 16:44:15 AdrianB: wanted to make a way to pass in a single shipping option which is auto-selected as the default one 16:44:37 ...the expectation is that the total price and other display items will include that shipping option 16:45:03 ...the address may dictate shipping options 16:45:44 ...default shipping option may be used when multiple similar options are available 16:46:31 Adrian: any comments about the PR? or ready to merge? 16:46:33 ack adam 16:46:54 Adam: good feature to have, but want this to be non-conformant 16:47:02 [prefer it be a hint] 16:47:13 AdrianB: not sure that can work 16:47:39 ...merchant must assume its included in the final price 16:48:18 q+ 16:48:25 ...if its a hint then you do not get the feedback to the app without firing an event 16:48:31 Adam: okay with firing an event 16:49:25 Adam: I will propose language in the PR 16:49:34 q- 16:50:05 was just going to say we probably just need to say the user agent can change the selection but they need to fire an event if they do or something to that effect. 16:50:51 Adrian: it could be that this is one of the big topics at the face-to-face, let's move to currency types and rendering 16:50:59 topic: Issue 185 - Currency Types and Rendering 16:51:25 ...we want to support ISO currencies because browsers know what to do to display them 16:51:43 ...we also want to support unknown currencies for use cases like crypto currency, loyalty points, etc 16:51:57 Here are three proposals captured by AdamR: 16:51:57 https://github.com/w3c/browser-payment-api/issues/185#issuecomment-220043533 16:52:18 ...complication in that we don't want ambiguity in the codes between the two types 16:52:54 ...we have not elegantly solved this, Adam with a proposal... 16:53:33 q+ 16:53:33 Adam: suggest 1 of 2 proposals, using ISO codes or using URLs for adhoc currencies 16:53:42 non-ISO through URLs. Resolve to a document with JSON that has properties that are interesting? 16:54:16 ...the other proposal is to use some well-known non-ISO currencies explicitly for common non-ISO currencies 16:54:58 Ian: user agent must interpret a string looking like an ISO code as an ISO code 16:55:18 ...also in support of a small number of non-ISO codes, but we must be careful 16:55:50 ...not thrilled with URL proposal, not sure we get far in specifying what happens we you access those URLs 16:55:57 q+ to say that tools always render stuff on the fly 16:56:40 q+ 16:56:41 ack ian 16:56:46 ...non-ISO may be getting ahead of ourselves, but if we do use URLs lets keep it as only an identifier 16:56:48 ack ShaneM 16:56:48 ShaneM, you wanted to say that tools always render stuff on the fly 16:56:57 q+ 16:57:03 Shane: tools on the web render on the fly all the time 16:57:39 ack adamr 16:57:57 Adam: what I'm proposing is as simple as "here is the name of this currency to render" 16:58:21 q+ to say you could put in a link 16:58:29 +1 to what Adam said about URLs not having meaning to users 16:58:32 ...we minimally need a way to say this URL links to the text to show the user 16:59:02 Adrian: I agree with Ian's points and Adam's points, dereferencing the URL feels high cost, but we have the need to fetch the display text, etc 16:59:27 ...maybe add these directly to CurrencyAmount somewhere down the line 16:59:27 q+ 16:59:43 ack adrian 16:59:48 ack dlongley 16:59:48 dlongley, you wanted to say you could put in a link 17:00:09 Dave: I don't think we need to define what happens withe these URLs in V1 17:00:21 IJ: One way to get extensibility is to say that behavior for other values is undefined 17:00:40 ...but if we do, maybe it is linking to more info rather than rendering it 17:01:19 ack adamr 17:01:35 q+ 17:01:36 Adam: concern with allowing the merchant to supply string could be used for phishing 17:01:38 q+ 17:01:43 +1 to that concern from adam 17:01:44 ack dlon 17:02:02 Dave: good concern, but not sure its mitigated by using URLs 17:02:44 Ian: there are unexplored issues here, one approach is to leave non-ISO currency behavior unspecified 17:03:27 ...I'd rather do less for this edge case and allow for experimentation and then we will learn from it after 17:03:37 q+ to say that doesn't solve the squatting problem 17:03:52 q- 17:04:06 alyver has left #wpwg 17:04:11 Adrian: we are out of time, let's take this to the issue this 17:04:22 leaving it undefined doesn't solve the squatting problem 17:04:26 ...(list) 17:04:35 ... uggh 17:04:42 ...face-to-face 7-8 July in London 17:04:54 rrsagent, make minutes 17:04:54 I have made the request to generate http://www.w3.org/2016/05/19-wpwg-minutes.html Ian 17:04:57 rrsagent, set logs public 17:04:58 no problem, that was harder than I thought! 17:13:08 roy has left #wpwg 17:44:04 manu has joined #wpwg 17:44:37 dlongley has joined #wpwg 19:26:29 Zakim has left #wpwg 22:11:06 sam has joined #wpwg