WPWG Virtual Meeting

21 Oct 2020



Ian Jacobs (W3C), Ciciley Nelson, Hervé Robache (STET), Tetsuya Kono (JCB), Danyao Wang (Google), Adrian Hope-Bailie (Coil), Jean-Michel Girard (Worldline), Manoj Kannembath (Visa), Fawad Nisar (Discover), David Benoit, Gerhard Oosthuizen (Entersekt), Frank Hoffmann (Klarna), Chris Dee (FIS Global), Gavin Shenker (Visa), Andy Estes (Apple), Olivier Maas (Worldline), Lawrence Cheng (Barclays), Myungho Han (INCA), Chris Wood, Bryan Luo (Amazon), Jonathan Vokes (FIS Global), Mathieu Hofman (Stripe), Takashi Minimii (JCB), Clinton Allen (American Express), Florent Lambert (Lyra Networks), Giulio Andreoli (Apple), Nick Telford-Reed, Benjamin Tidor (Stripe), Erhard Brand (Entersekt), Crystal Duan (Union Pay), Yuejing Yang (Union Pay), Marijke de Soete (European Payment Council), Stephanie Rieger (Yiibu), Tony Nadalin, John Fontana (Yubico), Vainateya Koratkar (C-DAC), Rachel Yager (FortuneTimes Group), Jeff Hodges (Google)
Nick Telford-Reed
Ian Jacobs



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

EMVCo QR code specifications and use cases

[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]


* 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.

China Union Pay QR code use cases

[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.

EPC on QR codes for mobile initiated (SEPA) credit transfers

[Marijke de Soete slides]

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

Entersekt perspectives on QR codes

[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

Web Authentication WG update

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]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/10/27 13:18:21 $