Re: [w3c/browser-payment-api] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#109)

> What's the purpose of this final step?

You cannot communicate so much when switching from the payment app context back to the merchant context, plus it might not be reliable.  It's safer to transfer tokens or whatever with separate API calls that do not exist before the user commits to a payment with that particular fulfillment page. 

These APIs are themselves a hacking vector, but they are not necessarily an issue for this spec.  And the payment app can more easily sandbox itself somewhat. 

> This proposal suggests that there is a need for the merchant and payment app to interact prior to the return of the response and that we should standardize a way for this to happen via a callback URL which the payment app uses to establish a back-channel session with the merchant.

Right, but what data does one actually need this step for?  Is the merchant no longer meant to obtain the shipping address earlier in the process or something? 

> This interface .. will be via HTTP calls so I'm not sure there is a risk of the payment app getting hacked if the merchant is hacked?

I think this assumes lots about the payment app.  

Just talking out my ass : If you've plugged this into a buggy BTC wallet with a bad PRF, then maybe an attacker could make you keep restarting a transaction until the PRF reuses a signature nonce, allowing them to drain your account on the blockchain.  No actual "hacking" there per se.  Just a bad PRF that's exposed enough to let the attacker determine when its state has wrapped.  It's happened before that nonces were reused purely by accident.  Those coins don't stick around long. 

---
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/browser-payment-api/issues/109#issuecomment-204388355