Home » Web » HTML » W3C Interview: Capital One and Tyfone on Tokenization for Web Payments

W3C Interview: Capital One and Tyfone on Tokenization for Web Payments

W3C’s Web Payments Interest
Group
is gaining momentum in its pursuit of the integration of
payments into the Open Web Platform. As part of building understanding
security, and the role of the Web, I am organizing a series of
interviews on Web payments. In this first interview with Tom Poole and
Drew Jacobs of Capital One
, and Siva Narendra of Tyfone, we open with
the broad question of what the Web needs to facilitate eCommerce.

Ian Jacobs (IJ): Let’s jump right in. The Web is 25 and people have
been engaging in commerce from the start. But smart phones,
cryptocurrencies, and stories of stolen passwords and other sensitive
information have created a lot of new activity around payments. What
does the Web need so that we achieve the full potential of ecommerce?

Drew Jacobs (DJ): The Web is clearly one of the most prominent
channels for payments today. But there are gaps and pain points
across the value chain, from the consumer to the merchant to the
financial institution. The reality today is that the process for
online purchases today can be convoluted, often requiring a lengthy
checkout process where you provide a lot of information without a lot
of security. Over the years solutions have emerged such as Amazon¹s
One Click to reduce friction at checkout. Other capabilities in
market today attempt to solve the challenge of convenience and
security, but no clear winners have emerged. We see a lot of
opportunities in the payments ecosystem for improving the lives of
customers, and giving them new tools for payments.

DJ: For example, online credit card transactions today leverage static
data and are therefore vulnerable. We are seeing a move toward
tokenization.

Editor’s note on tokenization: In eCommerce today, consumers typically
provide sensitive information such as credit card numbers directly to
merchants. Many in industry see tokenization as a promising secure
alternative. As an example of tokenization: when I want to pay for
something with a credit card issued by my bank, the bank can send me
an electronic token that I give to the merchant. To the merchant the
token is a meaningless sequence of numbers, but it can be “redeemed”
at my bank as part of settling payment. This indirection through a
secure token benefits the consumer, who keeps control of sensitive
information, and also merchants, whose liability is reduced in the
case of attacks on their IT system.

DJ: But tokenization should not be a separate process from other forms
of payments, we need a cohesive solution across channels. I want to
add that there are also many new opportunities to provide customers
with richer experiences by leveraging data available to merchants or
to banks.

Siva Narendra (SN): I agree with Drew that we need to improve
security. Today, ecommerce is a relatively small proportion of the
world’s overall commerce; I believe around 7%. But there is a fraud
rate of about .9% for ecommerce while it is .09% for other forms of
transactions. So the fraud rate for ecommerce is 10 times what it is
for non-ecommerce. There are a number of reasons for this, including
the fact that passwords are not very effective. Tokenization, as Drew
mentioned, is an important path for the future. But securely
authenticating the right user is being provisioned the right token is
necessary, otherwise criminals can steal tokens, too. When you have a
secure element on your phone that can be used for authentication, for
example, your fraud footprint decreases significantly. Tools provided
by the Fido Alliance are useful, but they do not yet take into account
tokenization standards already in use. I also agree with Drew that
leveraging data can be powerful, but I think consumer privacy
protection is going to be a big issue, and there may be pushback if
users start to receive a lot of annoying alerts.

DJ: Our data can enrich the experience or make it more efficient, but
I agree with Siva about the importance of privacy.

IJ: It sounds like security should be our first focus.

DJ: Yes, we need to secure both authentication of the user and then
the transaction itself. But we also need to simplify payments. Today
there are many disjointed ways to pay: PayPal, Credit Cards, wallets
from Apple, Google, etc. There’s already a proliferation of checkout
bugs for payment instruments on Web sites. Introducing more is not the
answer.

Tom Poole (TP): The more checkout bugs, the less likely any particular
one will be noticed. There are three different levels where payments
could be improved. The first involves adding support for secure
storage of information, such as via a browser plug-in. An open
standard would enable multiple providers of such plugins (and of
course, browsers might provide their own solutions). The next level up
is the “white label container” like Softcard that could provide
consistency for payment scheme providers, but still allow for
innovation. The third layer would be to build on something like Apple
Pay, but that would mean very little differentiation and a single
vendor would drive the normalization of payments. But I don’t think
many people want to invest in that sort of centralized
solution. Rather, I think they will want to differentiate by building
better or smoother experiences. W3C should focus on core service and
leave a lot of room and levers for innovation.

IJ: Ok, so within the first two levels, where should W3C focus?

TP: Identify what is the narrowest service that must be delivered.
One will involve delivery of payments credentials. As Drew and Siva
have mentioned, tokenization will play an important role, and the
browser (or plugin) would securely store credentials. Over time, we
could see direct fill of information in the background, which could
further increase security by reducing attacks like
keylogging. Ultimately it would be create to standardize the
interactions with merchant checkouts, so that sites have a common,
secure approach that works across browsers, speeding up transactions,
and enabling financial institutions opportunities to add value.

SN: I agree we should start by securing authentication and the
transaction. W3C is working on a Web Crypto API that
gives developers access to cryptographic operations from JavaScript.
I think there’s an assumption in the browser community today that the
only token that browsers will support is FIDO Alliance-based. But I
think we need greater interoperability. We do need to be looking at
secure elements, but chips in phones are not the only way to achieve
that. There is a large existing infrastructure for security and we
need to extend those capabilities to the Web to achieve scale and
success.

IJ: What are the most important bits of infrastructure that you think
we should be leveraging for the Web? What should we be connecting to?

SN and DJ simultaneously: Tokenization!

SN: There is no better security than hardware in someone’s hands.
Browsers should allow integration of the security modules available
through these portable devices. These security models might be running
in the cloud, as software on a device, or in a secure element in
hardware. For example, browsers might provide access to secure element
via a password (and the risk and reward will be different according to
application).

DJ: I agree we should be connecting to existing infrastructure,
especially around tokenization, and that there should not be a single
solution for all applications. Different needs will drive different
solutions.

SN: In my view, anything other than tokenization to secure the
transaction is probably not going to be acceptable to the financial
industry. We also want to see convergence between ecommerce and
in-store purchases.

IJ: What will that require?

SN: Building on top of existing tokenization standards will also
facilitate convergence. There are questions about liability between
physical and ecommerce transactions, but there are well-understood
rules of engagement between banks.

DJ: The key point for us is that W3C has a unique opportunity to
provide underlying infrastructure standards that leverage existing work
around tokenization. That is the biggest pain point for us today:
tokenization doesn’t exist easily online, and we need greater security
online. We think browsers can play a role in bringing this together.
We also see opportunities around improved authentication and
identification of the real user.

IJ: What will be the biggest benefits to banks if we can do this?

DJ: Improved security, both in terms of user perception and also
protection of assets. And merchants and banks will both benefit from
lower rates of shopping cart abandonment if we¹re able to build an
infrastructure that helps reduce the friction that exists in today¹s
checkout experience.

IJ: Thank you all for your time!

Feed Source: W3C Blog
Article Source: W3C Interview: Capital One and Tyfone on Tokenization for Web Payments

About Admin

Powered by WP Robot