WPWG Virtual Meeting
19 Oct 2020



Ian Jacobs (W3C), Takashi Minimii (JCB), Myungho Han (INCA), Ciciley Nelson, Vainateya Koratkar (C-DAC), Anne Pouillard (Worldline), Fawad Nisar (Discover), Frank Hoffmann (Klarna), Danyao Wang (Google), Adrian Hope-Bailie (Coil), Chris Wood, Hervé Robache (STET), Jonathan Grossar (Mastercard), Nick Telford-Reed, Gavin Shenker (Visa), Mathieu Hofman (Stripe), Tomasz Blachowicz (Mastercard), Tetsuya Kono (JCB), Lawrence Cheng (Barclays), Olivier Mass (Worldline), Desigan Chinniah (Coil), Joshue O'Connor (W3C), Jean-Michel Girard (Worldline), Justin Toupin (Google), Giulio Andreoli (Apple), Florent Lambert (Lyra Network), Jalpesh Chitalia (Visa), Bryan Luo (Amazon), Kagami Rosylight (Mozilla), Benjamin Tidor (Stripe), Jeff Hodges (Google), Philippe Le Hégaret (W3C), Mustaq Ahmed (Google), Rouslan Solomakhin (Google), Andy Estes (Apple), Gerhard Oosthuizen (Entersekt), David Benoit
John Fontana (Yubico)
Nick Telford-Reed
Ian, Nick



<nicktr> https://github.com/w3c/webpayments/wiki/2020-TPAC-WPWG-agenda

<Ian> Please review the W3C Antitrust Guidance.

Agenda Background

[Ian Jacobs slides on agenda background]

[slide 2] - Agenda

ian: our hypotheses on streamlining checkout have changed
... and we learned a lot from experimentation and implementation
... here's my take on our hypotheses
... 1) moving data storage from merchant to browser
... (participants that there is value here esp for guest checkout)
... but we have not seen many payment apps beyond the "*Pays"
... 2) a single "Buy button" would remove the "Nascar effect" and that would be valuable
... but this didn't pan out - users and providers want the brands
... and controlling the ordering of apps/methods on the page remains critical
... 3) standards would encourage diversity of payment apps
... but the cost of creating UX seems to be a real barrier

[we are at slide 7]

4) supporting a variety of authentication flows would be enough

scribe: but interest in WebAuthn and other related topics has grown
... and privacy changes in the browsers are triggering conversations about authentication use cases.
... handing over authentication to another group might not be enough

[slide 10]

ian: so we'd like to present some revised hypotheses
... A) Payment Request provides some value "as-is"
... B) There is high value in providing low-friction flows for strong authentication
... C) There is value in providing zero-friction pathways for risk assessment (but cognisant of user privacy implications)

AdrianHB: we need to be aware of payment method *and* payment values - the risk assessment that is appropriate for low-value is not the same
... and so balancing friction and privacy is challenging

ian: there is a potential workstream associated with each of these

[slide 11]

ian: D) guest checkout facilitation is valuable but we may have to do it differently (and we will discuss tomorrow)
... E) to help with adoption, we may want to reduce the complexity of the APIs/specifications to make them more useful/easier to implement

[slide 13]

ian: we want to move payment request forward to rec
... and we want to talk about new features and how to handle them
... we are going to talk about Secure Payment Confirmation
... WPSIG is going to talk about zero-friction risk assessment and it may come back to the working group in the future
... we are going to hear about use cases from a number of different payment systems

[slide 15]

ian: SRC demos tomorrow
... we would like to present some prioritisation on Thursday (good luck Chairs)
... it would be good to have a plan
... and we need to start looking ahead to charter renewal (or otherwise) at the end of 2021

NickTR: Thanks for putting that together, Ian

Secure Payment Confirmation (SPC)

[Danyao Wang and Benjamin Tidor slides]

Danyao: Problem statement: enable strong auth during checkout that works at scale for all payment methods across all merchants
... Four design principles:

1) Great consumer experience (fast, low-friction)

2) Each of adoption for merchants and issuers

3) Satisfy PSD2 SCA including dynamic linking

4) Privacy preserving by default

Danyao: For scalability:

1) Want one credential that works across all merchants

2) Don't want merchants to have to have out-of-band agreements with financial institutions

3) No redirect or iframe for usability and privacy

Danyao: SPC Is basically a combination of FIDO and PR API

(Ian referred to this earlier as "coupling the APIs")

Danyao: The pilot use case that we describe here is to leverage WebAuthn as low-friction 3DS2 step-up. It does not involve stored credentials, to make it easier to test with a traditional checkout form.
... API superpowers are two-fold:

1) Cryptographic binding of transaction details into the authentication assertion

2) Merchants can exercise payment credential owned by the issuer (the RP). In vanilla WebAuthn, this would not be possible. Only possible in PR API context

Danyao: We are shipping this experience in Chrome 86 on MacOS, available for origin trial.

[Demo by Benjamin Tidor]

