LIP-8 Recepient VASP can't send pre approval request to a sender VASP it is not aware of

In the recurring payments scenario recipient VASP (some merchant acquirer) should ask sending VASP (some consumer wallet) for a FundPullPreApprovalCommand (request for consumer consent for a recurring charge by the merchant). After such a request has been submitted the recipient VASP can now use "out-of-band methods" (Some interaction with the wallet user) to approve/reject the pull pre-approval request.

According to my understanding of the process, we may encounter a problem.
Let's say a merchant consumer wants to add Libra as a payment method (i.e to his favorite transportation app who wants to charge him for every trip).

The merchant app will ask it's Libra acquirer service to generate a request for a recurring charge consent. Problem is,
at that point in time nor the merchant or the acquirer can know who is the consumer VASP and who is the specific user (subaddress?) inside the VASP to whom the pre-approval request should be sent to.

Alternative flow might be:

1. Acquirer provides a QR/link at the checkout page with the scope of the consent request (amount, currency, etc...), the acquirer VASP address, and the merchant user id.
2. consumer scans the QR / opens the link with his Libra wallet.
3. The Libra consumer wallet asks for consumer consent (approve/reject).
4. Consumer wallet opens a channel to the requesting VASP (the merchant acquirer) and creates the FundPullPreApprovalObject with the consumer desition.

Thoughts?

Start with the issue's recurring-payments flow and the FundPullPreApprovalCommand and FundPullPreApprovalObject concepts. Compare the proposed QR/link flow with the documented protocol and determine whether the sender VASP and consumer can be identified and contacted. Done means the protocol has an agreed, documented flow for requesting and approving recurring-payment consent.

Written by the indexing model from the issue text.