17:38:50 RRSAgent has joined #wpwg 17:38:50 logging to http://www.w3.org/2016/01/21-wpwg-irc 17:39:01 I'm logging. I don't understand 'start telcon', shepazu. Try /msg RRSAgent help 17:39:02 VincentK: perhaps we should wait to make this proposal until FTF 17:39:12 q+ to not delay the decision, but get data for a better decision for later. 17:39:17 ... and we can make adjustments more efficiently at F2F 17:39:34 AdrianHB: anyone opposed to making a resolution on this? 17:40:01 q+ 17:40:19 PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate 17:41:24 https://github.com/w3c/webpayments/issues/62#issuecomment-173561385 17:41:27 MattS: the proposal is more detailed than what is being put forth. 17:41:43 q+ to note that is not the proposal. 17:42:19 manu: It's not clear to me what we're doing. 17:42:23 Proposal from MattS -> https://github.com/w3c/webpayments/issues/62#issuecomment-173561385 17:42:28 VincentK: I agree. 17:42:30 Manu: -1 to MattS's proposal 17:42:47 AdrianHB: I'm willing to push this out as unresolved. 17:43:05 q? 17:43:09 shepazu: We just need general consensus. 17:43:20 AdrianHB: Do we have clarity on the proposal? 17:43:38 AdrianHB: it will not change the work if we delay this 17:43:58 AdrianHB: MattS and VincentK, please put forth a clear proposal. 17:44:21 Ian: People who feel the proposal is not clear should make comments about the proposal. 17:44:22 I don't think the proposal is clear - are we doing what MattS is saying in the spec text, or in the WPIG Glossary, which is pulled into the specs. 17:44:31 Ian++ 17:45:09 https://github.com/w3c/webpayments/issues/62#issuecomment-173561385 17:45:21 Ian: This is a proposal that MattS is putting forth. 17:45:28 What terms are being adopted where? (I've read MattS's comment, but I'm still not clear). I heard people saying we use Payee and Payer and add those terms to ISO20022 as synonyms. But I'm not sure if this is what is being proposed. 17:45:33 ... please provide comments/questions to this proposal. 17:45:43 Ian++ 17:45:56 Agreed w/ this being the way we resolve clarity around this proposal. 17:46:06 agreed with Ian 17:46:07 So the group action is "Review MattS's proposal this week and send questions for clarification" 17:46:09 -1 from me because it's unclera. 17:46:15 ...then we'll put the proposal to the group at next week's meeting 17:46:19 -1 it's unclear how editor's should implement this. 17:46:19 AdrianHB: Please provide +1 / -1 on the proposal that has been linked to by Ian. 17:46:34 -1 to Ian trying to rush this ;) 17:46:51 Ian: we should come back next week and deal with this proposal. 17:46:55 (or rather, one of the editor's is concerned with exactly how we implement this in the specs) 17:47:05 take up agendum 9 17:47:10 (and it hurting understandability in the specs.) 17:47:30 -10 to rbarnes for being tuned out for a couple months :P 17:47:33 AdrianHB: this proposal is by Manu 17:47:53 manu: very quick, I think the payment request API is trying to improve the checkout process. 17:47:57 q? 17:48:14 ... one thing we could automate is shipping address collection. But collecting this information is very specific. 17:48:39 ... and there are discussions underway in various groups about how to best collect shipping address information. 17:48:57 ... the proposal is to NOT deal with shipping address in the payment API right now. 17:49:00 q+ 17:49:07 ack manu 17:49:07 manu, you wanted to not delay the decision, but get data for a better decision for later. and to note that is not the proposal. 17:49:09 ... let's delay that decision right now. 17:49:12 ack matts 17:49:26 q? 17:49:40 ack zk 17:50:04 zkoch: I disagree with manu. I think that there is no chartered working group to tackle shipping addresses. 17:50:19 q+ to note that Credentials CG engaged heavily w/ Mike West to generalize the API to support things like Addresses in the future. 17:50:22 as a webappsec person, agreed that there's no action on addresses there 17:50:29 ... secondly, I know we talk about shipping being ultraspecific use case 17:50:42 ... but there is nothing more common in e-commerce. 17:50:48 ... I think this should be implemented now. 17:51:02 q+ to say that there is also nothing more common than billing address. Why aren't we special casing that too? 17:51:06 ... I think it is early in the process to say that we should NOT be working on this. 17:51:09 q- 17:51:11 q+ to note that Credentials CG engaged heavily w/ Mike West to generalize the API to support things like Addresses in the future. 17:51:23 ack shanem 17:51:23 ShaneM, you wanted to say that there is also nothing more common than billing address. Why aren't we special casing that too? 17:51:39 ShaneM: why are we not special casing billing address which is equally ubiquitous. 17:51:42 ack manu 17:51:42 manu, you wanted to note that Credentials CG engaged heavily w/ Mike West to generalize the API to support things like Addresses in the future. 17:51:47 billing address is not merchant-facing 17:52:00 q+ 17:52:03 manu: we have engaged (digital bazaar and the credentials CG) with Mike West. 17:52:26 ... we have had discussion about using Verifiable claims API for this purpose. 17:52:55 ... I'm confused because the conversations that we've had were targetted at shipping/billing address and proof of age. 17:53:06 q+ with a concrete proposal 17:53:10 ack rba 17:53:11 q+ to make a concrete proposal 17:53:13 ... we are actively having discussions about charting work around claims. 17:53:39 ??: It seems early to be making this decision. 17:53:54 s/??/rbarnes/ 17:54:07 q+ 17:54:21 ... this would need to be something that involves a new working group which seem pretty far down the road. 17:54:42 quick comment: how this information is collected could change the shape of the API and there are potentially many other pieces of information to collect, +1 punt now deal with later (don't want to mess this up). 17:54:51 q+ to talk billing addresses 17:54:52 AdrianHB: I echo some concerns about depending on things that don't exist yet, but only likely. 17:54:59 ... we can't depend on that happening. 17:55:25 ... there is a lot of user experience issues that we should be considering. 17:55:46 ... if you use apple pay or android pay, collecting address information is performed along with payment. 17:55:48 it's also not the end of the world if we end up with two places to transmit addresses 17:55:55 some of my other complaints are with *how* it has been proposed to be collected: https://github.com/WICG/paymentrequest/issues/42#issuecomment-173628517 17:55:55 how many web storage thingies do we have? 17:56:03 ... I'm OK with punting until we have more specific information. 17:56:04 Yes, but no one agrees that was a good outcome :) 17:56:13 and yet, the web has not collapsed 17:56:15 having cruft in the Web Platform is not a good thing. 17:56:17 ack ian 17:56:17 Ian, you wanted to make a concrete proposal 17:56:21 ... can we still have a fluid user experience if we separate the concerns? 17:56:22 q- 17:56:33 The Web won't collapse, it's just we're unnecessarily adding cruft into the Web Platform. 17:56:36 merchants can collect address information today -- let them keep doing it until we have a good way to help them do it. 17:56:41 and it's not like merchants can't collect shipping address information today. 17:56:46 let's do this right, not rush into it. :) 17:56:47 Ian: I would like to propose that we continue to develop the spec as the authors write them. 17:57:09 ... if we see credentials work that is chartered and clearly relevant, that the payments API could evolve. 17:57:09 it’s also not like merchant’s can’t collect payment credentials today :) 17:57:10 also note: collecting shipping address information *too late* in the payments process is seen as a major cause of cart abandonment, let's not prescribe that merchants do it that way. 17:57:18 I wonder if we can't just mark this part of the spec as AT RISK because of pending work? 17:57:25 ... and it could be noted that there are hooks to other work that is taking place. 17:57:37 zkoch, yes - but we're focused on that in this group. We're not focused on gathering arbitrary credentials (shipping address being just one of them) 17:57:48 zkoch: yes, but we have some good direction and we're the group working on that. 17:57:54 ... this would allow drafts to include address information, but keep on eye on additional approaches. 17:58:00 zkoch, I'm not saying the decision is black or white - but I feel nervous saying "we're going to do this and then replace it with something better later on". 17:58:23 AdrianHB: I would like to allow the API to gather shipping information, but be aware of other work taking place. 17:58:42 Ian: if we can have a pipeline for getting information, I like that approach. 17:58:48 First bullet from charter on benefits: “A better checkout experience for users, particularly on mobile devices. The standards should facilitate automation, one approach to improving the user experience.” 17:58:51 I'd rather make the mechanism declarative instead of imperative - IF we decide to do something about it in this group, which I think is a bad idea. 17:58:58 I think it qualifies there, but agreed it’s a tricky question 17:59:08 Agreed it qualifies here 17:59:14 +1 to Ian, low-level APIs to get the info and a feature to pipeline them 17:59:24 don't agree that we have the right approach for shipping address. :) 17:59:30 AdrianHB: I suspect these heavy questions will not be easily resolved. 17:59:40 +1 to low-level APIs to get info and feature to pipeline them together. 17:59:43 q+ 17:59:55 ... we will likely see proposals be kicked down the road, how do we prevent this from happening indefinitely. 17:59:55 ack zk 17:59:55 zkoch, you wanted to talk billing addresses 18:00:06 this is great to get high bandwidth discussion on the tough issues on the call 18:00:21 zkoch: I think that billing is tricky. The billing address is more in the responsibility for the payment instrument. 18:00:28 ack rbarnes 18:00:45 Other WGs I've been in adopted a "feature at risk" designation. This designation serves as 1) an indication that the feature might go away in a later draft and 2)a call for advocacy from those who think it's important. "Feature at Risk" would appear in red. 18:00:58 (IJ agrees with Richard that more experience will inform the discussion.) 18:01:00 rbarnes: I'm not that worried about punting on hard questions, because we don't have a lot of concrete proposals and APIs to work with. 18:01:19 ... once we have more concrete ideas to work with, these questions will be more easily resolved. 18:01:44 overall, the process seems pretty OK, yeah 18:01:46 +1, happy with the process. 18:01:46 +1 to proposal methodology 18:01:49 +1 18:01:49 +1 with the process 18:01:55 AdrianHB: Are we happy to continue working on proposals on the call? 18:02:00 +1 18:02:03 +1 18:02:10 +1 to the process (and evolving it) 18:02:17 AdrianHB: Ian will be sending out updated meeting details. 18:02:22 +1 with the process 18:02:22 Topic: Next meeting 18:02:35 28 Jan at noon ET / 5pm UTC 18:08:45 rrsagent, make minutes 18:08:45 I have made the request to generate http://www.w3.org/2016/01/21-wpwg-minutes.html Ian 18:08:48 rrsagent, set logs public 19:27:42 zkoch has joined #wpwg 19:33:33 zkoch has joined #wpwg 20:03:58 AdrianHB has joined #wpwg 20:27:13 zkoch has joined #wpwg 20:32:23 zkoch has joined #wpwg 20:36:30 zkoch has joined #wpwg 20:46:59 zkoch has joined #wpwg 20:49:45 zkoch has joined #wpwg 21:06:35 zkoch has joined #wpwg 21:17:20 zkoch has joined #wpwg 21:32:26 zkoch has joined #wpwg 21:37:05 zkoch has joined #wpwg 21:50:31 zkoch has joined #wpwg 22:10:00 zkoch has joined #wpwg 23:16:20 sam has joined #wpwg