Benjamin: User selects or enters instrument before SPC is invoked.
... In enrollment flow (0) user is authenticated through something like OTP (1) FIDO authentication credential is enrolled with the issuing bank and (2) payment is completed.
... during checkout, the user is given the option to confirm an amount from an account to a beneficiary, and then to sign that information using the enrolled credential
... ...so that's a good experience and the data should support transaction confirmation use cases

Jonathan_Grossar: It's great to have these new browser capabilities because it enables other parties to have access to credentials, and because the browser is displaying info for transaction confirmation. Will this capability be available for other use cases than 3DS?
... e.g., some merchants might want to use their own credentials, or a wallet might want to use these capabilities.
... I'm not sure about the scalability comment since this seems to require all banks to provide FIDO servers.

Danyao: To answer Jonathan: Yes, this capability is available for other flows. All that's required is for an origin to provide credentials to the browser to prompt for authentication. The details of where the credential ids come from is left to the use case.
... ...in some cases it might be from the merchant, or the merchant might have to fetch them (e.g., from 3DS server)
... or a payment handler could provide them

Jonathan_Grossar: When we document the assumptions we should make clear it's not just for banks.

Chris_Wood: How do discoverable credentials (formerly, "resident keys") fit into this?

Danyao: We are aware of discoverable credential capabilities, but we haven't yet thought deeply about how to integrate them. But our design does not assume discoverable credentials because (1) we want this to work with WebAuthn Level 1 and (2) not all authenticators support discoverable credentials.
... we want to look more into this; conceptually it should work pretty well
... To recap the demo, there are two flows: (1) Enrollment of credential on a device with an RP (2) checkout flow
... During checkout, merchant needs to know credential ids. The pilot leverages 3DS (PAN => credential id)
... merchant provides credential id to browser which prompts user to authenticate
...the browser displays transaction details, combines details into the webauthn request, and then returns the Web payment assertion (including signature over transaction details)

[Danyao shows flow diagram of initial proposal involving 3DS server]

Danyao: SPC experiment is "as a payment method" but the expectation is that SPC (once it demonstrates value) will be implemented in away to make it available across payment methods
... Note that the dynamic random data is provided by the issuing bank (Relying Party)
... the dynamic data is input to Web Authentication
... the browser returns information useful for transaction confirmation in plain text, but also a signature over that data. That allows the RP to validate the data.

[Danyao shows SPC from an API / implementation perspective]

Danyao: Contact me if you want to conduct an origin trial. The Stripe experiment is expected to run for about 8 weeks. We expect full analysis by Jan 2021. Thank you Stripe for being willing to share data on the experiment when complete.

[2021 SPC Roadmap]

Danyao: If SPC proves useful we need to:

a) Get changes to 3DS to support credential ids, etc.

b) We need real ACS to implement this
... once we have done these things, we can make the API available to everyone.

c) Explore compatibility with Android SDK

d) Standardization and availability on other platforms

e) SPC for other payment methods....we are looking for collaborations with other partners

Danyao: looking for developer interest and browser implementer interest in SPC

NickTR: Thanks Danyao and Benjamin!

Jeff_Hodges: Where in the flow is the network data conveyed from the issuer back to whoever is putting together the challenge?

Danyao: The network data comes back from the issuer to the merchant via a new 3DS message. The merchant provides the data to browser through PR API

tomasz: Thanks for the demo; great to see this coming together. Will this be available to payment handlers as well?

Danyao: Yes.
... Payment handlers need to open a window to use WebAuthn.....SPC could remove at least 2 clicks in a payment handler context
... SPC today can't be used by a PH, but in the future yes.

Gerhard: Like others I am excited by this.
... +1 for Android support!

<nicktr> +1 for android too

Gerhard: Please also consider hybrid apps in your thinking.
... 3DS adoption may be slow. Have you explored other ways to accelerate adoption?

Danyao: I have understood indeed that adding a message to 3DS may require a couple of years. So backwards compatibility is top of mind .... namely shoehorning flow into existing messages.
... but we don't yet know exactly what this would look like. We are having good conversations with Sameer, et al. in 3DS WG

Benjamin: We've heard from others as well that this needs to work before 3DS 2.3.

Gerhard: Does this flow support frictionless?

Danyao: Not right now, since the pilot involves step-up. But we've heard clearly that people want this to work with frictionless flows. So we will be figuring that out.

Gerhard: There are two cryptograms (1) FIDO cryptogram and (3) 3DS cryptogram.
... It would be great to provide as input a PAN and get back the real cryptogram. Has there been any consideration around removing the need for an explicit AReq from the merchant if they can get the cryptogram another way?

Danyao: I think Mastercard is looking at getting final cryptogram via a payment handler
... Our current approach is intentionally experimental to reduce cost on merchant but I agree PH might be next step to combine 2 into 1

<Zakim> Ian, you wanted to ask when SPC turned from payment method to capability (wrt roadmap) and to ask about 3DS message status

ian: SPC is implemented as a payment method - but we've heard that it's desired to work cross-payment method
... where does this become a "capability" rather than a payment method in the roadmap?

<Ian> Danyao: SPC-to-primitive might happen at origin exit or sooner

ian: what's the latest on the 3DS message? New message? Changes to existing message?

