23:11:05 RRSAgent has joined #wpwg 23:11:05 logging to http://www.w3.org/2015/10/28-wpwg-irc 23:11:27 adrianba has joined #wpwg 23:11:30 MattSaxon has joined #wpwg 23:16:11 jungkees has joined #wpwg 23:20:24 Rouslan has joined #wpwg 23:20:44 Present+ Rouslan_Solomakhin 23:24:25 ShaneM has joined #wpwg 23:25:00 rrsagent, this meeting spans midnight 23:25:12 present+ nicktr 23:26:31 lbolstad has joined #wpwg 23:27:19 zephyr has joined #wpwg 23:27:30 present+ MattSaxon 23:27:35 present+ zephyr 23:27:58 zephyr has joined #wpwg 23:28:14 present+ zephyr 23:28:47 Ian has joined #wpwg 23:29:02 padler has joined #wpwg 23:29:09 present+ padler 23:29:10 m4nu has joined #wpwg 23:31:46 agenda: https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015#Detailed_2 23:31:51 Chair: NIckTR 23:31:55 Scribe: Ian 23:34:12 CyrilV has joined #wpwg 23:34:33 Topic: Welcome 23:34:38 AdrianHB has joined #wpwg 23:34:45 Nick: Welcome to the inaugural WG meeting! 23:34:58 dezell has joined #wpwg 23:35:08 ...my inestimably charming co-Chair is Adrian Hope-Bailie 23:35:11 MattPisut has joined #wpwg 23:35:28 Ryladog has joined #wpwg 23:35:52 Present+ Cyril Vignet 23:36:10 present+ Kris_Ketels 23:36:19 present+ Jean-Yves_Rossi 23:36:21 Present+ ShaneM 23:36:24 present+ Cyril_Vignet 23:36:36 present+ Zach_Koch 23:36:38 mountie has joined #wpwg 23:36:49 jyrossi has joined #wpwg 23:37:27 Jiangtao has joined #wpwg 23:38:48 https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015#Detailed_2 23:38:58 https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015#Thursday.2C_29_October 23:39:02 zkoch has joined #wpwg 23:41:35 scribe: manu 23:41:50 Present+ Adrian_Bateman 23:41:51 Lars: Hi lars from Opera, interested in integrating payments into our browser 23:41:59 Present+ zkoch 23:42:01 Present+ Katie Haritos-Shea 23:42:02 Present+ dezell 23:42:05 kris has joined #wpwg 23:42:10 shepazu has joined #wpwg 23:42:10 Matt: Hi Matt from Worldpay, we're a payment service provider 23:42:12 yaso has joined #wpwg 23:42:14 dwim_ has joined #wpwg 23:42:36 Adrian: Hi Adrian from Microsoft, on Edge team, interested in shipping a payment solution quickly 23:43:09 Matt: Hi Matt, at Microsoft, lead development team for Microsoft payment services - we're exploring consumer payment scenarios, want to use a standards-based approach. 23:43:31 Nick: Is this a cross-org effort, like mobile? 23:43:50 Matt: I'm on product engineering side - all money that flows through Windows Store flow through our services 23:43:53 present+ Jiangtao 23:44:17 s/a payment solution/a payment API for the browser/ 23:44:21 Mountie: Mountie from Paygate, interest from payments and settlement standpoint. 23:44:31 present+ shepazu 23:44:48 AdrianHB: Adrian Hope-Bailie from Ripple, co-chair of this group - focusing on technical work and spec editing, driving more technical side of things. 23:45:18 Nick: Hi Nick, work in technology and innovation at Worldpay, one of the co-chairs of this group - focusing on operational side of this group. 23:45:54 Shane: Hi Shane McCarron, wearing Digital Bazaar hat, assisting w/ spec authoring/editing, I have 30 years of standards experience and Q/A experience, trying to help w/ test development. 23:46:28 Katie: Hi Katie Haritos-Shea, worked w/ JP Morgan Chase for last couple of years but moving on from that, working w. regulators - focusing on accessibility. Liason from WAI and PF WGs 23:47:31 q? 23:47:39 DavidE: David Ezell from NACS, I chair the Web Payments IG - when I started in 1999 we were working in XML - store operators had to spend 5,000 USD on hardware to support EDI processing... XML changed all of that - we want to remove unnecessary stickiness out of the system. We want to enable people to make payments w/o paying a great deal for that. 23:48:05 Doug: Hi, Doug from W3C, staff contact - newbie to payments, but very involved in W3C. 23:48:30 m4nu: Chair a number of CGs and initiatives at W3C. Digital Bazaar hopes to take a number of standards from this group to market 23:48:36 ...for retailers and financial services orgs 23:48:58 pat: I am here from the US Fed. Am interested in how web techs can help faster payments 23:49:06 Pat: Pat from US Fed, US Fed has undertaken a movement to go to more real-time payment system - interested in standardization and Web technologies - we want to go much faster/safer for payments. 23:49:23 scribe: Ian 23:49:31 Brett: Am here from Google; 23:49:40 Zach: Google chrome team...improve user experience 23:49:50 Cyril: I work for BPCE innovation dept 23:50:11 ...I have worked in payment system since 1987...SET...card payments...project manager for SEPA project for my company 23:50:23 ...I am interested in direct debit and credit transfer issues 23:50:36 ...interested in how we manage flows 23:50:52 ...also related to merchant accounting relationship to payments 23:51:06 Jean-Yves Rossi: I have a consultancy...we help people design new payment services 23:51:18 ....help people manage regulatory/supervisory matters in Europe 23:51:38 ...I have been involved in French banking groups and re-engineering of banking oversight in Europe 23:51:47 contribution to the Group : SCAI worflow 23:51:47 Kris: From SWIFT representing ISO20022...standards for 20 years 23:52:04 ...I see this as an extension to ISO20022 realm 23:52:05 wseltzer has joined #wpwg 23:52:23 wseltzer has changed the topic to: Web Payments WG: https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015#Detailed_2 23:52:25 ...am here to help with interop of this work and ISO20022 23:52:47 ...Also Vincent Kuntz will be the primary WG participant (and I will be the primary IG contact) 23:53:01 Rouslan: I work on Chrome team 23:53:12 Jiangtao: I am from Huawei 23:53:29 Zephyr: From Alibaba...hope to contribute from PSP perspective in China 23:53:45 Yaso: I I wear 2 hats...W3C Brazil Office and also representing NIC.br 23:53:54 ....steering committee of internet in Brazil 23:54:10 ...I want to help contribute to the standard and also its deployment in Brazil. 23:54:27 @@: Am here from Samsung Pay 23:54:47 s/@@/Dongwoo/ 23:54:52 @@: Also observing from Samsung. 23:54:57 and, work for Samsung browser team 23:55:05 ...we'll discuss with the payments team 23:55:18 nick has joined #wpwg 23:55:18 s/@@/Jungkee/ 23:55:31 Laurent_Castilo: Gemalto...we are interested in standardizing APIs for easier payment instrument integration 23:55:40 Nick_S: I am from Apple. 23:55:54 Laurent has joined #wpwg 23:56:09 NickTR: Over the next couple of days we will be looking for volunteer editors, test lead 23:56:17 ...think about that as we go along. 23:56:23 ...Dinner tonight? 23:57:23 http://www.w3.org/Payments/WG/charter-201510.html 23:58:40 Nick: Good to recall from our charter that we are standardizing API not UI 23:58:59 s/oversight in Europe/oversight in France 23:59:04 ...having said that, it is reasonable to hope for a more consistent user experience for users 23:59:18 ...and also good to remember we are not defining a digital payment scheme. 23:59:36 Charter deliverables: 23:59:38 http://www.w3.org/Payments/WG/charter-201510.html#deliverables 23:59:44 FPWD expected in March 2016 23:59:59 q+ 00:00:07 ack me 00:00:19 q+ Deliverable question around registration 00:00:36 q+ 00:00:49 q+ on expectations on implementation 00:01:09 IJ: Is "early implementations one year from now" reasonable? 00:01:16 (Some nodding) 00:01:17 ack MattP 00:01:32 Matt: There is not specified in the charter that there is not a way to register a payment instrument 00:01:42 (Charter says " Registration: A payment provider requests to register a digital payment instrument for use by the payer.") 00:01:48 q? 00:02:09 AdrianHB: I think we are going to have to have registration (but not only through a browser) 00:02:31 MattPisut: There won't be a way for a DEVELOPER to add a payment instrument 00:02:59 Mountie: Data flow will be different depending on whether wallet is on client or server side 00:03:10 ...we'll need to be able to talk about registration both client-side and server-side 00:03:24 ack manu 00:03:31 m4nu: I think the timeline has a high chance of being unrealistic. 00:03:35 ack M4nu 00:03:35 m4nu, you wanted to comment on expectations on implementation 00:03:44 ...given something as complex as payment 00:04:06 q+ 00:04:07 ...Microsoft is saying we want to ship quickly, and that's great, but we don't want to hinder the viability of the Web Platform for doing payments 00:04:21 ...for developed and developing economies 00:04:28 q? 00:04:31 ...I want us to be sure to take into account the long-term future 00:04:44 q+ to talk about use case structure for "agile" 00:04:52 ...so I think the timeline is aggressive, but let's be sure we make good long-term decisions for the platform 00:04:59 ack Adrianba 00:05:23 adrianba: Our goal is to iterate. We want to make progress on something useful and expand scope over time 00:05:24 +1 00:05:43 NickTR: The scope is deliberately narrow. 00:05:52 ...scope increase would involve recharter 00:06:08 q? 00:06:17 ack dezell 00:06:17 dezell, you wanted to talk about use case structure for "agile" 00:06:19 ack dezell 00:07:01 jmr has joined #wpwg 00:07:10 dezell: We may need to restructure the use cases to ensure we can shed use cases if we want in order to ship sooner 00:07:22 zakim, close the queue 00:07:22 ok, Ian, the speaker queue is closed 00:07:39 shepazu: I would not like this WG to spend a lot of time discussing use cases 00:08:50 Topic: Capabilites 00:08:55 zakim, open the queue 00:08:55 ok, Ian, the speaker queue is open 00:09:31 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/W3C_TPAC_Web_Payments%20Capabilities_IG.pdf 00:10:36 padler: I'd like to review the flow and also the thing we are going to work on 00:11:37 Quick summary of categories of "capabilities" 00:11:43 * Core/security 00:12:00 * Identity/Credentials 00:12:41 * Accounts and ownership 00:12:44 * Clearing and settlement 00:12:46 * Commerce 00:12:58 padler: We think this framing is important to coordinate work and prevent redundancy 00:13:05 ...and reuse of materials that are related to payments in a variety of ways 00:13:24 ...e.g., payments may require security or credentials 00:13:34 ...I think we will encounter accounts and ownership 00:13:49 ...I'm going to send a payment request, where do I get details about accounts and assets in those accounts? 00:13:59 ...clearing and settlement is about messages and movement of funds 00:14:09 ...last bucket is commerce (discounts, coupons, rewards, invoicing) 00:14:19 ...those are more "relationship based" and not directly about transfer of funds 00:14:46 Doug: Is this an agreed upon delineation? 00:15:06 Pat: Generally, though there may be additional (e.g., UI) or refinement, but generally agreed upon that these are part of the problem space 00:15:18 Matt: Cross section of capabilities in the IG and what the WG says 00:15:41 ...how will we keep focus? 00:16:00 padler: Understanding that the IG is wrestling with other topics and we are also looking at the scope of this WG 00:16:35 ...the WG may find it needs something (e.g., related to identity) and can raise the question with the IG to find out who is working on the topic 00:16:57 q? 00:17:30 Ian: One way the IG was coordinating their work - what exists today, what doesn't exist - who should work on it - that's Roadmap, what is capabilities, use cases help refine everything. 00:17:44 Ian: Capabilities help us talk about big vision for Web Payments 00:17:56 Ian: From time to time, we will propose WG charters for gaps in functionality. 00:18:14 Matt: ok, that makes sense - how do we manage the overhead? 00:18:33 Ian: That's the Web Payments IGs job - I don't want IG work to be a burden for the WG. That's not our job here. 00:19:01 NickTR: So, there's a task for the IG to say how capabilities map to Web Payments WG 00:19:15 Ian: Yes, we should figure that out - there is some coordination role. 00:19:49 Matt: So, can we update the charter? 00:19:50 Shane: No 00:20:10 Ian: We will have to adapt how we talk about things in this group based on IG identification of capabilities. 00:20:19 IJ: I expect that the WG experience will flow back to the IG to shape our thinking 00:20:34 q? 00:21:16 padler: When you think about payments and commerce, the reality is that I may start a transaction in a store and then complete it at home in my browser. 00:21:17 Pat: Series of messages between parties - There are lots of cases where you walk into store, get offer, then leave the store. When I get home, I log into browser, I complete transaction. 00:21:25 ...when you think about payments and commerce it's a series of interactions between parties 00:21:37 ...I think it's valuable to think about capabilities in terms of communications between 2 parties 00:21:39 q+ 00:21:53 ...the WG may have an easier job if we can decompose the flow into smaller 2-party interactions 00:22:06 ....and how they fit together...and then we compose them into broader functionality 00:22:26 ...so rather than look at use cases end to end (as we do today in the use cases) we want to break down into atomic pieces 00:22:53 q- 00:23:02 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/paygent_connect.svg 00:23:18 (Some diagrams) 00:23:31 pat: We have wrestled with what to call the "thing we are focused on" 00:23:36 ...payment agent, user payment agent, wallet 00:24:13 ...originally we thought of a payment agent as an abstract thing that exchange data with other entities (and could be a browser) 00:24:29 pat: A wallet is just a specific type of payment agent. So is a car. 00:24:34 q+ 00:24:50 ...but we could call this "the payer's user agent" or the "PSP's user agent" 00:25:00 ...that's useful where you are dealing with things like loyalty coupons 00:25:02 ack nick 00:26:12 q+ 00:26:22 q+ 00:26:34 pat: I think wallet is not useful for some use cases....think we should have another term but that includes wallet use cases 00:26:35 q+ 00:26:38 q+ 00:26:40 ...e.g., point of sale terminal. 00:26:55 q+ to stop terminology discussion until we get further along. 00:26:59 pat: I think when we are writing specs it becomes more useful....I'm just exchanging point it's not a payment or my wallet, it's a loyalty dialog 00:27:16 +1 to avoid wallet which is a confusing term 00:27:20 IJ: I don't think we are far enough along to motivate this change from our charter 00:27:32 we can’t avoid wallet, it’s *in the charter* 00:27:39 AdrianHB: Today is a level-setting day and definitions are part of that...but we have "wallet" in our charter. 00:27:57 q? 00:27:58 q-, adrian has basically addressed what I wanted to say 00:28:03 q- 00:28:11 AdrianHB: we are defining things by what they do 00:28:26 ...we may decide that there are other functions that wallets have, but not sure that in this WG we need to do more 00:28:27 ack mountie 00:29:08 mountie: I don't understand clearly some uses of wallet 00:29:11 ...client or server side 00:29:21 ...does payment scheme belong to the wallet? to the instrument? 00:29:26 ...I think we need some pictures to help 00:29:32 q? 00:29:42 ack Laurent 00:29:44 ack Laurent 00:30:25 ack CyrilV 00:31:00 q? 00:31:43 CyrilV: we need to be sure to be explicit about different actors 00:32:05 q- 00:32:05 ack m4nu 00:32:11 NickTR: I hear that we need more work to agree on terminology 00:32:16 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/paygentbase.svg 00:32:37 pat: the IG worked early on on functionality 00:32:40 ...payer/payee/psp 00:33:18 ....we did this categorization 00:33:20 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/model_1A_user_agent_pass_thru.svg 00:33:28 ...in order to be able to talk about flows in a consistent way 00:33:50 (Pat walks through flow diagram) 00:34:42 q+ 00:36:00 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/model_1B_out_of_band_proof_of_payment.svg 00:36:57 (Different routing option for payment response) 00:37:19 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/model_3_P2P_Payment_Proximity.svg 00:37:24 (person-to-person) 00:39:18 q+ to focus on simple flows first, then more complex 00:39:41 q+ to focus on minimum viable payment flow, but not loose focus on more complex flows. 00:39:45 MattS: The diagrams are helpful...it's important that we as quickly as possible have flows to focus on 00:39:56 ack CyrilV 00:41:50 q+ 00:42:21 ack m4nu 00:42:21 m4nu, you wanted to focus on simple flows first, then more complex and to focus on minimum viable payment flow, but not loose focus on more complex flows. 00:42:23 ack m4nu 00:42:36 m4nu: The flows are helpful but too abstract for me 00:42:42 ...I think we should focus on the minimal flow 00:42:52 ...understand how it maps to browser API will be helpful 00:42:57 ...we should not find every single flow 00:43:07 ...we should start on a simple well-known flow like a card payment online 00:43:18 ...we should get comfortable with that. 00:43:28 ...then people who know other flows (e.g., ACH) works with the API we are coming up with 00:43:31 q+ 00:43:46 ack zkoch 00:43:47 ack zkoch 00:44:01 zkoch: The flows are nice as test cases. 00:44:13 ...I think they are useful and send a signal when the designs don't work with the flows 00:44:17 q+ to clarify intent of flows.. 00:44:37 ...also would be useful for our colleagues from Aliababa, CIPO, etc. to let us know about local flows that we are not yet addressing 00:44:51 ack kris 00:45:42 q+ 00:45:54 kris: I agree with Manu..the best way is to come up with our flows and then see if our term wallet still works across these scenarios 00:46:02 ack padler 00:46:02 padler, you wanted to clarify intent of flows.. 00:46:30 padler: The reason to work on the flows originally was to come up with a consistent taxonomy 00:46:48 ...we wanted to be able to focus on specific messages 00:47:21 ...it was important to me to have a consistent way to talk about flows 00:47:26 ack nick_s 00:47:28 ack nick_s 00:47:48 nick_s: We did define what wallet means in the charter; I'm wary about changing those definitions 00:48:47 (Review charter goals) 00:49:04 q+ to comment on slide.. 00:49:14 (Review of benefits we expect as well from the solution) 00:50:04 AdrianHB: A payment instrument is a thing with an API, that has execution logic. 00:50:19 ...it may store credentials....but it can be communicated with 00:50:24 ..it is a front for a payment service provider 00:50:36 q+ 00:51:15 ack padler 00:51:15 padler, you wanted to comment on slide.. 00:51:44 nick_s has left #wpwg 00:51:48 nick_s has joined #wpwg 00:52:17 AdrianHB: "Roles" rather than actors. So "role of wallet" may be taken on by various actors 00:52:45 ack CyrilV 00:52:50 wonsuk has joined #wpwg 00:53:14 +1 to Adrian's point 00:53:18 q+ 00:53:19 Cyril: W3C should not revisit 20 years of terminology in the financial services industry 00:53:38 ...payment schemes include rules 00:53:52 q+ 00:53:59 ...I strongly disagree with the definitions that Adrian has in his slides 00:54:08 ...people will look at us and say "They don't understand payments" 00:54:14 ..and people will look at the work and not understand it. 00:54:34 q+ we're in a terminology discussion again, we should stop and move on 00:54:47 q+ to say we're in a terminology discussion again, we should stop and move on 00:54:52 AdrianHB: We need definitions for the roles of components in our system 00:56:22 NickTR: There is still work to do on terminology 00:56:28 ack nick_s 00:56:33 Cyril: I'm ok with the definitions in the charter; not Adrian's paraphrasing 00:56:41 q+ 00:56:50 zakim, close the queue 00:56:50 ok, nicktr, the speaker queue is closed 00:56:52 nick_s: the end goal is to define standards for users, which here is end users of the web, developers, financial institutions. 00:57:02 ...they all have differing definitions...and I think it will be difficult to satisfy everyone. 00:57:19 ...in Apple pay we expose the term "payment instrument" but it can be confusing for some 00:57:39 rbarnes has joined #wpwg 00:57:45 ack jyrossi 00:57:47 +1 to Nicks point 00:57:58 jyrossi: I am wary of Adrian's definitions...can be misleading 00:58:13 jyrossi: payment scheme implies rules 00:58:47 AdrianHB: Let me explain how I got to these points...in the charter we talk about a payment request that comes from the merchant, and lists the payment schemes that are accepted by the merchant. 00:59:14 ...I am trying to simplify for some audiences (perhaps oversimplifying) 00:59:22 q? 00:59:26 ack m4nu 00:59:26 m4nu, you wanted to say we're in a terminology discussion again, we should stop and move on 00:59:43 ack 01:00:23 I am not totally sure we can suspend disbelief of definitions for the next two days if we plan to discuss messaging and architecture in those two days, they seem rather intertwined 01:00:31 …as loathe as I am to spend any more time discussing it 01:00:43 q+ 01:01:00 +1 to Nicks point 01:01:13 01:01:14 q? 01:01:17 ack mountie 01:01:25 zakim, open the queue 01:01:25 ok, Ian, the speaker queue is open 01:03:06 wonsuk has joined #wpwg 01:06:46 AdrianHB has joined #wpwg 01:08:07 wonsuk has joined #wpwg 01:27:38 wonsuk has left #wpwg 01:29:30 I has joined #wpwg 01:30:11 lbolstad has joined #wpwg 01:31:39 padler has joined #wpwg 01:32:00 nick has joined #wpwg 01:32:16 zkoch has joined #wpwg 01:33:00 rbarnes has joined #wpwg 01:33:46 Jiangtao has joined #wpwg 01:37:18 AdrianHB has joined #wpwg 01:37:30 wonsuk has joined #wpwg 01:38:10 topic: Proposal from Zach 01:38:40 https://drive.google.com/a/google.com/file/d/0B6Su47MQXuKZdVhwd0sta1NBaE0/view 01:38:53 rouslan has joined #wpwg 01:39:58 Zach: I will talk about payment instruments. 01:40:07 ...I will talk about them the way users think about them 01:40:12 ...I will avoid the word wallet 01:40:19 ...I think there are two big goals 01:40:26 a) Easier and faster to buy things on the (mobile) web 01:40:31 could we have the link in the IRC ? 01:40:35 b) Bring better, more secure payments to the web platform 01:40:41 https://drive.google.com/a/google.com/file/d/0B6Su47MQXuKZdVhwd0sta1NBaE0/view 01:40:41 one minute 01:41:38 discourse.wicg.io/t/rfc-proposal-for-new-web-payments-api 01:42:44 (Ian note for later based on discussion with MattP on two ways to identify instruments: by name or by class) 01:45:08 Zach: This example assumes we will define "visa" as a payment instrument. 01:45:15 ...we link payment instruments by domain 01:45:33 ...but for some well-deployed schemes we may have shorter strings (e.g., a card network name such as "visa") 01:46:40 Kris: I think what you have shown is great,t and the relation to ISO20022 is that the information is already described 01:46:51 ...if we don't have these things yet in ISO20022 we can add/extend 01:47:31 Cyril: You need a reference to the transaction 01:47:56 ...data we don't need to describe here, but is important so that the merchant can map the money they receive to a transaction 01:48:04 q+ to make an observation about parameter names 01:48:07 q+ to clarify remittance data.. 01:48:13 q+ 01:48:15 q+ 01:48:31 ack padler 01:48:31 padler, you wanted to clarify remittance data.. 01:48:35 zkoch has joined #wpwg 01:49:07 padler: Remittance data about the payment...it's where a lot of legacy systems don't allow passing that payment...it turns out to be critical to pass it along with the payment 01:49:46 correction.. remittance data is information about the payment and what it is for... not the payment itself.. 01:50:04 Zach: I am not sure we need it...but let's come back to it 01:50:09 ack AdrianHB 01:50:09 AdrianHB, you wanted to make an observation about parameter names 01:50:26 AdrianHB: You've got two params: supported instrument and also "scheme data" 01:50:34 q- later 01:50:36 ...we are going to have to figure out which is which 01:50:42 Zach: Point taken 01:50:43 q? 01:51:02 Laurent: I love the proposal but have some feedback.... 01:51:12 I will wait until after the next few slides 01:51:25 (We decide to go through the whole presentation) 01:51:46 Zach: First example is simple but there's no communication channel between browser UI and the app 01:51:54 ...suppose we want to include address which affects price 01:52:02 ...we need to enable the merchant to update the request 01:52:11 ...so in the next example we have 2 promises 01:52:31 ...original promise returns an object...that object supports events 01:52:40 ..the user agent can alert the merchant that something took place 01:52:51 ...there are methods the merchant can call to update the original request 01:53:05 ...so there is a communications channel between merchant and user agent 01:53:16 ...where there is support for events and callbacks 01:53:33 ...you can imagine a world where there is a paymentInstrumentChange event and the merchant could update the price based on the selection 01:53:44 zkoch has joined #wpwg 01:54:09 ...the second promise is the instrument response promise 01:55:11 IJ: So promise 1 is unlimited number of events; promise 2 is the "last thing that is really needed by the merchant" 01:55:13 Zach: Yes 01:55:23 (Review of flow from a high level) 01:55:53 ....first promise has any events (not just shipping address; could be any) 01:55:57 q? 01:56:05 ...there's a thing on the diagram "scheme-specific payment auth" 01:56:07 q+ 01:56:29 ...from the perspective of our API, we don't care how auth happens 01:57:59 Zach: Assumption here that the merchant and payment instrument have a relationship and the merchant understands how to parse the response 01:58:04 Jiangtao_ has joined #wpwg 01:58:24 Pat: the user agent doesn't care about how the payment method is implemented behind the scene, but does need to know how information goes back and forth. 01:58:38 ...I would use the phrase "payment method" not "payment instrument"... 01:58:47 Zach: +1 to continued work on the terminology 01:59:27 (nodding about term "payment method") 01:59:32 q+ 02:01:10 Zach: So the merchant is waiting for the response...they have the reference to the original request....so that's why it's not clear to me that you need additional transaction data. 02:01:25 ...since the merchant is waiting around for a response to the original request. 02:01:51 q+ to hear Alibaba's response to the proposal 02:02:04 Zach: there are methods for registering payment instruments....I propose we use a manifest file. 02:02:18 Manifest for a web application 02:02:23 http://www.w3.org/TR/2015/WD-appmanifest-20150921/ 02:02:32 We could also expose registration API on the merchant's web site 02:02:36 ...we do this all the time in user agents. 02:02:49 ...the user agent can choose to honor or not 02:03:01 ...the site can request to install the payment instrument and the user can say yes or no 02:03:14 ...I think we should standardize ubiquitous responses like credit cards 02:03:27 ...that way merchants don't have to account for PANs in different ways 02:03:40 ....in the base case, a payment instrument could be an embedded iframe 02:03:49 ...works in all browsers and platforms 02:03:55 ....Some open questions at the end of the presentation 02:04:05 q? 02:04:07 ack Laurent 02:04:15 q+ 02:04:18 ack nick 02:04:25 q+ 02:04:36 q+ to ask about "addresses" being credentials 02:04:50 nick: How do we let merchants know that instruments are available before the payment request? 02:05:01 Zach: I suppose you could return a boolean and stay privacy sensitive. 02:05:24 Nick: Standardizing credit and debit may be interesting...but please note that some methods are ubiquitous in the west but not everywhere 02:05:51 AdrianHB: The charter lets us focus on debit and credit cards (as a Note) 02:06:08 Nick: Could you speak to why this is a javascript only approach rather than any markup. 02:06:17 zkoch has joined #wpwg 02:06:23 q+ to talk about doing JS first; declarative later 02:06:27 Zach: I think you could easily do this as a declarative approach...I don't have a strong opinion about it. 02:06:34 q+ 02:06:41 ...I think programmatic access will be common for developers 02:06:51 NIck: I don't think we need to choose one or the other 02:06:53 ack I 02:07:19 Mountie: If the payment process takes multiple days, or if payment happens in multiple steps, then your suggest does not cover those scenarios 02:07:27 ...do you think that the payment instrument is bound to one domain? 02:07:41 ...not clear that binding payment instrument to domain a good idea 02:08:14 ...third comment - you mentioned iframes. But iframe may not be enough for security (e.g., keyjacking, etc.) 02:08:41 Zach: I think that the 3Dsecure case may not be part of this API...we should sit down and walk through the flows 02:08:58 ...and if the approach does not accommodate flows we should adjust the proposal. 02:09:31 ...we can also talk about iframes special cased by the browser 02:09:50 ...regarding binding methods to domain names, a method may accept multiple schemes 02:09:56 ...we might want to accommodate that 02:10:12 ..as to the domains themselves, I don't know how to do this outside of domains. 02:10:18 zkoch has joined #wpwg 02:10:29 Mountie: Blockchain? 02:10:37 Zach: Please suggest this as an issue on the github page 02:10:42 ack j 02:10:50 q- ShaneM 02:10:52 -> https://github.com/WICG/paymentrequest/issues GitHub issues page 02:11:11 jyrossi: I like the proposal. The only thing that makes me a bit uncomfortable has to do with trends in how merchants do payments...growing risk that payment could be revoked. 02:11:25 ...in the drawing there is one go-and-return 02:11:41 ...due to the growing risk that the payment could be revoked, the payment instrument is providing some kind of insurance solutions 02:11:44 ...but they are costly 02:11:52 ...merchants are mitigating between paying for insurance or taking risk 02:12:05 ..if you integrate such a capability, you won't have just one round trip, you'll have two 02:12:48 Zach: Suggest you add that to the issues list 02:12:52 q? 02:12:57 ack MattPisut 02:12:57 MattPisut, you wanted to hear Alibaba's response to the proposal 02:13:12 Matt: Thanks, I think the proposal makes a lot of sense. 02:13:22 mountie has joined #wpwg 02:13:26 ...for payment providers like AliPay and PayPal where there is a redirect 02:13:47 ...in AliPay case, the funds are captured at that point; PayPal can work that way as well 02:14:02 ...I hear in the proposal that you say "Go do AliPay as usual" and the merchant would do that experience as today 02:14:13 Zach: I can think of multiple ways to approach this question given this architecture 02:14:19 ...e.,g they could transfer funds immediately 02:14:37 q+ to build on Matt's question and tie it back to the flows discussed earlier.. 02:14:40 ...they could also do something where they authorize funds, generate a key, send back to the merchant, and the merchant does something with their private key 02:14:44 MattPisut: +1 02:16:28 ack kris 02:16:28 ack Kris 02:16:55 Kris: I would like to see whether we are going to use markup 02:17:12 AdrianHB: The purpose of today is to put all the information we've gathered on the table ... get ideas together 02:17:23 ...and record questions 02:17:27 rrsagent, make minutes 02:17:27 I have made the request to generate http://www.w3.org/2015/10/28-wpwg-minutes.html adrianba 02:17:40 zakim, set logs public 02:17:40 I don't understand 'set logs public', Ian 02:17:49 rrsagent, set logs public 02:18:53 Meeting: Web Payments Working Group F2F 02:19:05 shepazu: A good thing to do is write an alternate proposal if you think you have different perspectives 02:19:07 q? 02:19:08 q? 02:19:16 evanschwartz has joined #wpwg 02:19:29 Group's mailing list -> https://lists.w3.org/Archives/Public/public-payments-wg/ 02:19:42 NickTR: We need to talk over the next couple of days about how we are going to work operationally 02:19:56 q? 02:19:59 ack Cyril 02:20:01 ack CyrilV 02:20:26 CyrilV: We need a trace of consent to pay and consent to deliver. 02:20:33 ...so I think we need to have transaction information 02:21:16 ...I think we need in at least some schemes that we will need transaction information for merchants (e.g., for accounting) 02:21:20 q+ 02:21:38 ....I also want to see flow of credit transfer (and also direct debit) 02:23:22 ack m4nu 02:23:22 m4nu, you wanted to ask about "addresses" being credentials 02:23:45 m4nu: Overflow idea, promise-based...love it 02:24:03 ...some things seem to me to be the space of credentials 02:24:15 ...such as address 02:24:23 ..there's shipping address, billing address, proof of age, etc. 02:24:25 nick has joined #wpwg 02:24:29 q+ 02:24:34 ...if we start working on that stuff, it distracts this group from setting up the payment 02:24:44 schuki has joined #wpwg 02:24:50 AdrianHB: There's a note for discussion about securing data 02:24:52 +1 to Manu, plus it's User credentials, we already have to care about merchant and instruments credentials 02:24:54 present+ schuki 02:24:55 I believe addresses are absolutely within this group’s purview and should not be left to the credentials CG 02:25:09 m4nu: There's a lot of JSON being suggested; messages need to be extensible however. 02:25:23 ...merchants and payment schemes wants something that is extensible. 02:25:23 kris has joined #wpwg 02:25:41 ...one way at W3C to do this is to use a registry, another is to use the linked data approach; we will need to discuss 02:26:13 Zach: I want to address shipping address since so critical. I expect that we will have to address extensibility (though I think JSON is extensible) 02:26:15 ack MattSaxon 02:26:32 As to payment address - it is one of many things that a merchant might request. The API should have a way for a merchant to request X 02:26:37 MattS: I like the flow. 02:27:05 ...question about instrument response -is there an option for the merchant to say "I don't like this response"; I think that's important to the merchant 02:27:36 Zach: that's not part of this proposal; one assumption of the system is that if you choose to support a payment method you are expected to support what you get back 02:28:54 Discussion point: PSP declines a transaction...there's an authorization failure 02:29:09 MattS: Question is whether the user agent has a response in the case of authorization failure 02:29:36 Zach: After you submit a request in android pay, there's a way for android pay to take action..the more I think about this, the more I think this is a good question. 02:29:50 MattS: There could be some magic on the merchant side that we should be discussing 02:29:58 Zach: I can see an optional layer. 02:30:01 q? 02:30:33 adrianba: We should differentiate in the flow diagram between the the merchant on the server side...and ... 02:30:59 AdrianHB: I think the standard doesn't have to tell the merchant what happens next; the merchant can decide...but it could be in scope to discuss 02:31:08 We should clarify the flow diagram in Zach's proposal to differentiate between the web page that calls the paymentRequest method and the service side communication 02:31:09 MattS: On delegation.... 02:31:27 ...I'm wondering whether your flow allows the response to be proxied. 02:31:30 Zach: Right now; no. 02:31:47 ...I don't think that it's in our best interest to interject ourselves into that relationship 02:32:00 MattS: I think that delegates a lot of work to the merchant; but many merchants prefer simplicity 02:32:12 ...I think we need to look at how the merchant interface needs to be delegated to the PSP 02:32:41 ack padler 02:32:41 padler, you wanted to build on Matt's question and tie it back to the flows discussed earlier.. 02:32:43 We now have on the white board for flows: 02:32:46 - credit card 02:32:48 - credit transfer 02:32:51 - Alipay 02:32:53 - direct debit 02:32:54 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/model_1A_user_agent_pass_thru.svg 02:32:57 - Proxy flows for PSPs 02:33:01 - 3DSecure 02:33:29 padler: We are trying to fix that the user does not need to send details to merchant's back end to be paid 02:33:51 ...whether the PSP is locally invoked or remote, that seems to be the first delineation 02:34:21 ...who declines the payment? If I invoke my payment processor and my payment processor says no, I need as a user to be able to choose an alliterative instrument. 02:34:55 padler: how do I reply that the payment was successful? Is it from the browser? Or do I provide enough information so that the payment service provider can send information directly back to the merchant? 02:34:57 https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/model_1B_out_of_band_proof_of_payment.svg 02:35:06 q? 02:35:16 zakim, close the queue 02:35:16 ok, nicktr, the speaker queue is closed 02:35:24 padler: It feels to me the key delineation is: (1) how do we prep the payment (2) how do we @@ 02:35:29 ack Laurent 02:35:57 Laurent: I think we also need to have a flow where the instrument response goes back to the merchant on the server side 02:36:08 ...I am thinking of the base credit card use case 02:36:27 Zach: I think that this proposal accounts for that...we need to whiteboard the flows 02:36:56 Laurent: Do we want to normalize these flows or just use them as examples? 02:37:10 ...what I like in this proposal is that there are a lot things left to the merchant side 02:37:20 ack nick 02:37:29 ...but need people in industry to understand what are examples v. normative 02:37:40 nick: Re shipping address..I think it's important and should be part of this group. 02:37:48 ...when I say it's not always a credential. 02:37:58 ...address is a transient location... 02:38:10 ...I think we need to cover card payments and billing address is required 02:38:13 +1 to comment abt transient location being important.. 02:38:25 Github issues page: https://github.com/WICG/paymentrequest 02:38:27 FYI there are terms in the schema.org vocabulary that we should be able to take advantage of. 02:38:27 ...we'll need to define something for address; I don't want to wait for a group that's not yet be chartered 02:38:31 Post issues there so we can keep track and think about :) 02:38:48 +1 for Nick's address point 02:38:52 ShaneM: Some of those things are special cases of a more general activity 02:38:59 Nick: Agreed. 02:39:05 topic: Manu's proposal 02:39:08 Credentials CG Proposals: https://docs.google.com/presentation/d/1Zx-wbg_vxsEuRInM64Y4xm7SdO_E6KO_qQ8abSExFkU/edit 02:39:13 s/Manu's/Web Payments CG 02:39:19 rrsagent, make minutes 02:39:19 I have made the request to generate http://www.w3.org/2015/10/28-wpwg-minutes.html Ian 02:39:32 m4nu: Lot of agreement between this proposal and Zach's 02:39:36 ...the general form of the API 02:39:44 ...I will focus on the points that are not as aligned 02:40:16 ...the CG has been working for 4+ years...this proposal is the latest thinking 02:41:51 (Manu walks through presentation) 02:42:18 There are also lots of E-Commerce vocabulary items at http://purl.org/goodrelations/ 02:42:47 https://web-payments.org/specs/source/web-payments-messaging/#message-formats 02:43:24 q+ 02:43:30 zakim, open the queue 02:43:30 ok, Ian, the speaker queue is open 02:43:33 q+ CyrilV 02:43:59 slightlyoff has joined #wpwg 02:44:00 m4nu: The examples show that there's a URI for the service for handling payment requests 02:44:12 gjaya has joined #wpwg 02:44:57 m4nu: The point is that different organizations would specify what the data is necessary for different instruments 02:45:30 m4nu: Next we look at payment request initiation data blobs 02:45:59 ...merchants can include whatever information they want into the message 02:46:11 ...there's a digital signature at the end 02:46:21 q+ 02:46:32 Currency names are in ISO 4217; Country codes are in ISO 3166 02:46:34 ...you shouldn't be able to tamper with the message 02:47:28 ... note that if we have weird currency names that are outside of ISO 4217, maybe they could be scoped (ala CURIEs) 02:47:31 ...there's another example of a request with multiple accepted schemes 02:48:03 ...there's a longer example of an ISO20022 payment request that can be translated directly to XML 02:48:03 of course BTC would not be a currency in ISO world 02:48:21 q+ 02:48:24 m4nu: So we have extensible messages; the routing is the domain of the APIs 02:48:27 ack CyrilV 02:48:28 q+ to clarify where/how money transfer takes place compared to other proposal 02:49:16 q+ to ask about paymentCompleteService. 02:49:20 Cyril: You need more information than "Visa' you need information about the bank that issues the visa 02:49:26 ...you have a "Barclay's Visa" 02:50:49 Cyril: Note that ISO20022 is not a scheme 02:50:57 ...it's EPC 02:51:40 ...so you need the scheme but also the issuer 02:51:44 q? 02:52:01 s/EPC/SET 02:52:41 q? 02:53:18 Cyril: Things to taken into account...timeout (e.g., bitcoin request) 02:53:23 ...there are periods of uncertainty 02:53:25 q+ 02:53:29 ...to have a more concrete consent to pay 02:53:36 q+ 02:54:06 ack MattS 02:54:25 CyrilV: Signature works for me as a form of consent 02:54:46 MattS: Let's look at example in 2.1 02:55:18 ...the payment request service ... is the intention is when I want to authorize I go to pay.example.com ? 02:55:38 m4nu: Potentially. 02:56:02 MattS: I'm happy with a non-specific response. 02:56:51 Mountie: We need to discuss same origin policy 02:56:54 m4nu: Agreed 02:56:57 ack zkoch 02:56:57 zkoch, you wanted to clarify where/how money transfer takes place compared to other proposal 02:57:05 Zach: Are you taking a stance on when money is transferred? 02:57:07 m4nu: No. 02:57:08 q+ 02:57:11 ack mountie 02:57:13 ack mountie 02:57:36 m4nu: In the REST case, it could be that this URI is where you send the request. But in a promise-based flow the data you provide could be other. 02:57:54 ...so there is no stance...the data that is provided is whatever people need to provide 02:58:08 AdrianHB: Could be, for example, UI to display.... 02:58:18 ack dezell 02:58:18 dezell, you wanted to ask about paymentCompleteService. 02:58:19 q? 02:58:26 ack me 02:59:00 ack Laurent 02:59:07 m4nu: Payment complete service could be a service where you post information 02:59:28 I’m happy to wait 02:59:46 m4nu: Message format takes some positions: 02:59:47 q+ 02:59:49 - not xml-based 03:00:05 ...even though the financial service industry is powered by XML 03:00:27 ...JSOn-based messages...extensibility is vital 03:00:36 ....we want to future proof the solution 03:00:43 ...JSON-LD provides an extensibility story 03:00:59 ...communication is HTTPS only 03:01:39 ...we need to make sure that we support card, bitcoin, ACH, SEPA, etc. 03:01:51 ...we may also want to support non-scheme digital signatures 03:02:02 q+ 03:02:08 ...for things like offers of sale or invoices which we may pick up when we start work on ecommerce things 03:02:15 q+ to consider if we want to tie ourselves to a dependency like JSON-LD 03:02:19 (Regarding the APIs) 03:03:28 * Should be a browser API and a REST API 03:03:43 m4nu: the browser API looks like Zach's proposal 03:03:45 +1 for other transport mechanism supports 03:05:04 q+ 03:05:20 m4nu: When the request is sent to another site...the site needs to be able to say "I've done the interactions I need to do such as 2 factor auth" 03:05:30 ..then the PSP or paypal or google wallet or whoever has executed the initiation of the payment 03:05:49 ...they put together something we call an "acknowledgment" (of receipt of the request) 03:06:00 ...the acknowledgment resolves the promise on the merchant side 03:06:16 ...the only thing that really differentiates the two proposals is that: 03:06:19 q+ 03:06:19 * We are using linked data 03:06:27 * Strong separation between messages and APIs 03:06:29 * Signatures 03:06:37 ack kris 03:07:00 q+ to ask about transforming message serializations (JSON, XML) 03:07:09 Kris: I think that "supporting ISO20022 messages" is missing apples and oranges 03:07:20 ...do you mean "ACH format" 03:07:38 ...if so you need to be clearer that we would be creating an ACH-formatted message in the payments sphere which doesn't make sense 03:07:46 ..if we are talking instead of payment instruments we need to fix this 03:08:20 ..example, we can do ACH-batched transfers at our company, and our hope is that our bank would give us a payment instrument 03:08:38 Cyril: There is no ACH method 03:08:56 NickTR: In the US it's different; that's the source of confusion 03:09:01 Kris: We should clear up slide 5 03:09:29 q? 03:09:36 ack Laurent 03:10:03 Laurent: I wanted to highlight an interesting difference between CG and Zach proposal: 03:10:11 ....different prices for different ways to pay. 03:10:16 ...that's possible in Manu's proposal 03:10:23 ...you may also want to the same for signatures 03:10:40 ..the signature itself may depend on the scheme 03:10:40 q+ 03:10:55 q+ to suggest that the request could ask for additional information for each scheme in a merchant request 03:10:56 m4nu: The proposal is to have two layers : one scheme-specific, but a second one that would come from this group... 03:11:02 q? 03:11:07 ...you can't use scheme specific mechanism for an offer of sale 03:11:08 ack nick 03:11:10 zakim, close the queue 03:11:10 ok, Ian, the speaker queue is closed 03:11:26 nick: Thanks to m4nu and zach for the proposals. A comment on both. We are missing "Discovery" 03:11:33 ...how a server knows that this API is available 03:11:45 ...we need to consider that, which brings me to another point: i don't see substantial discussion of privacy 03:11:51 ...I'd like to see that in more detail 03:11:59 ...how we can avoid these APIs being abused 03:12:08 q? 03:12:13 ...eg., in the case of a REST API you could rapidly interest to determine what one has in a wallet 03:12:17 ack Cy 03:12:18 ack CyrilV 03:12:59 Cyril: I think that we may need signatures everywhere even if we have HTTPS everywhere. 03:13:24 ...the message needs to be protected as well 03:13:44 ...the message should be signed 03:13:51 q? 03:14:21 Rouslan has joined #wpwg 03:15:03 CyrilV: There may be a need for another layer to parameterize how payment happens (e.g., installment) 03:15:09 ...lots of merchants ask for that 03:15:35 ...and how the user chooses to pay may affect things like fees 03:15:54 q? 03:15:56 ack MattSaxon 03:16:03 building discount capabilities into the payment offer. 03:16:33 (More notes on API from Manu 03:16:36 - promise-based 03:16:43 - browser mediates flow via same origin policy 03:16:52 - centralized discovery of payment instruments 03:16:54 - polyfillable 03:18:42 (Remaining work) 03:18:50 - steal from Zach's proposal the good bits 03:19:06 - ensure in-scope flows supported 03:19:16 - Web Payments REST API spec 03:19:21 - Detail discovery and process 03:19:30 zakim, close the queue 03:19:30 ok, Ian, the speaker queue is closed 03:20:16 MattS: In section 2...4/5/6 indicate differential behavior. 03:20:22 ...that's a fundamental difference in the two flows. 03:20:55 ...m4nu has different type of behavior based on instrument type built-in 03:21:01 ...that seems to be a fundamental difference 03:21:31 m4nu: This proposal attempts to support push, pull, and approaches that are in-browser (e.g., built-in bitcoin) 03:21:38 ...so this algorithm tries to take that into account. 03:21:51 ..the detail in there addresses some of the questions that have been raised. 03:22:04 MattS: We need to address this fundamental difference. 03:22:29 ack 03:22:33 ack zkoch 03:22:33 zkoch, you wanted to consider if we want to tie ourselves to a dependency like JSON-LD 03:22:36 Zach: The one limit of polyfills is that they limit us in what we can bring in. 03:22:51 ...browser has access to some things like secure elements that other software may not have...polyfills may limit us 03:23:05 ...second point - when we think about deployment -- dependencies add weight. 03:23:24 ...JSON-LD dependency for example. 03:23:36 ...I would vote that we take Manu's good ideas and put them in my proposal ;) 03:24:07 m4nu: We do want rapid deployment....we don't want to leave browsers out in the cold... polyfills allow older browser support 03:24:30 m4nu: I don't think we should propose sem web processing flow blown; I propose that we should provide hooks for extensibility 03:24:36 q? 03:24:37 ack shepazu 03:24:38 shepazu, you wanted to ask about transforming message serializations (JSON, XML) 03:25:19 shepazu: Should we factor out serialization (and, e.g., be able to provide an XML serialization)? 03:25:23 q+ 03:26:24 ack mountie 03:26:29 ack mountie 03:26:47 Mountie: Character encodings are important wrt signatures 03:27:10 M4nu: JSON-LD is Unicode-based 03:27:19 q? 03:27:34 ack ShaneM 03:27:34 ShaneM, you wanted to suggest that the request could ask for additional information for each scheme in a merchant request 03:28:24 ShaneM: As the merchant is offering up information about instruments they accept (e.g., variable pricing) it might be additionally interesting to embed other additional information (e.g., merchant is willing to sell it for you at this price if you give them your home address) 03:28:35 ...so there might be additional CONDITIONS beyond simply instrument 03:28:41 m4nu: that may be a pre-step 03:29:08 rrsagent, make minutes 03:29:08 I have made the request to generate http://www.w3.org/2015/10/28-wpwg-minutes.html Ian 03:55:31 rbarnes has joined #wpwg 04:03:34 kazue has joined #wpwg 04:07:38 ShaneM has joined #wpwg 04:15:24 LJWatson has joined #wpwg 04:18:24 rbarnes has joined #wpwg 04:19:24 mountie has joined #wpwg 04:22:52 padler has joined #wpwg 04:23:23 nick has joined #wpwg 04:24:42 sangjo has joined #wpwg 04:27:39 Rouslan has joined #wpwg 04:31:22 sangjo has left #wpwg 04:32:40 lbolstad has joined #wpwg 04:33:45 m4nu has joined #wpwg 04:33:47 Jiangtao has joined #wpwg 04:34:14 zkoch has joined #wpwg 04:34:41 q? 04:36:29 wonsuk has joined #wpwg 04:36:39 MattPisut has joined #wpwg 04:36:57 padler has joined #wpwg 04:37:07 topic: How to write an API 04:37:14 joe has joined #wpwg 04:37:21 (Various guests from the TAG - Alex Russell, Travis Leithead, Mark Nottingham) 04:37:34 https://w3ctag.github.io/design-principles/ 04:37:45 alex: The TAG's responsibility is the overall coherence of the Web as a platform 04:37:50 ....we collaborate with different WGs. 04:37:51 kazue has joined #wpwg 04:37:58 ...the earlier we work with you in your design, the better 04:38:09 (Dan Appelquist arrives as well) 04:38:26 DanA: We're the TAG we're here to help 04:38:47 jmr has joined #wpwg 04:38:55 ...we've worked with various groups also on joint deliverables 04:39:01 dezell has joined #wpwg 04:39:17 ...we have expertise in network protocols, javascript, security, etc. 04:39:39 ...our offer is "come talk to us" we want to understand the problems you are trying to solve; and tie together APIs with rest of web platform. 04:39:48 ...I was happy to see use of promises in early proposals. 04:40:00 ...that's an example of where our work attempted to unify otherwise un coordinated bits 04:40:11 joe has left #wpwg 04:40:13 ...use of WebIDL 04:40:30 sangjo has joined #wpwg 04:40:35 twhalen has joined #wpwg 04:40:57 (Some discussion about the way things were re: events and callbacks) 04:41:05 ...we have a guide now on how to use promises 04:41:12 ...by domenic denicola 04:41:28 ...I want to say that if you have questions; that's our job 04:41:52 -> https://w3ctag.github.io/design-principles/ API Design Principles 04:42:24 Alex: Another topic is origin model. 04:42:40 ...how various actors in the system interact and where information can/cannot be passed 04:42:45 q+ to ask about high-level concerns around data security, extensibility, data linkability, credentials, decentralized identifiers. 04:42:49 shepazu has joined #wpwg 04:42:50 zakim, open the queue 04:42:50 ok, Ian, the speaker queue is open 04:42:54 q+ to ask about high-level concerns around data security, extensibility, data linkability, credentials, decentralized identifiers. 04:43:27 Alex: We've also seen high-level APIs....there are so many existing systems where it may be inevitable to have a high-level API 04:43:34 q+ to ask about message format, and security of polyfill 04:43:45 ...high level solutions may not serve people 04:43:46 q+ to ask about the interaction model on different platforms 04:44:01 ...it's important to have the conversations early about extensibility 04:44:02 q+ to ask about pre-requisites for good new APIs 04:44:18 sam has joined #wpwg 04:44:26 ...we worry about the tension between the audio element, for example and "Web Audio" 04:44:37 q+ 04:44:38 jyrossi has joined #wpwg 04:44:41 q+ 04:44:41 ack manu 04:44:48 ack m4nu 04:44:48 m4nu, you wanted to ask about high-level concerns around data security, extensibility, data linkability, credentials, decentralized identifiers. 04:45:31 m4nu: There are a number of high-level concerns around data security. I think there's a unified response to security on the web today which is "use JOSE" 04:45:36 lbolstad has joined #wpwg 04:45:48 Alex: there are many people who think that's a good thing to do, but some people who think it's too complicated 04:46:04 Manu: We are potentially going to hit that problem head-on... 04:46:21 ...there are many different types of extensibility, e.g., linked data, data extensibility 04:46:49 ...I don't know if the TAG has any recommendation about how to look at data extensibility 04:47:10 ...when is it ok to have linkability in the platform? 04:47:24 Alex: Our general discussion tends to revolve around "who the origin is" 04:47:29 ...the web platform really has one security model 04:47:36 ...this causes real chafing 04:47:48 ..it's got weird grandfathered in behaviors 04:48:05 ...the more than you can think about "who as an origin did that map back to?" 04:48:32 ...reducing the questions to origins lets you treat it as an API question and let the browser handle the social aspect 04:48:45 yaso has joined #wpwg 04:48:55 ...promises, because they are asynchronous, you can ask the system or the user to make a choice about whether information can be shared 04:49:09 ...e.g., requests for geolocation...those being async are important..... 04:49:27 ...the architectural principle is "Where you are not sure what should happen, keep things asynchronous." 04:49:55 m4nu: There are multiple groups searching for identity/credentials solutions....whether it's possible to authenticate people cross-domain. 04:50:01 ...any input from the TAG on that question would be welcome. 04:50:30 ...the TAG has an ability to say "this area is a problem and W3C should be spending more time talking about it" more visibly at the consortium. 04:50:47 ...there are three groups currently struggling with it...would be nice for the TAG to discuss this. 04:50:55 q? 04:51:10 Alex: Yes, where there are multiple groups discussing something, consistency would be a good thing 04:51:20 ...one thing we are emphasizing is that it's ok to make local progress. 04:51:22 sam_ has joined #wpwg 04:51:27 ...don't block on boiling the ocean. 04:51:31 ...boil just enough to make tea if you want tea 04:51:34 q? 04:51:49 ack shepazu 04:51:49 shepazu, you wanted to ask about message format, and security of polyfill 04:53:02 shepazu: This morning there were 2 proposals. When I looked at them two diffs that stood out for me were (1) zach did not have a message format proposal [Zach: that is to be fleshed out] 04:54:00 Alex: Inside w3c we are not relitigating transport. but there are areas for collaboration, such as out-of-band push notifications 04:54:09 ...or working with TC39 on improving WebIDL 04:54:21 ...please specify enough to solve the problem. 04:54:29 shepazu: What about polyfills? 04:54:39 mnot has joined #wpwg 04:54:43 q? 04:54:49 ...are there security concerns about delegating to a polyfill? 04:54:56 Alex: There are up sides and risks to polyfills. 04:54:56 q+ 04:55:16 ...upside is obviously earlier visibility....but the downside is that polyfills can end up with lives of their own 04:55:34 ...a polypill that is widely used has risks. 04:55:55 ..e.g., early shadow dom polyfills led people to think they were slow, but implemented natively are much faster than other approaches 04:56:13 ack AdrianHB 04:56:13 AdrianHB, you wanted to ask about the interaction model on different platforms 04:56:14 ...just beware of downsides of polyfills 04:56:28 AdrianHB: I want to throw more specific questions on the table. 04:56:47 ..one of the questions that has been thrown around without a clear answer 04:57:01 ...we have a narrow scope of what we want to standardize (which does not mean narrow in what we want to consider) 04:57:14 ...the standard is for the flow between web site and payment instrument 04:57:30 ...how that manifests itself on different platforms will be different (e.g., on mobile may be native app) 04:57:42 ...so, e.g., user selection of payment instrument is selection of an app 04:57:51 ..but we don't have an elegant way to replicate that in a desktop world. 04:58:00 ...how would we achieve the same kind of idea on desktop? 04:58:22 ...as a merchant web site I've provided information about ways I can be paid. 04:58:44 ...let's say for this example the user agent assesses the list, compares to the list of payment instruments that have been registered, and provides the user with a set of choices. 04:59:07 ..the user picks one, there's execution of some logic by the payment instrument (potentially in its own execution environment) and then returns (via a promise) a response. 04:59:13 ..in mobile that pattern is quite familiar. 04:59:42 ....one proposal for the desktop is the browser gives you a selection UI (thus, rendered by the browser) 05:00:01 ...now the payment instrument wants to render some UI...is it sufficient to do so in a frame? 05:00:18 Alex: I hear a couple of questions: (1) how much needs to be in the spec (2) if so, how much needs to be specific 05:00:36 sam has joined #wpwg 05:00:37 AdrianHB: The definition of the payment instrument needs to have enough data for whatever the instrument execution environment needs 05:00:48 ...so we need enough information (even if as simple as a URL) 05:00:56 Alex: In the webplatfomr we are always mapping things back to URLs 05:01:07 (Ahh, mention of HTTPRange-14) 05:01:16 Ryladog has joined #wpwg 05:01:27 Alex: You can map pieces of the transaction back to URLs and origins...that makes it easier to talk about "who is doing what with whom and with what data" 05:01:28 q? 05:01:34 ...there's a related question about how to do the selection dance 05:01:47 ...there are various approaches like protocol handlers, custom url schemes, etc. 05:01:54 ...redirecting through the OS to get something 05:02:03 ...mobile systems have intent handlers 05:02:15 ..those are questions that are a bit out of view from the web platform. 05:02:22 ...there have been ideas proposed like web intents 05:02:39 ...there is an itch to re-explore that, but my advice today is to not try to solve that problem. 05:02:59 ....provide enough information to bootstrap ... but also chart a path forward 05:03:30 ...you might uncover latent issues this way ...the exercise is valuable...but I wouldn't get too hung up about harmonized UI across systems 05:03:52 AdrianHB: Part of the motivation for the question is that we are looking at things from the perspective of the merchant creating things for their sites and calling this API 05:04:08 ...but we are also thinking about how the payment instrument provider gets their instruments to different platforms 05:04:20 ...maybe we don't have to SOLVE it but I think we should think about it since it will be part of flow. 05:04:24 ack nicktr 05:04:24 nicktr, you wanted to ask about pre-requisites for good new APIs 05:04:27 Alex: I would guess your implementers help address it. 05:04:32 AdrianHB has joined #wpwg 05:04:54 q+ to ask about REST APIs 05:05:03 nicktr: Given that we are just starting off, are there pre-requisites or patterns based on successful ones 05:05:07 MarkN: Implementations 05:05:09 Alex: Iteration 05:05:12 MarkN: +1 to iteration 05:05:21 Alex: You can't design something without implementation. 05:05:27 Alex: So just get started. 05:05:56 Travis: You also need people to do the work 05:06:01 MarkN: Don't boil the ocean 05:06:14 ...don't try to accommodate things you don't know. 05:06:26 q? 05:06:53 MarkN: Shipping a spec is not a guarantee of success 05:06:56 ack zkoch 05:07:32 zach: In our proposal, we took a hacky approach with a promise...we wanted to open a comms channel between browser and merchant, so that when an action takes place we want to emit an event with info that allows the merchant can respond. 05:08:10 ...our approach is to have a first promise that returns an event target, that becomes the event target. 05:08:17 ...a second promise is the instrument response promise. 05:08:30 ...that should work BUT you could imagine a world where events and promises work together. 05:08:33 ...any thoughts on this? 05:09:13 Travis: I had a brief look at the API. I think you are modeling the right principles on the right syntaxes. Unless you have a strong motivation I think there's probably not a reason to merge concepts. 05:09:41 Zach: There are some edge cases where having two promises is overkill...so the solution seems a bit ugly. 05:09:44 q? 05:09:56 Travis: We'll stew about this and see if we can come back with something that's a bit better. 05:10:03 (Some design on the fly) 05:10:08 Alex: Promise is a one-shot response. 05:10:22 ...we see this tension all over the place..e.vents have no historical data.... 05:10:46 Travis: You want to return data back to the platform. 05:11:00 ...you are generally responding to a platform event...but here you are also sending data back. 05:11:20 Alex: In service works we have "extendable events"...they extend the life of an operation...they also respond to it. 05:11:39 ...that's a way of saying "I'm going to give you a value that is either a value or a promise." 05:11:57 Zach: If there's a cleaner implementation let me know. 05:12:08 ...also AdrianB mentioned other groups that may be looking at that. 05:12:16 ack kris 05:12:40 https://w3ctag.github.io/design-principles/ 05:13:06 Travis: Myself and Domenic are collective authors 05:13:18 Kris: With my ISO hat one we are trying to figure out how ISO messages would fit into an API environment. 05:13:23 ...I'd like to speak with you separately about it. 05:13:25 ack mnot 05:13:38 MarkN: Manu asked about extensibility and I wanted to add to that. 05:13:59 ...extensibility has a critical role in what we do (e.g., future unintended uses)...but extensibility can be harmful especially in protocol design 05:14:06 ...it can be quite counter-productive. 05:14:13 ...there are painful memories of Web Services 05:14:36 MarkN: Extensibility can give some players in market extra power 05:14:40 ...e.g., "must understand" flags 05:14:49 ...OAUTH2 is also a cautionary tale 05:15:04 ...you can't use OAUTH2 unless knowing which flavor. 05:15:25 ...so be wary of supporting lots of use cases, but then supporting none without some out-of-band shared understanding 05:15:25 ack m4nu 05:15:27 m4nu, you wanted to ask about REST APIs 05:15:54 m4nu: We plan to have a browser API but also may need a RESTful API for machine-to-machine communication.... 05:16:02 ....e.g., car needs to pay automatically at the gas pump 05:16:10 ...to my knowledge W3C has not standardized a REST API.... 05:16:15 shepazu: LDP 05:16:33 m4nu: Does TAG have thoughts on RESTful API design? 05:16:44 Mountie: What about CSP? 05:17:12 MarkN: REST is not well-understood. I would encourage you rather to decide whether you want to use HTTP and just to use it wel 05:17:26 MarkN: I'm happy to help with that as well 05:18:06 ...there's a list at the IETF coming soon for help on using HTTP with APIs 05:18:20 q? 05:18:37 m4nu: Is there anything analogous to IDL for HTTP design for APIs? 05:18:50 MarkN: No 05:19:09 q? 05:19:09 Alex: We don't in the TAG do a lot of it so other communities may be more well-suited 05:19:42 padler: Payments touches a lot of things...a number of the flows we can imagine like for IOT will become increasingly important. 05:19:51 ...we could in the payments IG use the TAG's help 05:20:07 q+ 05:20:11 ...looking at things like identity and credentials, signing messages, confirming people are who they claim to be, ecommerce, etc. 05:20:45 Alex; I have the feeling that when it's easy to pay for things in the browser, people will notice 05:21:18 ...feel free to ask us for review of whatever you have at whatever stage 05:21:22 q+ to ask about declarative requests 05:21:23 q+ to ask wha the process is for that review? 05:21:29 zakim, close the queue 05:21:29 ok, Ian, the speaker queue is closed 05:21:29 rrsagent, make minutes 05:21:29 I have made the request to generate http://www.w3.org/2015/10/28-wpwg-minutes.html adrianba 05:22:10 ack kris 05:22:31 Kris: regarding RESTful design...you (MarkN) sounded mysterious.... 05:22:37 ....what's a classic misunderstanding? 05:22:58 MarkN: In the context of designing an API, "REST" is meaningless. REST is a style. It happens to be modeled on HTTP but it is not HTTP 05:23:16 ...the problem is that many people have different ideas of what it means...so not useful to communicate with that word. 05:23:23 ack AdrianHB 05:23:25 AdrianHB, you wanted to ask about declarative requests 05:23:34 AdrianHB: The question came up earlier about whether we should be considering declarative ways of doing things. 05:23:42 ...e.g., what would be a good way to do something declaratively? 05:24:06 Alex: Normal declarative style we see in HTML and CSS...that gets you to a point where you hang information off the DOM 05:24:17 ..that has upsides in that you can easily provide UI for something in the DOM 05:24:40 ...but it's difficult to both build an API that hangs together as well as the HTML bits...it leaves a lot to come back and do. 05:25:05 The blog entry about extensibility I mentioned: https://www.mnot.net/blog/2006/04/07/extensibility 05:25:08 Alex: Declarative is great because you don't have to specify much. You can increase what is specified over time. The