12:54:24 RRSAgent has joined #autopay 12:54:24 logging to http://www.w3.org/2017/10/19-autopay-irc 12:55:23 Meeting: Automotive Web Payments Task Force 12:55:24 Chair: Ian 12:55:34 Agenda: https://github.com/w3c/automotive-pay/wiki/Agenda-20171019 13:00:17 present+ 13:00:20 present+ Ted 13:00:22 present+ Matt 13:01:03 present+ JohnStrutton 13:01:08 present+ AdamCrofts 13:01:21 regrets+ Rodrigo 13:01:26 Matt has joined #Autopay 13:02:10 AdamC has joined #autopay 13:02:32 john_s has joined #autopay 13:02:33 https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer 13:02:45 scribenick: ted 13:03:07 Ian: we are still in the process of building agenda for our F2F meeting at TPAC 13:03:09 ---> https://github.com/w3c/automotive-pay/wiki/Agenda-20171019 Agenda 13:03:22 -> https://www.w3.org/2017/11/TPAC/ TPAC 13:03:34 https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer 13:04:07 Ian: last call we asked people to flush out use cases they were interested in 13:04:19 … I took a pass at an explainer for pay at the pump 13:04:58 … ultimately I felt somewhat comfortable saying there are limitations in payment method implementations and fraud prevention that digital/web payments may help overcome 13:05:32 … taking a look from cost reduction, convenience and improve security 13:05:57 q+ to talk about First Data 13:06:00 Adam: we have previously built an application with Shell 13:06:19 … some information about the user is stored in the vehicle regarding their account 13:06:49 … various systems like OCR for plates aren't integrated at this point for unlocking the pump 13:08:05 Ian: I have seen a prototype of an integrated solution from FirstData at a conference 13:08:28 … I was told the regulatory requirements are complex 13:09:40 … unsure if that applies when it is the phone versus the car 13:09:45 Whilst petrol stations have ANPR (not OCR), they are not directly linked to the users and their accounts, they are purely for security. 13:10:21 Matt: you should not engage in your phone in any way while vehicle is in motion. it could interact with the vehicle and internet in the background 13:10:33 It was also john_s, rather than myself 13:11:02 IJ: I Wanted to separate "safety" from "how data flows" 13:11:02 q? 13:11:04 ack me 13:11:04 Ian, you wanted to talk about First Data 13:11:48 Ian: after considering the problem statement, the opportunity is about streamlining, improving security etc 13:12:00 … we would have to treat poor or no connectivity differently 13:12:28 http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/automotive-pay/gh-pages/flows/geolocation.pml 13:12:56 … station owner (or chain) could have a site that phone or car could interact with it to complete payment 13:13:08 http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/automotive-pay/gh-pages/flows/ble.pml 13:13:42 … this UML shows the different paths for how the pertinent payment link is delivered. it can be done via NFC, BLE, GPS etc 13:13:46 q+ 13:14:07 … this raises some security issues 13:14:36 ack ted 13:16:36 Ian: FirstData limited the problem by having pre-existing relationships with stations elsewhere 13:17:33 s/ack ted/Ted: to avoid eg a bogus beacon, your vehicle could send GPS so payment provider can align before letting payment proceed/ 13:17:48 s/AdamC:/JohnS:/ 13:18:55 JohnS: there is a merchant certificate that is transferred to the device eg ApplePay at the outset 13:19:18 Ian: yes, our API aligns well with Apple with the exception of the merchant certificate part 13:20:03 … since on the web you may not have a previous relationship with the merchant. that can help and we have a proposal in the WG for addressing that 13:21:44 … there is business value in doing more on the web and not having heavy, constantly updating apps 13:22:06 Adam: we definitely want a standard payment process which can interact with any bespoke service provider we deal with 13:22:26 … having this genericized would definitely help 13:22:50 Ian: [typing on the wiki 13:22:58 https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer 13:23:12 … there might not need a prior relationship with the service station 13:23:41 JohnS: while that makes sense the OEM wants to retain control to its app market 13:24:00 … they may want to limit based on partnerships 13:24:03 q+ 13:25:00 Ian: even without partnerships you can monetize and direct to preferred stations without discarding others 13:25:13 … there are other ways to monetize 13:26:09 JohnS: we can implement the various steps in your UML up to 6 readily 13:26:27 … security issues are reduced when you have the previous merchant relationships 13:26:28 John: We can enhance security based on database of locations and relationships (can be monetized) 13:27:05 ack ted 13:27:15 John: We could start with subset of merchants, then allow them to onboard easily 13:27:21 Ted: John touched on part of what I wanted to say 13:27:50 ...OEMs will control the app marketplace and have the opportunity to establish partnerships 13:28:24 ...while you do want to leverage partnerships, you will also want to enable some additional relationships 13:30:06 (IJ adds to fraud mitigation section: "OEMs may have partnerships with some merchants, and can increase security through an onboarding process. In this case, OEMs will also want to account for situations where users wish to get fuel from merchants that are not yet OEM partners.") 13:30:18 scribenick: ted 13:30:30 JohnS: on the merchant side you want to standardize processing 13:30:43 … OEM may want to provide a bespoke experience 13:31:21 … what needs to be returned to the merchant as part of the payload before proceeding 13:31:39 … I am keen to think about what information is necessary for this and other use cases like parking 13:31:57 Ian: in the vision outlined in the explainer the user is interacting directly with eg Shell 13:32:24 … Shell can ask me to provide any necessary information through their web service including pump number 13:32:48 … we can also make strides in streamling beyond just the payment piece 13:33:36 JohnS: in that scenario you are working with the merchants page and data needed 13:33:54 q+ 13:35:06 JohnS: Might be interesting to bundle other data relevant to the transaction (e.g., pump number) with the payment payload 13:35:08 ack ted 13:35:29 Ted: This is HTML but is not necessarily a "page" that loads 13:35:47 ..people are mixing and matching various technologies in practice 13:35:57 ...I note payment request API is being implemented in webkit 13:36:32 Ian: I am looking for some validation that people are interesting in persuing this use case 13:36:41 +1 I think this is the highest profile use case 13:36:49 (perhaps the most complicated as well) 13:37:30 Ian: the starting off point is how to get the device (phone or car) the URL 13:38:10 … I hear it is a regulatory and liability problem 13:39:36 … everyone here is welcome to edit this wiki page and contributions are welcome 13:39:54 JohnS: how does the UX operate under 2FA? 13:40:15 Ian: in some sense the ecosystem consists of merchant with buy button on their website 13:40:46 … it returns credentials, shipping address etc. browsers are starting to ship with ability to integrate with payment apps 13:41:09 … some data may be stored in browser and relayed to merchant and defer to the app for the transaction 13:41:36 … there is discussion in the Web Payments WG around 3d secure without further user verification 13:42:10 … we expect the strong auth to come from underlying payment app and send tokens through encrypted pipe 13:42:47 https://w3c.github.io/webpayments-methods-tokenization/index.html 13:43:08 Matt: we recognize tokenization isn't universal yet but we're moving that way 13:43:41 Ted: We could work on more than one use case. 13:44:02 ...do people want to focus on this one or start to explore others like parking or tolls? 13:44:25 Adam: as a team here at JLR we are looking at the other use cases as well 13:44:46 John: I think it comes down to the payment types, fuel needs to be pre-authorized 13:45:13 … if we segment the workflow then common components will apply to other use cases such as parking 13:45:41 Ian: what we have done so far in web payments is streamline checkout 13:46:13 … there are a number of things in our queue such as recurring payments, preauth and those are on agenda for F2F 13:47:09 … cards on file get stale. through API it can know when you update your credit card and could as a convenience communicate that out to recurring service needs 13:47:32 present+ Evgeny 13:47:54 Ian: Tolls and parking are of interest 13:48:33 Topic: Toll roads 13:48:37 Adam: there are a couple interesting use cases for handling Tolls 13:48:48 … they vary widely across the world 13:49:11 … some use ANPR and give owner N days to make payment 13:49:36 … others can be handled with a toll and credit card 13:49:51 John: some have card on file and use RF and create charge automatically 13:51:02 Ted: here I keep 40US on my RF account, if there is an issue eg stale card I get flashing yellow at toll 13:51:11 Ian: what is broken today? 13:51:35 Ted: One thing that's broken is "wide variety" around the world 13:53:11 Ian: two main cases are prepaid/card on file or pay within N days 13:55:16 Ted: What user confirmation is required for transaction? 13:56:35 Ian: web payments doesn't require user confirmation but PCI in some cases prevents storing of CVV and considers entry as confirmation 13:56:58 … there could be logic in the payment app for a certain type of payment (toll) to proceed 13:57:12 … it is possible 13:57:36 (avoid distracting driver) 13:58:12 Adam: what about use case of paying tolls at the end of your journey? user can choose which payment method they wish for all the tolls incurred on the trip 13:58:28 Ian: I like and that is a good UX 13:59:06 +1 to a consistent user experience where the car helps me manage interactions with different merchants (e.g., pre-order food, buy fuel, pay tolls) 13:59:18 ..the car helps me manage my merchant needs. 13:59:37 John: what is the value on doing this from car instead of just from someone's phone? 14:00:05 Ian: from user perspective I can see both, from car point of view the partnerships 14:00:33 Adam: apps can be preinstalled. user might not want to download an app to complete a transaction 14:01:17 Ian: app on phone can know you have pending tolls and you can pay that while waiting in queue at movie theater... 14:02:45 [Discussion of "phone" v. "head unit"] 14:03:32 Ted: both and pairing and being able to get to pending and completed transactions from either has many advantages to the user 14:04:09 Ian: I encourage people to work on UML mockups and contribute to wiki 14:04:42 Ian: the BT folks have a proposal that came out this week 14:04:59 Topic: Next meeting 14:05:36 IJ: Let's hammer on this over the next week and see if we can refine it / raise issues 14:05:46 Next meeting - 26 October at 9am ET 14:06:55 I have made the request to generate http://www.w3.org/2017/10/19-autopay-minutes.html Ian 14:06:59 Ted encourages JLR to open up use cases they're working on 14:07:05 John: will do 14:07:06 I have made the request to generate http://www.w3.org/2017/10/19-autopay-minutes.html ted 14:07:08 RRSAGENT, set logs public 15:51:22 Zakim has left #autopay 16:01:16 RRSAGENT, bye 16:01:16 I see no action items