Web Payments Working Group
16 Apr 2020



Ian Jacobs (W3C), Nick Telford-Reed, Rouslan Solomakhin (Google), David Benoit, Clinton Allen (American Express), Andrey Bannikov (Facebook), Danyao Wang (Google), Lauren Helt (American Express), Lily Chen (Google), Rowan Merewood (Google), John Fontana (Yubico), Marshall Vale (Google), Rolf Lindemann (Nok Nok), Sophie Rainford (American Express), Adrian Hope-Bailie (Coil), Mathieu Hofman (Stripe), Kaustubha Govind (Google), Fawad Nisar (Discover), Chris Dee (FIS Global), Jonathan Vokes (FIS Global), Rob Martin (Capital One), Gerhard Oosthuizen (Entersekt), Marek Kurylko (Mastercard)


Recap of virtual meeting

Minutes from virtual meeting

Summary (blog post)

NickTR: Thanks to Ian for fast minutes availability. AdrianHB, Ian and I worked on summary
... please have a look and share it if you think it's interesting
... focus at the end on next steps
...re: payment handlers, really great feedback on concrete proposals.
... we have started working through those with the chrome and mozilla teams
... and we'll get review for some of those from the W3C technical architecture group
... it would be great to get multiple implementations ... very very thankful for work by Google and Samsung!

IJ: We expect to have a comprehensive proposal regarding payment handler changes for discussion at the 30 April WPWG call.

NickTR: Regarding SRC we took a big step forward to walk through the architecture and flow diagrams. Thanks Mastercard!
... so the next step is to hear from the other networks that we are heading in the right direction

IJ: At the 29 April card payment security task force call we anticipate detailed feedback from Discover and American Express.

NickTR: Re open banking, momentum in Europe but also in other jurisdictions. Really great to hear about implementation experience from various API efforts in Europe, and harmonization efforts
... we really want to build some prototypes that put all the APIs together; that was one of the big ideas for the code-a-thon in dublin
... we'd still like to do something before TPAC (Oct) along those lines
... we are thinking hard about what a virtual code-a-thon
... On authentication, really encouraged by collaboration with FIDO and WebAuthn WG
... feels like if we could collectively push through we can really solve a problem
... need to figure out now how to connect the dots

(IJ: The WebAuthn joint task force is addressing those topics!)

NickTR: Regarding merchant feedback, good to hear use cases brought forth we've heard before (split tender, loyalty)...those are v2 features we've considered before
... we want to hear more from merchants

<Rolf> Not sure whether you have seen it: https://github.com/w3c/webauthn/issues/1396 (ongoing work regarding transaction confirmation support in Web Browsers).

Ian: See also Proposal from Adrian HB related to transaction confirmation.

NickTR: Thanks again to everyone who participated; certainly one of the most productive remote meetings I've been involved with. Great hard work and concentration.

Ian: Any other feedback from participants?
... thanks to people who answered the feedback survey

Objectives review

2019 work plan and April 2020 update

<nicktr> Ian: recaps action plan update

[IJ walks through the update]

AdrianHB: For a long time we've sought to make the APIs accommodate what exists in the ecosystem.
... with the advance of WebAuthn and mobile devices, payment systems are starting to adapt instead to users
... perhaps there's an opportunity for us to define a generic payment consent flow and model that isn't designed for any particular network, but
... has all the properties needed by a payment system to get consent, authorization, etc. in digital channels
... I think that might be more effective than creating opaque communication channels between origins via the broswer
... we might want something that allows the merchant to request a payment, and the merchant gets back info that proves the user approved payment of a certain amount from a specific account.
... and the standardized blob could be used by a variety of payment systems.

NickTR: I think we'd need to go from both ends -- existing paradigms and also building from the other end as well

AdrianHB: +1...both sides together

<jv> +1 new thing for authentication which is payment instrument agnostic

danyao: Our experience as browser vendors -- it's been challenging to build all the UI features. Solicitation of help: as a working group we have three stakeholders: browsers, PSPs, payment solution providers
... and we have merchants
... we have talked a lot about technical implementation; we are interested in how to support PSPs to drive the next features for merchants.
... would like to build a tiered solution: PSPs build solutions for merchants; browsers build for PSPs

NickTR: Some challenge there re: competitive landscape among PSPs

[IJ hopes we can return to objectives next meeting as well!]

Participation in task forces

[NickTR mentions our task forces for card payment security, payment handlers, webauthn. For schedules, see the meetings page.]

Chrome SameSite changes and payments

[Chrome presentation on SameSite changes] (PDF version)

