Since addresses are not stored on MWEB outputs, identifying coins belonging to a wallet is no longer as simple as sharing a bloom filter with a full node, and letting them check for outputs that probabilistically belong to the wallet.
There are 2 ways that existing light clients identify coins belonging to a wallet:
BIP37 - Bloom Filters: Light wallets build a bloom filter for a list of addresses belonging to them, and share it with a full node. That full node then does the work of checking for outputs that probabilistically belong to the wallet.
Since addresses are not stored on MWEB outputs, we cannot identify a wallet's transactions using server-side filtering through probabilistic data structures like bloom filters. The only server-side filtering currently supported for MWEB is filtering using knowledge of private view keys. Light wallets would share their private view keys with a full node, which would then churn through all outputs to find any belonging to the wallet. Unfortunately, this is not a probabilistic process, so full nodes will know with 100% certainty outputs belong to the wallet. To make matters worse, the node will also learn the value of the wallet's outputs. This method is ideal for those who want to use MWEB from a mobile wallet connected to their own full node on a desktop or server, but due to the weakened privacy, you should avoid using this method when connected to untrusted nodes.
BIP157 - Client Side Block Filtering: The reverse, where full nodes build a compact filter for each block, and light wallets use those filters to identify blocks that may contain the wallet's transactions.
For those who don't have a trusted full node to connect to, we could use something similar to client side block filtering. More precisely, we could perform client side output filtering. Though no method has yet been designed for building filters as compact as those defined in BIP158 - Compact Block Filters for Light Clients, nodes can provide light clients with compact MWEB outputs, allowing them to avoid downloading the large rangeproofs associated to each output. In fact, we can be even more data efficient, and download only outputs that are verifiably unspent. Following the process defined in LIP-0006, light clients can download and check all UTXOs from multiple nodes in parallel, avoiding the privacy and verifiability shortcomings of the server-side filtering approaches.