Re: [w3c/payment-handler] What happens when clearing site data? (#236)

@jakearchibald wrote: 

> If PaymentInstruments is a persistent store, associated with the origin, that the origin can freely read/write to, surely it must be cleared along with other origin storage. Otherwise, you've just created a clear-site-data workaround.

Pretty much, but it would be inaccessible without again getting permission to access it. Let's put that aside tho - I'm not advocating for this, just trying to rationalize the model. 

> *A general payment method owned by the user.* 

I been struggling with this also over last few days. This would only work for "credit cards" and their ilk, so I don't think this works as we add new payment methods and "exotic" new instruments that are likely tied to a payment handler. 

> *A payment method owned by the user, recorded by the origin.* 

This is how I've been viewing it and what brought me here. This feels like the most natural fit to me... but...  

> *A payment method owned by the user, recorded by the payment handler.*

This is close. What I want is to have the Instrument Store owned by the user, accessed by the origin, but have a service worker registration to handle events. 

I see this very much like the Cache API: 

I can CRUD things in the Cache(s) from the Window object same origin. I can CRUD things from the Cache(s) from the Service Worker(s). And I can have the Service Worker(s) handle "fetch" events. Caches are cleared with site data.

Thus, I want `InstrumentStore` to fit this story:
I can CRUD things in the `InstrumentStore` from the Window object same origin. I can CRUD things from the IntrumentsStore from the Service Worker(s). And I can have the Service Worker(s) handle "paymentrequest" events - but these requests come from same origin or foreign origins. `InstrumentStore`  is cleared with site data.




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/236#issuecomment-349540206