Marshall: Thanks for having us. We want to review SameSite changes that we announced in May 2019 (at Google I/O) and published some outreach articles
... rolled out in Chrome 80 (Feb 2020)
... we did a roll-out over the past few months, but then rolled back a few weeks ago (due to COVID)
... goal is to bring more transparency, choice, and control around 3p cookies
... there's a change in labeling requirements for cookies used in 3p context, and how browsers will treat unlabeled cookies
... this should also help prevent some cross-site attacks.
... we rolled back due to impact we saw in some areas, one of them being 3-D Secure.
... we've done some investigation based on sites we saw that were impacted, and proposed some ways for 3DS users to address the issues
... we'd like to run through a presentation of these recommendations and get your feedback.
... we want to firm up the recommendations based on your feedback, and would like to continue to communicate as we re-ramp these up perhaps mid-year
... and we'd like your help propagating the good practice through payment industry channels

Rowan: Some definitions (same-site request relates to request matching what user sees in URL bar)
... same cookie can be either 1p or 3p depending on its context
... SameSite controls inclusion of cookie on same-site or cross-site requests
... three values of SameSite: Strict, Lax, None
..Strict: ONLY included in same site requests
...Lax: Included in same site requests and a few safe top level navigations
...None: Cookie included in all requests, including cross-site
... the proposed change involves when the request has no SameSite label: "Lax" becomes the new default.

[Now on to impact on 3DS flows]

Rowan: impact relates to how returning POST request happens
... flow diagram shows the issue
... user is redirected to issuer site which might involved password or SMS; at the end of that a POST request is triggered back to the merchant site with status info
... because that is counted as a cross-site request; does not include 1p cookies
... some things we've seen:

* Transaction appears successful!

* but user may see error in iframe after verification

* Or user may be signed out as the site has no cookies on the clalback

Rowan: Abstraction is "some 3p doing something on behalf of 1p and returning to 1p via POST request". I expect there will be other scenarios than 3DS that look like this
... to mitigate this, we have some suggestions

1) Don't rely on cookies in callback post
...They should not initialize session on callback route
... for iframe implementations postmessage() can be used ot send the verification result to the top-level window
... to display cookie-dependent content as a result, use the POST/Redirect/GET pattern to process the POST request without cookies, then issue an internal GET redirect that will include cookies

Rowan: 2) Another fix (not great but exists) is to create some short-lived, cross-site cookies for the POST
... e.g., cookies that has 15-minute life. Set with sameSite=none; that cookie will be included in POST....and can be used to reinitialize session
... ideally make these cookies single use
... 3) It may be tempting to mark all cookies for cross-site usage, but please don't do this
... this looses all the cross-site RF protection and introduces additional compatibility issues with older browsers

Rowan: We welcome your feedback on our Initial 3DS guidance materials. We would love your feedback on whether this matches issues you saw when this was activated.
... and does this advice work for you?
... do you foresee implementation issues?
... any other areas that might be similarly affected?

NickTR: There are some PSPs on the call.

jv: Thanks for the presentation. Can we send this deck to third parties?
... how would you like feedback?

Rowan: Fine to share the presentation. Can also send to Github repo. I plan to make this available as a blog post as well
... can create an issue on GitHub as a way of providing feedback

<Zakim> AdrianHB, you wanted to ask if switching to GET and URL params would also work (similar to OAuth2 flows)

AdrianHB: Thanks for the presentation. I have a general question around the callback. Is there a reason why 3DS does a POST back rather than a redirect with a GET and pass a session token, the way OAuth does it
... can anybody speak to whether that is intentional?

Rowan: I don't know if it's necessary for it to be a POST request (I am not as familiar with the protocol). But I think POST is preferable because you don't want the data cached or logged or repeatable.
... I also think from an architectural point of view, this is probably not a request that a site should be relying on for 1p cookies. It would be better to treat this as an uncredentialed request

AdrianHB: The short-lived cookie approach reminded me a lot of how OAuth does things with URL params

Rowan: Another issue that was raised was that some 3DS implementations allow you to pass merchant data with this. E.g., transaction id....and that might be echoed back on returning post and that might be usable to link sessions

mhofman: I'm not super familiar with 3DS, but I think that POST is part of the 3DS protocol itself
... and so you're not going to get ACS's to change to a GET for that

Rowan: One thing that is tricky is that there is no issue with the 3DS protocol itself. It's just an assumption of merchant sites that they will have their 1p cookies available on the return request, even though generally not required for processing the return request
... so it's not a 3DS spec issue, it's an implementation issue

Chris: I was about to confirm it's an implementation issue
... they should not depend on browser sending them a cookie when the POST comes back from the ACS
... thanks for the presentation

Rowan: Feedback welcome on how to clear up the framing and who needs to make changes.

NickTR: Thanks Google folks for speaking with us today!

Next call 30 April

30 April!


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/04/17 12:58:42 $