<ted> scribenick: ted
Previous: https://www.w3.org/2018/03/15-autopay-minutes
Ian: John gave us a great presentation last time and will link the slide deck
Ian: where left off was at the
user experience and security to be followed with "how the web
will be used for this?"
... a gap analysis on existing solutions and motivations for
using the web
John: that was the essence of the
conversation Rodrigo and I had in person in UK on his visit
recently
... to figure out how web payments works in this flow
... all the messages going for authorization and communicate
back to the site to enable the pump and send receipts
... what doesn't exist and where W3C would be most helpful is
on the front end, eliminating the proprietary apps
... the user experience is poor here
... how do we give an everyday user an option where he doesn't
need to install a specific app
... when I was a Shell employee we wanted everyone to use a
Shell app
... phone fills with them. I recently tried the BP one to see
what it is like and it is essentially the same (with a
different logo)
... need to fit in with P97
Dave: I have two points. Some of
the apps aren't bad but the consistency is deplorable
... I do agree with you about this leg, mobile device talking
to the cloud being standardized. it is an important piece
... phone will send a token back to the pipes to the payment
provider but how do we communicate back to the station? the
inside authorization
John: that means you use the
existing payment rails on site. the PCI certification was
something you didn't have to touch unless you had to
... we would only do that for a new pin pad on site, not for
passing a token through
... not an option for most EU companies since they don't want
to invalidate PCI certs
Dave: we haven't run into a PCI problem, we do have to do PD@@
<Zakim> ted, you wanted to comment on consistency
<Ian> scribenick: Ian
Ted: The consistency part stands
out for me in how the user experience would be when going
through the screen on the head unit
... we've been hearing from some OEMs that they would want to
control a portal in order to enforce consistency
... across service stations
... I think that consistency of experience is important
<ted> John: I agree, it is all about consistency
<ted> … the marketing of the apps is they all want to be unique and distinguish themselves
<ted> [imprint and establish brand loyalty]
<ted> John: you may offer customer loyalty promotions
<ted> Ian: why would that not work with a web solution?
<ted> John: it could
<ted> … it is something the see as a differentiator
<ted> … if you knew you were at the Shell service station, your payment app would know your customer/loyalty identifier
<ted> Ian: integrating loyalty, ease of use, control of experience, branding are all independent of solution
<ted> … question to me is why would the OEMs or people building apps on head unit want to use web technology?
<ted> … I am hearing about it being widely deployed, established medium
<ted> … are there things in the flow on slide 10 and wondering if there is anything there that couldn't be done in a web page?
<ted> John & Rod: I don't think so
<ted> Rod: low cost is a factor. UX defined by the browser and leveraging industries of scale are also good cases to make
<ted> Ian: in order to do this thing you need NFC, Geolocation, Wifi, notification API, core web for display/UX
<ted> … we need to identify what applies to each and what doesn't work across devices
<ted> … being able to send how much gas a vehicle's current capacity could take would be useful to communicate
INTERESTING: Capability matching between site and vehicle
<ted> John: autonomous vehicle use cases complicate things. there will be a need for the vehicle and service station to communicate about what service is needed, it could require air in tires not gas
INTERESTING: e.g., air, fuel, car wash, etc.
<ted> … these are derivatives
<ted> … 95% of the time it is a straight forward transaction
<ted> Ian: that is an interesting intents matching
<ted> … I am not sure the current state of Web Intents at W3C (will need to check)
<ted> … that is a slightly bigger project and not a prerequisite for the simpler use cases
<ted> … it could be undertaken in the Web of Things group (ping DSR)
<ted> John: vehicle might make some decisions like avoiding a particular bridge to save money since the detour is not that far out of the way
<ted> … Adam's JLR example takes assumptions of what has to be known at present, subset compared to future use cases
<ted> …
<ted> scribenick: ted
INTERESTING: an abstract thinking
exercise could include passenger capacity and routing for
shared use scenarios
... quite a bit of intelligence would be needed in these
systems
Ian: any news Rodrigo on prototyping?
Rod: specifically testing on web
interface and communicating with OEMs
... the simple case we implemented was successful
... it is still geography based use case. there needs to be a
person to acquire receipt
... used tokens, device data and an external back channel for
parts not web payments. it would be nice to have additions to
web payments request that are automotive specific
[I wonder if there could be a mapping with existing payment request parameters for automotive]
Ian: we think we have pieces in
place and still questions on how you identify the station
you're at
... in John's example identifying the pump is manual, next is
which merchant site
... pump needs to be turned on
... whether that is based on POI, BT, NFC...
Rod: we explore geolocation and
@@a
... today if you let for example know you are at a given
restaurant you were stationary at for some time and prompt you
for writing a review
... based on location you can determine they are at a gas
station, ask to confirm they are at pump #6 and go from
there
Ian: if we go from manual pump selection to automated, that would be a good piece to solve
David: there are things like
geolocation and lower tech options like scanning a QR
code
... vendors are doing things in different ways and require a
device interface in browser
... to read QR code or BT beacon
... BTLE, NFC - information about where you are
... any of those would need to be part of the information and
coordinated with geolocation. payment solution would need
access
Ian: earlier it seemed we could
use the Genivi Development Platform to start
experimenting
... we have seen user paths and whether we have enough to solve
with web tech and now we have to demonstrate it
John: we did start off with a QR
code, metal sheet attached to pump
... unique to each pump, placed precisely and visibly
... in practice we found people didn't want to use them,
pointing camera on phone
... feedback we continually got was to provide the pump number
instead
... the QR code would get defaced, rarely would get too much
sun on them in the UK causing reflection and therefore
unreadable
... the key to this is device integration. at the moment we are
talking pump numbers but it could be a tire pressure gauge,
bridge toll...
... we wanted the system to be able to pay for ferries in
Denmark
... part of the overall fleet management you want to look at
tolls, congestion fees, etc
... we keep for now to the simple (primary) use case
fueling
... today we just have to identify the pump number, next we
will need identifier for other use cases
... how you get that device a unique identification - user
entry, QR, NFC etc it doesn't matter
Ian: from a functional
perspective I agree
... for all those solutions we have work at W3C either done or
in progress
... there might be other coming along like BTLE
... we would need all those APIs. for payments I am not focused
on that piece of the puzzle
... a web interface to indicate I want to fill up at pump 6 and
get a car wash
... my question is can we setup a demo on automotive stack (eg
in a vm on a laptop)?
[yes, will take work]
John: we can't make a petro station appear in an office in a conference center and it wreaks demo
[fake the location ;-)]
John: we were able to get a
solution on android
... there was no available way on an iphone to dupe the
device
<Ian> scribenick: Ted
<Ian> ted: GPS spoofing is a concern
<Ian> ted: I think we can do mapping with PR API for auto-specific data
<Ian> ...it is feasible to create a demo on a laptop
<Ian> ...would take some wokr
<Ian> ..wonder if Rod could share some more info
<Ian> ...I will work to engage people at Genivi in a couple of weeks
<scribe> scribenick: ted
Rod: I will check if any of the
partners we are working with will share our prototype
... we all want a demo to kick around and show something
concrete
Ian: yeah!
... I want to look at the next meeting, scheduled for 12
April
<Ian> Ian: Currently proposed for 12 April
<Ian> Ted: Still working out dates with John Strutton
<Ian> IJ: What could we have done by 26 April?
<Ian> Ted: I could give an update from various conversations
<Ian> ...including reporting back on engagement from Genivi
<Ian> Karen: Can we back up a minute to Rod and John and David
<Ian> ...it would be helpful for me to hear the categories of ecosystem players for something like this to work
<Ian> JohnC: Good question
<Ian> JohnC: A huge number of actors are involved in a single end-to-end solution
<Ian> ..phone providers
<Ian> ...mobile payyment platform
<Ian> ...oil company
<Ian> ...authorization system / issuing systemn
<Ian> ...loyalty systems
<Ian> ..just to do pay-at-the pump there were probably 15 orgs involved
<Ian> ...e.g., "where are the pump locations"
<Ian> ...integration with offers (to know that you can use points for a wash)
<Ian> ...device management, customer management, etc.