https://github.com/w3c/payment-handler/issues/236
Rouslan: I think people are
wondering whether we need to link service workers and payment
handlers closely
... people have said "you need to fire your event somewhere,
needs to be a service worker"
IJ: What about separating data from event management?
Rouslan: Question is whether
clearing site data should clear payment instrument data.
... clearing site data clears service workers as well.
... so if user clears site data, that removes payment handlers
as well.
Ian: Could you make payment-related information in prefs to not clear payment info?
Rouslan: Whatever clears service workers will clear payment info
IJ: Does it make sense to keep
payment info around even with no service worker?
... [IJ reasons out loud it does not]
... Seems good for privacy, but how often do people clear their
browsers?
alyver: Do we have any stats?
rouslan: I can try to look for that info
alyver: I think people do it
frequently enough that it might be a problem for payment
handlers
... though I do agree with Ian that clearing the SW is the
right thing to do when clearing the data so others cannot use
your payment information
IJ: Could also contemplate just-in-time reregistration to make that easy, but still breaks the user privacy expectation
Adrian wrote: "So when the user re-installs the handler I'd expect it to be pretty trivial for the provider to also re-add the instruments."
IJ: SW also seems like an
implementation detail. "Clear means clear."
... we don't yet know whether users will want to say "Clear a
lot of data but keep my payment info"
... autofill is separable however today
alyver: Some browsers have checkboxes for categories you can uncheck
Ian: Pain to lose lots of shipping addresses.
IJ: Where do shipping addresses go?
Rouslan: Autofill data
IJ: Maybe say "Autofill and
stored payment data"
... Let's let the thread for 236 do its thing
https://github.com/w3c/payment-handler/issues/239
IJ: Any comments on the proposal so far?
Rouslan: Note that some parties (e.g., branded buttons) can include service worker code in an iframe
<AdrianHB> There are many use cases that we need to accommodate. I think doing consent at time of payment but allowing it to be given explicitly at time of registration (with guidance from publisher) is a good framework to start with. We can always build on that
ok
what do we need to say in the spec?
Rouslan: I want to ask other implementers who plan to implement whether they want to do time of payment or time of registration consent.
<AdrianHB> Not sure how you spec the "diamond in the address bar thing"
Rouslan: if they want to do time
of payment, then the "request permission" part of the API may
not be useful.
... so one change to the spec might be removing the permission
bits
IJ: does it make sense to write the spec in terms of permission prior to the first usage?
Rouslan: The same JS API would not be useful at time of payment
https://w3c.github.io/payment-handler/#requestpermission-method
scribe: doesn't work at time of payment since the user is on the merchant site not the payment handler site
IJ: Where does .requestPermission go at time of payment?
Rouslan: My proposal is not to do it that way. The service worker does not get permission until the user agent presents the service worker URL to the user and the user has to give consent first.
[Discussion of whether .requestPermission() is even necessary]
IJ: Does the site need to know whether permission was given?
Rouslan: I agree having UI on the
bank site saying "You've installed your app" is useful
... I think banks want to know that their app has been
registered.
... I think we should change this to something a bit different
that would satisfy more use cases.
... we should let the web site set payment instruments even if
the user agent returns some state saying "not known"
... so allow site to set up instruments.
... if the site wants to know whether the user has granted
permission, the user agent returns the current state (e.g.,
allow, block, or ignore for now)
Ian: So something like requestPermissionState()
alyver: I anticipate some opposition to installing instruments
IJ: Why, what's the danger of having that data around?
alyver: What if you are on a public computer?
rouslan_: If you are on a public computer, you would clear your browser session before you are done.
IJ: I agree we need to think through the security implications of the public usage
Rouslan: Agreed, we need to think about that one.
Summary:
* User consent is required before first usage
* Revisit spec in terms of payment handler being able to query current permission state
* When permission granted may vary (e.g., dismissible prompt but no later than first usage)
* Security issue of silent registration of instruments, e.g., in public computer use case
<scribe> ACTION: Rouslan to mention summary in GitHub thread
<trackbot> Sorry, but no Tracker is associated with this channel.
18 December
{No meeting 11 Dec}
<alyver> +1
<anthonyvd> +1