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