The problem for the sponsor (A in your example) is the bounty-reward problem:
If Alice is due to collect an on-chain bounty upon the successful execution of a transaction, then generally speaking there is always a risk that her transactions fails because the bounty was already claimed.
The classic example is that Bob simply spends the ERC20 tokens while Alice’s sponsored transaction is in-flight. Unless you have a special contract set up, then generally speaking, Alice will just waste some gas. Several wallets already offer DAI payment as a feature (Argent) and so far they just absorb the risk/cost of it.
For the use cases. It really depends on:
Payment mechanism. How is the sponsor being paid for sending the sponsees transaction?
On-chain authentication. How is the sponsee authenticating with the target contract?
I should stress that both payment and on-chain authentication are separate problems. The EIP is only focusing on on-chain authentication.
For a full picture, the payment mechanism can be pre-payment (ITX) or the bounty approach (on-chain refund).
How prepayment and receiving job may work.
Figure 1: Overview of Gas Tanks for ITX
In Figure 1, we only consider the pre-payment approach and we assume the clients have a pre-paid gas tank with ITX. They may have paid in ETH or FIAT, but in the end they will have an ETH-denominated gas tank with the service.
The client can simply send a signed transaction to the API:
}, <signature here>
ITX takes the “to”, “data”, packs it into an Ethereum Transaction and then sends it to the network for them.
The next problem, which is really the focus of EIP-3074, is how the user authenticates with the target contract that will be executed:
Modified target contract. It authenticates the user with a signed message instead of msg.sender.
Wallet contract. An intermediary contract holds the user’s funds and verifies their signed message. It then .calls() in the target contract and acts as their identity on the network.
The former approach is pretty janky as it doesn’t work with most ERC20 tokens or most contracts for that matter. There is some work towards standards such as EIP-2771, EIP-2612 and EIP-3009 standards, but they all fall short due to lack of adoption.
As a result, most services need to deploy wallet contracts. An example of how to execute (and the refund via bounty) can be seen with Gnosis Safe, but asking users to both deploy expensive wallet contracts and move all their assets to it… is typically a blocker to adoption.
I hope the above example helped. Sorry, it was the quickest thing I could think to put together and I hope it isn’t too long!