NickTR: Welcome back everyone!
We'll start with QR code use cases, which has grown immensely
in the past few years, starting in Asia.
... it lends itself well to being physically remote (but
proximate) so relevant during COVID-19
<benoit_> twint is a really interesting EU example for QR codes
[Bastien Latge presents EMVCo slides on QR codes]
Bastien: We delivered a
presentation recently in South Africa and Europe; there is
growing interest
... EMVCo specs designed to be flexible to cover a number of
use cases; we'll only look at a few today.
... we will look at two broad cases: merchant-presented and
user-presented QR codes
EMVCO specifications on QR codes
Bastien: History of these specs
starts in specs (2017), followed by self-evaluation testing
service (2018)
... global acceptance mark (2018)
... the mark enables consumers to recognize merchant usage (and
thus how to consume the QR code)
<Zakim> nicktr, you wanted to ask about adoption of the QR mark
nicktr: How widely has the QR mark been adopted?
Bastien: I won't be speaking
about that today; I don't have deployment data
... Regarding consumer presented QR code....reuses the existing
card rails
... the merchant reads the QR code, the POI decrypts it, and
that is followed by the usual authorization request
... a big difference between chip and QR code is that it's a
1-way exchange
[Bastien reviews one consumer-presented flow, showing an app that generates the QR code for consumption by the merchant's reader]
Bastien: This flow is similar to
the usual chip flow.
... I listed a few specifications...we have also published
updates and you should check those out as well
... at some point we will fold that material back into the
specs
... Regarding merchant-presented mode, the merchant generates
the code for consumption by the consumer, typically a mobile
app
... Although the specs are often used for card payments, they
are designed for other payment system usage as well
... and they allow for multiple payment networks within the
same QR code
... QR codes can accommodate local requirements
... the user experience can be the same however many networks
are represented in the QR code
... ...we have one example of 8 payment networks encoded in the
same QR code, so the user does not have to hunt around to find
the QR code to go with their preferred payment app
... The format supports extensions (e.g., for local
needs)
... We have done some tests recently with a variety of mobile
handsets reading QR codes (merchant-presented mode). The
results showed us that (1) the number of payment networks
supported does not affect the time to read the code, and (2)
the average reading time [including phones back to 2014 models]
is less than 1 second
... ..if we look at phones less than 3 years old (the average
lifetime of phones in the market, the read time is .5
seconds
[Use cases on slide 12]
Bastien:
* Base example
* Transaction amount provided
* Multiple payment networks
* Convenience fee
* Alternate language
* Bill pay
* Additional data field
Bastien: QR codes can be static
(good for printing stickers for example) or include dynamic
information (good for security)
... Static QR codes suitable for merchants that do not use a
digital display
[Bastien shows example with an amount in a QR code, hence dynamic one]
ChrisD: How does the merchant know that a payment has been successfully made?
Bastien: EMVCo does not define that. The spec provides merchant/app interoperability. How the merchant learns about the transaction status depends on the payment method.
ChrisD: Regarding dynamic linking: are these transactions considered "authenticated" in 3DS terms?
Bastien: There are multiple ways
to authenticate (including 3DS). But since these use cases are
face-to-face, one can imagine CVC code. There are ways to add
cryptograms to the QR code.
... the issuer can verify the cryptogram.
... there are many ways to perform authentication but this is
not defined by EMVCo.
Ciciley: Can merchant-presented
QR codes include dynamic data?
... e.g., for fraud prevention
Bastien: Our objective is to
accommodate lots of use cases, so nothing is mandated in this
regard. The specification supports dynamic QR codes.
... the issuer can determine whether the code includes dynamic
information.
[Crystal Duan presents Union Pay slides on QR]
Crystal: I'd like to introduce
Online QRC solution
... Our QR codes leverage the EMVCo specifications, using
dynamic data
... a major advantage to QR code usage is similarity between
in-store and online experiences
... users have union pay cards in their apps because in-store QRC is very popular in places like China, so many cardhlders has downloaded the available APP, bound the card and finished authentication in advance. When Online QRC appears on the webpage, thay can just scan the QRC and finish the payment in the same way as in-store QRC, which can greatly improve the user experience.
... typical scenarios for online QR code are: online payment,
tv shopping, game console
... in online QRC, the QR Code is in merchant-presented mode.
... the union pay-generated codes are called "SecurePay
QRC"
... the merchant-generated pages are generated by the merchant
or acquirer for display on merchant page.
... the SecurePay code, on the other hand, requires no
modification for SecurePay merchants.
... the QR code is displayed on the union pay page (rather than
the merchant page)
[Screenshot of an online merchant QRC]
[Screenshot of a SecurePay displayed code (by Union Pay)]
<nicktr> nicktr: is the Union Pay solution the same as the EMVCo spec?
Crystal: There are many
similarities between online and in-store codes (rules, user
experience, risk and liability). Note that the issuers and
acquirers bear the risk in in-store cases.
... some differences: HTTP message format
... online merchant QR requires acquirers / merchants to
generate and display the QRC (requiring developer effort in
acquirer host system and merchant site)
... in general, we find that acquirers (not merchants) are
generating the codes
... We follow the EMVCo specification for international
merchants, for domestic merchants we're using the same flavor
that WeChat and Alipay use.
Marijke: Today I'll talk about QR
codes for mobile initiated (SEPA) credit transfers ("MSCT").
... started our work a couple of years ago
... scope is technical interop of credit transfers
... the credit transfers themselves (whether instant or
regular) are defined elsewhere
Marijke: we started from a
generic model where the payer has a payer service provider as
does the payee. We are focused on the interoperability between
the respective MSCT service provider, e.g., across country
boundaries.
... We are looking at a
variety of transaction types: P2P, C2B, B2B
... within those we are looking at a variety of proximity
payment use cases, including some involving QR-codes
... but also NFC, BLE, geo-fencing, etc.
... looking at minimal at a sets for payee-presented QR
codes
1) all transaction data is available in the clear to the payer
2) the payer uses a proxy for the payee
3) The payee-presented transaction data includes a token
Marijke: We've been looking at
flows necessary to detokenize
... suppose the consumer reads the QR code from a POI, the user
might be redirected to a Web site to conduct the
transaction.
... during the past month more and more use cases have been
proposed.
... our payee-presented QR code is URL-based
... HTTPS scheme
... the path component includes: version, type, routing
information, payload information
... We did a similar study for payer-presented QR codes, and
again looked at three principal use cases:
1) payer-presented data includes a token
2) payer-presented data includes customerID and IBAN "in the clear"
3) payer-presented data includes customerID and proxy
Marijke: and from these use cases we have derived a similar URL format
IJ: What does "proxy" mean in this context?
Marijke: Might be something
linked to an IBAN but is some other identifier like phone
number or email
... This umbrella definition is designed to accommodate
existing local approaches (a variety of countries)
... we have also published some interop guidance, and step-wise
descriptions of flows.
... These documents have
gone through public review; we are awaiting board approval in
early December 2020
AdrianHB: What happens if one tries to dereference these URLs?
Marijke: I would assume one can
dereference, but I am not familiar with all the
implementations.
... Regarding security of data, we are still discussing this,
especially wrt EU regulations. We have some questions about,
e.g., encoding some data in "clear text" in the QR codes
... we are also interested in offline use cases (more work
required)
... another challenge: unknown final transaction amount...MSCTs
are push payments which is the source of the challenge
... [More challenges related to entity identification]
... Please check out the docs; future docs will be subject to
public consultation. W3C invited to comment!
NickTR: Is now a time for comment?
Marijke: Not at the current moment, but in Q1 2021 I expect we'll publish new use cases
NickTR: Seems like good opportunities to align with PR API and EMVCo specs.
For more information, see: The ad-hoc multi-stakeholder group for Mobile Initiated SEPA Credit Transfers and Documents published by the group
[Gerhard Oosthuizen slides on Entersekt perspectives]
Gerhard: Merchant-presented QR
codes feel like a good fit for e-commerce checkout. The interop
challenge is arbitrary sites/apps speaking with arbitrary
payment apps.
... from a consumer perspective, the experience should be
similar between online/in-store and across different use
cases.
... problems with QRs today:
1) Typically closed loop. (EMVCo workin on this)
2) Merchant has to choose which QR code to support
3) Consumers also have to set up QR-brand-apps
Gerhard: merchants have to support
multiple formats if they want wider coverage
... merchants critically need to know status of transaction
(success) as part of willingness to adopt. Downloading apps,
choosing from among apps, this is all friction.
... The QR code itself is
not that important; it's just a link between two parties. Could
be done in many other ways (e.g., BLE, Web link, etc.)
... benefits is convenience, lower friction, increased
trust.
... global proliferation of
QR codes is a problem. EMVCo QR attempts to consolidate QR, but
still requires multiple providers baked into one format.
... it's ideal for the consumer to use the "account provider
app" such as a bank app.
... two important concepts:
- merchant presented natural fit for ecommerce
- push payments v. pull payments
Gerhard: ..let's start with
example of merchant presented QR with push payment
... what happens if the transaction is no longer available
(e.g., expired)
... need user consent to use an account for the
transaction
... the bank pushes notification to the merchant's acquirer;
the merchant then ships the goods
... In second use case, merchant QR code with push payment, but
some information is not available in the code (e.g,.
IBAN)
... so lookup is used
... it is also valuable in some cases for the code to be
_short_
... in this case, the QR code is scanned, and then the system
needs to do a lookup .. e.g., details on where to deposit
money, what formats are supported, etc.
... after that, the flow looks similar with consent to pay,
addition of tip potentially, etc.
... In the third use case, it's merchant provided code with
card pull payment.
... in this case, the info is submitted to the QR provider,
which gives it to Acquirer, which then requests payment
... the user experience is still the same even if backend flows
differ
... in the third use case, we already have user consent...we
use 3DS with card data and already user consent.
... I'd like to raise the "single device" problem.
... What if the merchant site is on the same device as the
trust app?
... in this case, the QR code can't be scanned...but perhaps we
could hand off to a payment handler.
... we could hand over information to the payment handler
... from a merchant perspective, the merchant just wants the
data.
... I think this group could explore 5 problems:
1) Consumer could install a "QR code provider" from an issuer.
2) Merchant could generate a consolidated QR
3) Seamless interop between 1-device and 2-device use cases...if there's a payment handler, show it. Or if not, generate QR code. The Browser in this case helps increase interop among the parties
4) Include provider integrity check: how do you prevent against sending funds to illegitimate merchants?
5) Include consent (e.g., via pre-consented QR)
NickTR: These sound like real pain points you've experienced. Can you tell us about QR code adoption in South Africa?
Gerhard: Originally adoption was
brand-based
... what we've done recently is start to enable it for
banks
... we are in the 10s of thousands per month, with more banks
coming
... ...there's a potential for this to work in e-commerce to
avoid retyping card info
NickTR: Thanks for listing five problem statements. What would merchants say about the priority?
Gerhard: Merchants will first ask
about lowest interchange rate. After that merchants want
interop and not having to support lots of formats.
... ...they would like maximum coverage per QR code
format
... it would be great if merchants could rely on payment
handlers to provide the interop, and the merchant just gets
back that data they need
<AdrianHB> The CEO of a large South African merchant payment service provider told me "Merchants support the payment methods customers ask for. They don't add payment methods to attract customers."
Clinton: I think this
presentation provides a lot of insight that the scope of the
problem is highlighted by QR.
... do you think we are making progress to interop ? Where are
major gaps?
Gerhard: I think we need to be
able to "resolve" a QR code. We need a directory service that
"goes the other way". It allows me to find a QR provider and
get an answer back.
... and then perhaps routing help to submit a transaction the
right way
... The EMVCO standard is good for DISPLAYING the code. I think
the EU committees work on representing information as a URL is
also valuable...to work on both desktop and mobile
... this removes one click
Nick: Thanks to all the
presenters today!
... clearly a lot is happening in the QR space
... seems like good opportunities for more interop; and a role
for bodies such as EMVCO, W3C, EPC
John: We are headed into
Candidate Recommendation for Web Authentication Level 2
... we'd like to get to Proposed Recommendation in Q4
<nicktr> vainu: vainu from c-dac, w3c india chapter here - just wanted to know if we have anyone in the room with india specific presence and qr technology-- national payments corporation , paytm, indian banks
<nicktr> vainu: in case of no internet - some apps use ussd code
Tony: Our charter expires soon so
need to see if we have to extend it
... if we move to "Level 3" we may need to formally
recharter.
... Here's the latest on Level 2
... there's been some cleanup from Level 1, including editorial
changes.
... there have been changes in the Extension Framework
... Level 1 had a bunch of extensions that were not implemented
in practice
... such as transaction authorization, geolocation, biometrics
performance bounds
... those will remain a part of Level 1, but we've removed them
from Level 2
... there are two new extensions in Level 2:
1) Large blob storage
2) Credential properties
Tony: it was a Working Group
decision not to continue to support unimplemented
extensions
... and this created some challenges for us moving Level 1
through Candidate Recommendation
... removal in Level 2 should ease our path to
standardization
... we have also added (1) Enterprise attestation and (2) Apple
attestation
... the Apple one was included in just the past few weeks
... there are some terminology clarifications in the
specification
... we are going through a controversial issue from a W3C
process perspective - are Edge and Chrome two separate
browsers?
... we are making the case that they are because of how Edge
folks have implemented the spec
... recall Level 2 decision to allow get() from 3p context in
an iframe
... we don't have any changes to the spec related to
transaction confirmation; people don't think a change is needed
in WebAuthn or are not interested
(IJ notes that SPC speaks to this as we discussed on Monday)
IJ: What do the new attestations give you?
Tony: In the WebAuthn Adoption CG
they are looking at verification of the Apple attestation
... this will give you the attestation (for both MacOS and
iOS)
... the Enterprise Attestation is for MDM-type
environments
... With the Enterprise attestation, FIDO needed to tweak their
privacy principles white paper
... there were some statements about non-correlation.
... the enterprise attestation allows correlation to happen
John: The attestation gives enterprises tools for device management
Tony: This is one of the key
features that large enterprises have asked for. Some vendors
had done this prior to the standards effort
... there may be some guidance about not using an enterprise
ready authentication on the public web
nicktr: You mentioned that you are in the throes on the question of "separate implementations". What is your perspective on this?
Tony: Lots of products use
publicly available code. This is (perhaps a larger ) variation
of this phenomenon. Code is modified and not 100%
identical.
... And if the code is deployed to different environments, I
would consider this two separate implementations
NickTR: I agree they are separate implementations, but not necessarily "independent"
IJ: Related to this topic: breakout sessions next week (see Breakout calendar and in particular session on engine diversity).
AdrianHB: See also the Web
Monetization session (29 Oct)
... we are also trying to put together a panel at 2pm UTC...a
panel on revenue models for the web
NickTR: Thank you for the WebAuthn update. We have a keen interest in relationship to SPC. We heard that probably no WebAuthn changes are needed for SPC. IS that still the consensus?
Tony: Yes, although we'll keep an eye on it
<nicktr> ian: gerhard raised the role of remote authenticators in SPC (Chris Wood too)
<nicktr> ...where is that work happening?
Tony: CaBLE (cloud-assisted BLE). That's not in Level 2. It is
currently in Google's hands. There is some work that is
related: IP-transport
... the IP work piggybacks on work that CaBLE leverages. This is "Level 3"
work
... many challenges derive from bluetooth interop issues
... There is a lot of interest in this area and I think it will
happen, but not in Level 2 timeframe. QR code also enters into
the CaBLE discussion
<AdrianHB> Grant for the Web Breakouts:
<AdrianHB> 28 October - 4pm UTC: https://www.w3.org/2020/10/TPAC/breakout-schedule.html#Grant-for-the-Web-1
<AdrianHB> 29 October - 1am UTC: https://www.w3.org/2020/10/TPAC/breakout-schedule.html#Grant-for-the-Web-2
NickTR: Thanks everyone for
coming today!
... on the agenda tomorrow: open banking, web monetization,
RTP
[ADJOURNED until 22 October]