[Ann shows demo}
anne: [showing enrollment]
<Ian> Demo with description
anne: user has an option to
install the payment app from bank website
... we rely on mobile auth to authn the user
... [shows checkout]
... we are showing minimal UI
... the PH allows the merchant to retrieve the card info and
then call the acceptance platform to finalize the payment
anne: the PH is al alternative to
forms which are used to capture card details
... we could also use the bank ACS to handle 3DS without
needing to do existing 3DS auth methods
... normally we use the directory server to get the issuer bank
URL but thanks to the payment handler we already know the
issuer
NickTR: Coult the same flow be used for a push payment (non-card)?
Anne: Yes
danyao: What payment method are you using?
anne: we should develop a standardised payment method?
tomasz: have you considered the case where the user has multiple cards? How would this work?
anne: in this demo we are using
minimal UI so there is no selector and we have used only one
card
... our previous demo which this is based on proposes a wallet
where you get a standard UI and when you choose the bank then
you get directed to the bank and choose a card
tomasz: in the past we looked at each card being a PH which means they can all be featured in the minimal UI
<Zakim> AdrianHB, you wanted to ask about instrument selection in minimal UI
<nicktr> scribenick: nicktr
AdrianHB: I think the Minimal UI
doesn't have an instrument selector
... is that on the roadmap?
Danyao: we are exploring it. It's
not on the roadmap currently
... do we need to have one handler per instrument it the
question?
Anne: On this demo, to be compliant with PSD2, we need to show two schemes and the choice between them (so here between CB and international scheme)
nicktr: perhaps we could solve this with user preferences
danyao: is that per transaction choice a regulatory requirement?
anne: I'm not sure
adrianHB: we could tackle it as separate instruments for the separate networks
tomasz: this ability to choose
between schemes is wider than just PSD2 - e.g. debit schemes in
the US
... perhaps we could use supported method as a mechanism for
handling this
danyao's document https://docs.google.com/document/d/1wetV2oVjYvBU-tD0nF_FiUsynXp17oXuvCm3O8Sv3y4/edit#heading=h.bat9awopsp53
<AdrianHB> danyao: want to give the group heads up and get input before browsers start privacy interventions
<AdrianHB> ... but we don't want to break the web so we want to get a better understanding of how payment flows are implemented
<scribe> scribenick: AdrianHB
UNKNOWN_SPEAKER: the goal of the
doc is to enumerate the apis and capabilites used by payment
flows so we can understand the dependencies
... the WG is very knowledgeable on this topic and we are
looking for input on the document (currently a WIP)
... truth is that we don't know exactly what the changes are
that are coming because we're still trying to understand the
impact
... we want to avoid rolling out changes and then having to
roll them back (e.g. 3P cookies SameSite)
... 3P cookies will be gone by 2021 so we need to find
alternatives and work-arounds before then
... Storage Access API is proposed to enforce storage
restrictions. Chrome also exploring partitioned storage
<nicktr> Apple's Safari Storage Access API proposal https://webkit.org/blog/8124/introducing-storage-access-api/
UNKNOWN_SPEAKER: not sure prompts
are the best solution
... fingerprinting will also be restricted (e.g. properties
like screen depth are supposed to be used for developing great
UX but are used to fingerprint users)
... cross-site post message - allows pages to communicate via
messages
... concern is that it is used to communicate silently when the
two sites are different origins
... final mitigation is link decorations. Expectation is that
sites will load an iframe with info in URL params as a way to
pass data to 3P
... actively studying how we can differentiate legit use cases
from trackers etc
... please provide info on any legit use cases you have to help
us with our research
<clinton> +q
mhofman: first I've heard of the corr-site postmessage and link decoration considerations. I think this would break a lot of sites. Where is this being discussed
danyao: it's early so we're still just gathering data
mhofman: Stripe elements is entirely built on this (post message)
danyao: popups?
mhofman: no, those are samesite as far as I know. Need to think about it
clinton: in the Card Payment Security TF we're looking at SRC and would like to apply this analysis there as well
tomasz: card industry are heavily
leveraging these features for SRC
... I am sympathetic to the privacy issue but we need to also
be pragmatic
... I understand that this is an effort from Chrome but how can
we engage with other browsers?
danyao: marcos is a good contact
for Mozilla
... if we put this document together then we can use it as a
basis for discussion with other browsers
tomasz: the changes will not only affect the payments industry, they affect merchants. They introduce friction which increases abandonment
danyao: the rest of the document
is an inventory of the flows
... I want to be specific so that it is hard to dismiss them as
easy to work around
... so far we only have 3 flows
<clinton> +q
benoit: is it possible to share this document outside the WG?
danyao: feel free to share, but please be aware this is a discussion document for gathering feedback
clinton: if we're looking at
path's forward we should make a distinction between authN and
identification
... a lot of the cookies etc are used to identify the person
first
... authN is a subsequent step
mhofman: someone mentioned that the difficulty is not on the PSP. It's on the merchant. We need thousands of merchants to change their websites which is going to be very difficult.
danyao: would it be possible to push these changes via PSP SDKs?
<benoit> manifest hosted on a site that lists specific URLs to which something like postMessage() is allowed?
mhofman: not in this case.
danyao: if we can make the alternative lower fricition than the forms it seems likely that merchants will be compelled to move from something that uses cross-site postMessage anyway
mhofman: i agree that is possible
but that's not the case today. PR is only supported in
Chrome
... there will always be a long tail of merchants that will be
slow to change
danyao: maybe we need to start
with a blacklist for cross-site postmessage to start and only
deprecate after we are sure there are alts
... thanks for the feedback. we need to make the alts
materialize so the privacy work can progress
nicktr: our role is to have these discussions and share feedback, please let us know if you want to discuss this further
next meeting: 9 July