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
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!]
[NickTR mentions our task forces for card payment security, payment handlers, webauthn. For schedules, see the meetings page.]
[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!
30 April!
ADJOURNED