<Ian> Summary of impact on 3DS today and in future?

Benjamin: In the explainer there's a note about what it looks like for a payment to support SPC and what functionality is required.
... EMVCo is looking at what it would take to integrate into 3DS. I think there a couple of proposals under discussion

<Zakim> nicktr, you wanted to talk about implementation/adoption

nicktr: In response to a Gerhard comment...we should not be swayed by the need for change in order to produce a significant improvement.

<btidor> ++nicktr

NickTR: ...illustrating reduction in drop-off really drives home the business case.

Danyao: Thanks, Nick. Benjamin, ball in your court! :)

Tomasz: Regarding the need for adoption by merchants...is there data about how many banks are going to use Web Authentication?
... the proposal relies on an assumption that banks will adopt Web Authentication over other authentication mechanisms.

Benjamin: We have heard some positive signals from some ACS's
... even anecdotally we've heard within Stripe that having strong authentication integrated into the platform is attractive.

Tomasz: Issuers need to be sure of wide support otherwise there is a risk of dropoff

Benjamin: I think partly it remains to be seen. Work in 2021 will involve getting more adoption. Issuers will need to run a FIDO server but won't have to do a lot of front end development. They could use Web Authentication today but SPC will make it easier for them.

Tomasz: It would be great to see some data about issuer adoption potential

Gerhard: We've seen a lot of interest from issuers we've spoken with. They have wanted to know where deployed. All solutions will have a hybrid approach....some will use SPC, some will use apps, some will use OTP.
... but we've definitely heard interest in this for ecommerce

AdrianHB: Regarding payment handlers: there is a communication between the merchant and RP (or bank). Payment handlers let you run code in the browser from the RP. It might replace one or more backend calls. In the 3DS case, the preference was to stick to the existing merchant and ACS (which flows via the backend). But for other payment methods, payment handlers would definitely be a valuable alternative.
... all the proposed architectures are going to be validated by experimentation as we go

Ciciley: Will there be any efforts to include fraud measurements for issuers? There is still the concern around synthetic fraud (see synthetic fraud definition, for example).
... I recommend that your pilot includes scenarios when someone pretends to be someone they are not.
... what failsafes are in place to prevent those transactions from being false positives

Danyao: Thanks for the recommendation. This is one of the benefits of using FIDO. The main ID & V happens at enrollment.
... after enrollment, the authentication is just checking that the user is still in possession of the authenticator.
... There may be attacks still possible, but it's likely they are more difficult than, e.g., just stealing a phone number.

Ian: See FIDO White papers and ID & V work. Also, see the work of the >WebAuthN Adoption Community Group, which may be able to help out in understanding obstacles developers (e.g., of banks) face in adopting Web Authentication.

<Chris_Wood> For info: 3DS 2.1 & 2.2 handles FIDO data as a blob in the field threeDSReqAuthData - 2.1 has a 2k limit, 2.2 has a 22k limit

NickTR: I absolutely hear Ciciley's concerns. The balance of consent, authentication, friction, etc. is at the heart of the debate.
... the merchant business group will be another venue to hear from merchants about priorities; talk to me about that
... when people talk to me about "what's new" in the SPC space, the availability of (conforming) authenticators on so many devices is really new and exciting

Danyao: Thanks for the questions and recommendations. We welcome feedback moving forward.
... you can file issues directly on GitHub: https://github.com/rsolomakhin/secure-payment-confirmation/issues

Benjamin: Thanks all!

Payment Request API

ian: shout out to Marcos Caceres; it's the middle of the night for him so he is unable to attend the meeting.
... payment request is deployed and is being used
... our plan in 2019 was to increase adoption
... the browser members of our group have indicated an enthusiasm to move to a full recommendation
... today we are a "candidate recommendation"
... the next step is "proposed recommendation"
... but because we have removed some unimplemented features we need to go back through CR
... the Call for Consensus lists the changes. The first is to remove "merchant validation" into a separate specification to be published as a note
... hasEnrolledInstrument is not shipping in two browsers so we have moved it to a "future" version and it won't be a formal part of v1.0
... and we continue to look at privacy implications of hasEnrolledInstrument
... lastly we had a included an attribute to allow child frames to implement payment request but we have deprecated it in favour of a more general attribute from HTML5
... I wanted to call out that we had a privacy objection raised by Sam Weiler around oversharing of address information.
... there has been discussion around this and a proposal of how to fix, but there are no implementations of it
... but the desire is to move to a more stable "V1" spec while continuing to work those privacy issues
... our call for consensus ends on Monday 26th October
... there are a large number of steps to go through but our intention (see timeline) is to reach "Recommendation" late in Q1 2021

ian: I would be interested to hear informally from the group - this is not your formal response


<AdrianHB> +1

<benoit> +1

<danyao> +1

<Chris_Wood> +1

<Anne> +1

<Ciciley> +1

<Ian> IJ: Please reply to the CfC by 26 October!

<Ian> NickTR: Thanks to presenters and people who raised questions.

<Ian> ...tomorrow we'll talk more about architecture and SRC

<Ian> [ADJOURNED until 20 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/22 17:43:09 $