[Danyao walks us through Update from Chrome Team about proposals reviewed by WPWG at virtual emeting]
Danyo: We intend to follow the
spec (gesture required) but we plan to grandfather some origins
while we find solutions and move eventually everyone to the new
path
... please let us know if you are relying on this behavior so
we can take the legacy behavior into account
...Regarding mitigating
zero-click tracking, we are working on design to raise
awareness and will come back to the WG. We have added some
language to privacy/security considerations
[Regarding cross-origin switch awareness]
Danyao: We didn't hear
objections, though we know people don't want to add
friction
... we've updated the PR API privacy and security section, and
are also iterating within Chrome on proposals for how to signal
to user cross-origin switch
... will keep WG apprised of new ideas
[3p context by default for payment handlers]
Danyao: We heard lots of feedback
that 1p access is important for login persistence and using
webauthn.
... the problem boils down to how to make it easy to let users
give trusted payment handlers 1p access
... the default 3p context proposal thus depends in part on how to
grant 1p access
... people expressed concerns about explicit enrollment
phase
... because we are going to move ahead with user gesture
requirement, that should close some gaps around zero-click
tracking
... we think that visible UI will deter (but not fully solve)
zero-click tracking
... we are deprecating "*" in payment method manifest spec,
which will reduce risk surface
... in practice "*" is not being used, and and it creates
threats, so we are removing it for now
... Biggest use case for 1p access is login. We are actively
investigating login friction that does not rely on storage the
same way
...please add use cases
relying on 1p to issue
370
<Zakim> AdrianHB, you wanted to ask how URL based PMIs now differ from others
AdrianHB: Given that we are removing "*", how does one get a federated payment method that is URL-based?
Danyao: Today there is no
significant difference between the two types of payment method
identifiers
... however, in terms of installation, JIT is not supported for
standard PMIs (since no manifest)
... Skip the sheet is supported in general.
... the part that we consider a bug is: when you visit a
website and they install a payment handler with a short string
payment method without the user noticing it. This opens a
distribution vector for bad payment handlers
... so we are discussing how to close the gap there
Ian: The topic of
login persistence came up in the card security tf
...web-wide solutions
welcome but to the extent that PH are "special" because the
user is known to be in a special context there may be a payment
specific solution
...i like the framing
of "make it easy to login" not "hard to logout"
...there was
discussion around using Cred Man API
AdrianHB: I have explored
Credential Management API
... I think we can combine that API with "you are in a payment
handler" for special powers
... we could say that if the user has provided that credential
in a PH before, and they give permission, don't prompt them
again. So we can persist the login across payment contexts. Also, worth
exploring if the cred man API could be used with federated
credential where IdP is Payment Handler
Danyao: Our preference is general solutions where possible, and PH-specific solutions where we cannot
<scribe> ACTION: Danyao to add the principle of "general then specific solutions" to privacy threat model
[Regarding explicit install]
Danyao: We wanted to increase
awareness of installation but heard a lot of pushback to adding
friction
... especially there's disagreement about whether installation
should happen when the user is visiting a 1p context
... or if installation should happen mid-payment (since context
clearer)...but also more friction
... ...we are taking into the feedback and will bring back new
ideas. But no timeline yet for explicit installs
... The second proposal involved payment handler vetting (e.g.,
registry)
... or per-browser whitelist
... we heard some supportive feedback from the community about
vetting...the cost of one-time setup is low and creates barrier
for malicious payment handlers
... but we chatted subsequently with other browser vendors and
heard that registry management is challenging. And the FIDO
folks shared that registry management is challenging
... at this time we are not dismissing that idea, but need to
do more research
<nicktr> There's no question that managing a registry is a step into a certification regime which is something that W3C is not set up to do
<AdrianHB> +1 that this would be very hard to do, especially given localization
[Regarding hasEnrolledInstrument]
Danyao: one way to reduce threat
surface is to limit storage access before the user has
interacted with the PH
...after investigating
internally, because PH's make use of service workers, it will
be difficult (technically) before show, and because it may also
be performing other SW functionality. So we are dropping this
proposal for now.
... The next question was whether we could remove
hasEnrolledInstrument completely.
... we heard feedback from the meeting that this is an
important feature
<AdrianHB> +1 to drop hasEnrolledInstrument. Can we define the reasons it is required so we can explore options
Danyao: in Chrome we are still
exploring alternatives to this method, perhaps replacing it
with something better.
... one way to replace it is to think about the two main use
cases:
a) merchant wants to know if low-friction flow is possible for this user
b) payment handlers want to be asked before a transaction happens who the calling origin is (e.g., to determine whether merchant is registered with the payment handler provider)
Danyao: so one way of thinking is
to replace hasEnrolledInstruments with two different solutions,
as the technical requirements are different
... so for example, for (a) the answer might be cached and
answered by the browser without the browser having to reach out
to the payment handler during transaction time.
Ian: +1 to exploring that path!
Danyao: And the payment handler
can update the browser asynchronously via the service
worker.
... For the second use case, no user information is required
for the payment handler to know who the calling origin is. So
we could inform the payment handler about the merchant without
providing info about the user. Since we have a merchant
validation event, we are exploring whether we could use it
(although heavier than some needs require)
AdrianHB: I wanted to mention
with regards to explicit install: Coil is experimenting with
explicit install and the kinds of things to present to the
user.
... drive by installation in a 1p context is weird...if you
don't know you have the handler until you check out
... while I understand that explicit install raises friction
concerns, I think it's useful friction. It makes the whole
thing make more sense and will relieve security concerns
... I think there's a lot to explore there; I would not write
off explicit install
Ian: the SRC
implementations involve SRCi that is embedded in merchant
pages. You click to pay (and see no origin) but you immediately
see your cards
...I think seeing the
origin of the entity showing you your cards is useful (i.e. in
PH window)
... Explicit installs
feels like a better UX since it implies revocation etc are
available
...It builds trust
and seems like the privacy and security problems are only going
to get harder without explicit install
Danyao: We also want to harmonize
payment handler installations with Progressive Web App
installation event
...when you install a PWA it
adds an icon to home screen
...we are thinking that
payment handler installation is not very different
... so maybe easier for users and developers are more of the
same concept than if two separate installations
<AdrianHB> +1 to harmonizing PWA and Payment Handler (we already use the PWA manifest for branding...)
<Zakim> AdrianHB, you wanted to talk about experiments with explicit install timing
Danyao: Two other small proposals were floated:
1) Separate canMakepyament and
hasEnrolledInstrument. As long as we keep them,
we are going to clean up the naming
... we'll proceed with that
2) Last week we discussed skip-the-sheet behavior related to delegation; didn't hear objections so we're going to keep the behavior we've currently got
Danyao: Please review the update and proposals ... we are very open to feedback and want to hear from you!
AdrianHB: Proposed 26-28 May.
<AdrianHB> ian: are there any big conflicts with the dates?
<AdrianHB> ... for some people they had availability for Dublin but are now busy
<AdrianHB> ... we may not get everyone at any time so we're going ahead with those unless we have a showstopper
<AdrianHB> ... plan is to have some synchronous sessions (like this) starting with some into and lightning talks
<AdrianHB> ... also some tooling in development fo people to use
<AdrianHB> ... every 24 hrs we'll reconvene to sync up
<AdrianHB> ... final session will be feedback and demos
<AdrianHB> ... does that structure seem useful? Are there other ideas?
<AdrianHB> ... ito actual topics, we've listed these in the wiki but please add others you'd like to see worked on
<nicktr> Topics https://github.com/w3c/webpayments/wiki/Code-A-Thon-2020#initial-topic-ideas-for-ideation
<AdrianHB> ... if there are people that you think will be interested please bring them to the meeting
AdrianHB: Two things....
... on tooling, I mentioned Coil is doing experimentation
... we have an open source wallet that can be used as a payment
handler
... our plan is to make that available to people so they can
fork it and create their own experimental merchant site and
payment handler
... we also have been chatting with Max from Google about
documentation, also with links to other demos
... we will clean up our code and share as quickly as possible
before the code-a-thon (so people can warm up)
IJ: can we share links sooner and get feedback?
AdrianHB: We can ping Max offline
about sharing the doc with the group in draft state
... The other comment I wanted to make about work we could do
at the code-a-thon: a Payment method shared by a number of
payment handlers. Things like SEPA credit
transfers
... payment methods where we think there will be lots of
payment handlers for a single payment method
... we'd like to see the real world UX issues that arise in
that case.
...Regarding mobile money;
met with GSMA who have simulators
... they have a well-defined OTT (over the top) API for 3rd
parties to initiate transactions from a mobile money
wallet
... they are interested in making simulators available to us
for experimentation
... we're going to work with them to get them more
involved.
IJ: Likely will be virtual only. We will take this up again at another meeting.
AdrianHB: Maybe if code-a-thon is successful we can foster larger scale coding activity. There's some IETF experience in that space
14 May