Automotive Web Payments

Ian: I would be interested in your 3DS perspective

Matt: we are heavily involved with Emvco and hoping it can live up to expectations

Ian: in addition to tokenization we are looking within W3C Web Payments at 3DS for improving security of sending payment parameters
... we are looking at how to leverage in web space. we spent 5 hours on it at our F2F last week in Singapore

Matt: the way I look at it is a more secure way to share information up and down, being able to share passive information that is collected
... we can apply machine learning to that data
... we will have enough data that our probabilistic models can reduce fraud further
... from the Mastercard perspective, I have ongoing dialog with our representative in Emvco
... that is what we are going to use for authentication
... I have asked our rep to take that into the issues in automotive such as intermitten connectivity
... when we are thinking of 3DS 2.0, our thoughts include ensuring this can work in a car environment
... the fallback still exists to use RSA token or password from bank but that is not very useful while driving
... the can deny the step-up and take additional risk

<Ian> [Work in progress]

Rodrigo: is the 3DS 2.0 already have that all mapped to W3C Web Payments APIs?

Ian: the WG met last week and short answer is work in progress
... it is a complex discussion because it mixes desire to facilitate 3DS as it exists today plus leverage web technologies for eg increased privacy
... there are also challenges because it includes technologies such as SRC which is not yet public
... I appreciated Mastercard including in their recent announcement the related work at W3C

<Matt_Miller> currently available SRC Data https://www.emvco.com/emv-technologies/src/

Ian: there was a start of an overture from browser vendors in creating JSON for interop

Rodrigo: tokenization aspect can be handled sooner than 3DS, how will they fit together?

<Ian> https://www.w3.org/2018/04/19-wpwg-minutes.html

<Ian> https://www.w3.org/2018/04/20-wpwg-minutes

Ian: tokenization can be realized sooner

<Ian> https://w3c.github.io/webpayments-methods-tokenization/index.html

Ian: the tokenization discussion was particularly productive and will influence our current spec
... there was consensus around use case and related data model to support it
... in a simple model of the world, some party would be a token requestor and send back in pipe to merchant
... authentication is required and cannot be decoupled
... we are exploring who is doing what in this space. we are unclear if browsers want to be token requestors directly or will defer to a locally installed app
... hint I got was was browsers were not interested in becoming token requestors
... downside is that will slow down deployment. some vendors who are also payment providers may take a different stance
... instead of tokens being requested by eg Stripe it will move to the user side and unsure who those parties will be
... Mastercard in particular seems to be taking a lead on experimentation in this space

Matt: we want to push to network level tokenization, it has advantage of being visible across the ecosystem
... it is a goal and available today, apple, google and the other pay are already doing this
... we want to move from hardware to cloud based solutions. 3DS increases the authentication component
... tokenization reduces replay risk

Ian: I have been pitching Payment Request API as the potential flow for all of these
... a question for me still is role of web authentication. I am still piecing things together. in 3DS it seems W3C WebAuthN may make sense
... I know FIDO (which submmited toward WebAuthN) and Emvco have been collaborating on a possible extension
... unsure what we will need to do within Web Payments or if it will be covered by WebAuthN

<Ian> Ted: Any experiments from Mastercard we can talk about in the automotive space?

Matt: connected car opportunity is currently non-existent but has great potential
... where the division with Web Payments and WebAuthN is fluid right now
... the challenges and opportunities is that people want to bring things to market quickly and we may have to do proprietary solutions in the interim
... we are participating in a number of confidential initiatives and people want standardization

<Ian> SAP Vehicles network

Matt: short to medium term, companies will be creating individual solutions. commerce platforms like SAP vehicles network is bringing a bunch of parking providers together
... presently it is not practical for the different parking providers to tackle this separately
... they believe they can aggregate merchant content
... this applies to other IoT models with more going on in automotive at present
... our key position is that OEM level account is what hosts the payment experience. relationship needs to be between consumer and car, that is where you will manage your credentials and payment information
... that interaction will be based on this standard as it emerges

<Ian> Ted: Aggregator++

Matt: aggregation is key to increasing scale initially
... being only able to pay for a single gas company or parking facility is not useful
... it is a behavior that only works in one brand of car
... we will see increased consumer demand however as some individual solutions are available in different cars
... I anticipate the near term these aggregators will contribute a significant role
... take food ordering, they are banding together as well

[discussion of SRC publication timeline, unclear at present]

<Ian> Ted: A topic that has come up is having your personal profile stored in the cloud

<Ian> ..and being able to retrieve it for the duration of a trip then expire

Matt: that is very much aligned with our vision
... we do not want to put payment chips in cars directly. we see DSRC taking hold
... we feel it should follow the individual
... more mobility, shared use cases means it make sense to tie to drivers or individual vehicle operators

<Ian> Ted: We have fleet managers getting more involved in W3C (WIX, Geotab)

Matt: that is why we see individual and corporate (fleet) profiles needing to be cloud based more than on vehicle
... cloud based account that includes payment preferences with clear ownership and authorization
... rental and other fleets will act as a moderator between payment profiles and merchants
... nobody wants to look at the payment data, it will be opaque if not strongly encrypted

Ted: with industry moving to more shared and usage based models we are thinking it makes more sense to have profiles in the cloud and retrieved for short term use on vehicle

Ian: we are not looking at anything like that regarding user profiles or identification

Matt: it is assumed that someone has a profile or there would be nothing to send
... payments data need to be stored somewhere and Payment Request just provides that on demand

Ian: the browsers themselves are stored a subset of information with something akin to auto-fill which is not standards based
... in some cases they are already storing credit card information or calling out to 3rd party payment provider apps on the device
... we are standardizing the API access to that information but not the management of the profiles themselves

Matt: as long as the profile has the capability to fulfill the request it is fine

<Ian> Ted: In light of intermittent connectivity; how are payments managed?

Matt: until we have more consensus on v2x (DSRC), parking merchants would not be able to have hardware to communicate to the vehicle
... going through the internet makes more sense

Ted: for eg parking and fueling scenarios when there is low connectivity we have wondered about whether payment providers would be confortable with using a local hospot given potential for it to be a hostile network

Ian: some people wonder how to use Payment Requests with some constraints like intermitten connectivity
... while en route with poor connectivity it might not be the right too
... we have wondered about connectivity issues for push payments and worked in transaction ids to enable reconciliation later
... I would step back and look at the use case more broadly

<Ian> Ted: Thanks Matt!

<Ian> matt: Regarding 3ds, I think it should be sorted out first in WPWG and then see if we can leverage that for other use cases

Matt: not sure we need to get too deep into 3DS but do need to make sure it can support auto specific