<Ian> AdamC: JRL contacted Shell a year ago or so about bringing payments into the vehicle
<Ian> ...took our incontrol apps platform (our brought-in device and infotainment systems, analogous to CarPlay or AndroidAuto)
<Ian> ...screen does some implementation mirroring
<Ian> ...plug in the phone...various apps available for navigation, music, bluetooth beacons for tracking objects
<Ian> ...signal from vehicle indicating low fuel combined with geolocation information about nearest shell station
<Ian> ...you select (manually) the pump number
<Ian> ...within the app on the screen
<Ian> ...you will have already synced up your payment mechanism (apple pay, google pay, PayPal)
<Ian> ...you can pay up to a certain amount
<Ian> ...you approve use of the credentials, get out and pump gas, and receive a receipt by email
<Ian> ...also linked to loyalty program
<Ian> AdamC: Shell app does a lot of the heavy lifting. What we would love to do is put the app that's running on the phone on the embedded platfrom.
<Ian> ...so user does not have to have a connect phone
<Ian> ...the web payments API will help for the HTML5 apps
<Ian> ...here is where I would hand over the presentation to John Carrier (next time!)
<Ian> ...obviously geo location in use, but not granular enough for pump number.
<Ian> rod: Is this live?
<Ian> AdamC: Yes
<Ian> ...it's live in the UK; many of the shell garages support mobile payments
<Ian> Rod: How is this enabled? Through the gas station controller?
<Ian> AdamC: John Carrier (ISFS) developed the standards for how the shell app works.
<Ian> ...the logic mostly runs on the handset
<Ian> ..it doesn't go through the JLR back end...our embedded apps do...but the brought in apps only communicate with the handset and a few signals from the vehicle
<Ian> Rod: And the experience today is available through in control / ApplePay
<Ian> AdamC: That works on 3 of our entertainment platforms
<Ian> ...original in control, in control touch, and in control touch pro
<Ian> Karen: GDPR
<Ian> ...how will GDPR affect solutions such as this?
https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
<Ian> AdamC: Only affected as much as any application on a user phone would be affected.
<Ian> ...the use of hardware based security suggests they will be ok
<Ian> ...where we are responsible for user data we are being very careful
IJ: You mentioned the credentials
are stored
... a key piece of payment request API is collection of
credentials
... does this happen in app, embedded app, some other
time
... or use of Apple Pay, outside of the platform
Adam: It's ApplePay and
AndroidPay
... I know ApplePay takes responsibility for it
IJ: How do you see benefits of
the use of HTML in this case?
... what is it that is driving you in that direction?
<Ian> AdamC: Over the air updates
Adam: Key thing is we can update
HTML apps OTT without a systems image
... onboard any payment service; parking, fueling, drive
through McDonalds
... we can update HTML5 app over the air
... use existing infrastructure
... and harness that, possibly through web payments API, poss
other things
... Looking at whether we create a JLR wallet
... or merchant aggregation platform and harness that
... and deal with tokenization issues
... very early days for embedded
IJ: say out lout
<Ian> Payment Handler API
s/outloud
scribe: important if browser is
not going to be storing credential directly
... and you are doing web way, use payment handler API
... mention in case you have not looked at it yet
... that's how the browser talks to the payment apps
... user control, get backs data through payment request
API
... Chrome recently announced intent to ship payment handler in
Blink
... which is good
... you could build whole system using various payment
apps
... using AliPay, Samsung Pay, Square
... side effects would be easier to plug into different payment
apps the user might have
... whether running in the car or on the phone
... plan to pay on phone if rest of app is running on the
car?
Adam: It's an option we want to
investigate
... if we let the phone do the heavy lifting
... we don't have to embed details in the vehicle
... my understanding of payment handler API
<Ian> https://w3c.github.io/payment-handler/
Adam: Chrome would be running on
the mobile handset
... so grab payments on the handset
IJ: so there are two worlds of
payment apps
... three actually
... browser itself storing credentials; then native mobile apps
and how they talk to browser, which is up to the operating
system
... Google Pay, native app, talks to app running on head unit
through Android proprietary protocol
... but if they are paying through web site
... like chase.com, then they would pay through the payment
handler API
Adam: ok
IJ: We have not discussed what if I am paying with my browser on my phone visiting chase.com but tokens running in browser on my car; above my pay grade
Adam: whether we could
harness
... the kind of JLR app running on the hand set to authenticate
with specific vehicle wirelessly
... sounding a bit messy for user experience
... and multi-faceted in the architecture
IJ: I have not thought through
it
... wondering about carrying your credentials around through
any car; not specific apps running in car
... use preferred payment method
... perhaps pay with issuing bank that tokenizes
... how it works in practice; over Bluetooth, NFC, no
idea
... may not be what users have
... drive same car; not sure of the 80/20 point
Rod: I think following your
thought
... question to Adam
... I think the browser experience is there would be a wallet
of choice
... every provider gives their experience
... with payment handler capability
... removes friction to download applications
... I believe this increases potential for adoption
... I believe the architecture I'm seeing would allow it
... If JLR did not integrate solution for the web server
... more with Shell facilitating and receiving payment
... security is not managed by application
... it's supported regardless of whether it's supporting
payment handler or fcs
... with our knowledge, if pursuing web standard is
overkill?
IJ: I meant to say decoupling the payment app onto a mobile device is overkill
Adam: we are still investigating
what would be appropriate and how to decouple senstive
credentials on the vehicle
... if we can store offboard
... and request using auth we already have to our own
service
... that would be beneficial; we don't want to store sensitive
data on the vehicle itself
... the standard web payments API and payment handler API
... could be a window from a web app
... to an underlying layer that we don't understand yet
... and then if we have multple applications using these
payments APIs that's great, but layer that's missing is a bit
outside of the web API's scope
IJ: Yes, anything transport is outside of our scope
Adam: I guess we need the bigger
picture to understand end-to-end and whether this is the right
thing to do or not
... and whether it is some kind of server based API that
becomes a standard
... and maybe that would be appropriate
... but it requires more thought
IJ: right
-q
IJ: Adam, any other topics you wanted to cover today?
Adam: I think that's it
... original plan was to go deeper on plan with John, but we
can cover that on a future call
IJ: It's interesting to see the
user experience
... it is what I had begun to think we could do
... with the possible improvement that
... if you were advertised the URL to a server, you might get
pump in there, too, and not have to select the pump
... although there are security issues there
... an advertised URL might include the pump number
... screen that pops up is a web page from a server that asks
if you would like to pay at this pump using this card and you
say yes, pump, and get receipt
... so the hard questions were how do you get that URL?
... this assumes you have Internet connectivity and can talk
through a web page
... and assumes remote activation of the pump
... someone suggested to me that is not how systems work in the
real world in the United States
... no remote activation from an offsite server
Adam: I'm not entirely sure
if
... how that currently works in the Shell system
... I don't know if the
... payment attendant has to actively say I've received
pre-authorization and then press ok or not
IJ: even that ok
... if I get a URL
... that is trustworthy from the pump
... IDs me, takes me and page to Shell.com; Shell.com server is
running
... can they send a signal to some small station on the side of
the road in Steynes
... at which point the attendant pushes the button
... these things on the back end are mysteries to me
... So, how active is the HTML5 development going?
Adam: Completely
... we've got a number of active apps at the moment
... we have the concept of connected accounts
... we integrate to @
... in touch probe builds
... user connects there
... and can use web app for playback of Visa connected
account
... very much active with HTML5 in the vehicle
IJ: What would it take to do some
prototyping?
... any browser running?
... what engine?
Adam: It's a browser, webkit
based at the moment
... we are discussing the tech now
IJ: WebKit supports payment
request API
... in technology preview
... WebKit is developing payment request APIs, but not yet
developing payment handler support
... I want to move beyond FF and Chrome to Edge and
WebKit
... I don't know
... since WebKit is open source, presumably you could add
connectivity where there isn't but don't know if you would get
for free
... would have to talk to Apple about getting payment handler
API support
Adam: I guess the browser engine
can be changed, but not OTT dynamically
... in future if we think a different browser engine gets us
the support, that is not a problem
IJ: I recently asked our Apple
colleagues
... some browsers would natively support and store card and
shipping info in the browser
... but Safari does not; only support third party payment
app
... on Chrome you can plus into other 3rd party payment
apps
... that is state of play right now
Adam: yes
IJ: thank you
... I would be interested
... in hearing how people might play with payment request API
in different scenarios
... we could find partners like MasterCard, Chrome team for
experiementation
... if that is of interest let me know
Adam: definitely
... some standards are being developed by EMV
... on network technolization
... only periferrally aware of
IJ: EMV is working fairly closely
with W3C on some public topics
... EMV and W3C have different confidentiality levels
... we are working on 3D Secure and workflows
... bring network tokens to web through payment handler API
<Ian> https://w3c.github.io/webpayments-methods-tokenization/index.html
IJ: we have this document in
development
... called tokenized card payment
... to allow merchant to say, I'd like a network token; here is
an encrypted key
... for the response
... Visa and MC want the data to be encrypted
... imagine encryption but some display data
... we are working with EMV to figure out what the data model
should be
... does key come from a certificate that is validated
... second one, 3D Secure Authentication flows
... figuring out what role 3D secure plays, etc.
Adam: Good to know EMV is involved with W3C as well
IJ: yes, it's getting
better
... we are eager to improve payment security and they are eager
to get their stuff out
... Anybody else?
<Ian> Karen: Are your slides public?
<Ian> AdamC: Yes
<Ian> ...I will get review of the deck and share it.
<Ian> Proposed 15 March