I tried to generalize this question from one I asked on the BitcoinJ development list.
I'm working on a project that requires a centralized wallet. From what I gather, these types of services generally rely upon simple balance checks to ensure that an individual user doesn't spend more than is in their wallet. That is, all users share a pool of keys, and the only thing tracking each user's balance is the service's database.
The Bitcoin daemon exposes functionality not in the GUI, namely that of accounts. An account is a string that groups keys. You can send from an account, and it will only gather coins owned by the keys in that account. This is beneficial, but is fairly limited. Using this however, you could have each account be a unique identifier for a user, and then that user "owns" the associated keys. One seeming drawback to this is that there is one centralized location to change ownership of an account.
I came up with a potentially better solution. Each account "owns" one or more public key hashes (the meat of a Bitcoin address). When creating a transaction, the service will transmit these hashes, letting the wallet know that when scanning unspent outputs, only use those with a public key hash owned by the user. In this way, without associating a user account with the private key itself, we are able to allow the user to have exclusive access to any number of keys.
Does this seem like a good solution to the problem? Is there something better that I'm missing?