I meant to say that when you receive the asset you receive all its past historic data, like today I think. You'd receive the whole thing unencrypted from the sender.
Then you'd encrypt it with a seed generated new key of yours and save everything back as a payload in the public DAG (forget about compression as this data probably shouldn't compress well anyway, addresses, signatures, etc.).
When it comes time to send these tokens to someone, your wallet would have retrieved it from the DAG, unencrypt it with you key (calculated from your seed), maybe save it in your local database (which now function as a local cache) as it does today, generate the new transaction and send it to the counterpart using the same mechanism as it does today. Then the process would repeat all over again by the new receiver.
Note that after each transaction reaches finality state, the payload of the previous transaction could somehow be pruned as not needed. As today any owner of a token could only access previous history of it and wouldn"t be allowed to see future transactions.
I see what you mean, the data to be stored would be huge (megabytes) in this case. The pruning part is not trivial too, because 3rd-party nodes don't know what data is already not needed.