Great. It's good to know that there is a plan in place for this. I'm sure you have already thought through a lot of this, but I would like to throw in my two cents on how I would like to see this implemented.
What I am looking for is to have the option for something that goes beyond just a straightforward multisig. First, each registered account would publically register three public keys (PRIMARY_PUBLIC_KEY which I guess is equivalent to the Active Key in the current system, SECONDARY_PUBLIC_KEY, and TERTIARY_PUBLIC_KEY) and a MULTISIG_EXPIRATION_DELTA which specifies the time increment from the time of the transaction to the time when the transaction can be spent by just one of the keys. For privacy reasons users should not choose a rare MULTISIG_EXPIRATION_DELTA.
When a spender creates a transaction that sends money to a recipient, the spender takes OneTimePrivateKey and does elliptic curve point multiplication with PRIMARY_PUBLIC_KEY, SECONDARY_PUBLIC_KEY, and TERTIARY_PUBLIC_KEY, to get SECRET1, SECRET2, and SECRET3, respectively. Then, PRIMARY_PUBLIC_KEY.child(SECRET1) => PRIMARY_RECEIVE_PUBLIC_KEY, SECONDARY_PUBLIC_KEY.child(SECRET2) => SECONDARY_RECEIVE_PUBLIC_KEY, TERTIARY_PUBLIC_KEY.child(SECRET3) => TERTIARY_RECEIVE_PUBLIC_KEY. The corresponding receive addresses are added to the transaction for multisig purposes, along with MULTISIG_EXPIRATION_DELTA, and also two encrypted memos: PRIMARY_MEMO and TERTIARY_MEMO. PRIMARY_MEMO, which would be encrypted with SECRET1, would contain the same information currently put in the memo with TITAN. TERTIARY_MEMO (encrypted with SECRET3) would only contain information on which registered account was the intended recipient of the transaction.
Spending the transaction before (TIME_OF_TRANSACTION + MULTISIG_EXPIRATION_DELTA) would require a signature from either PRIMARY_RECEIVE_PRIVATE_KEY and SECONDARY_RECEIVE_PRIVATE_KEY or PRIMARY_RECEIVE_PRIVATE_KEY and TERTIARY_RECEIVE_PRIVATE_KEY. Spending the transaction after (TIME_OF_TRANSACTION + MULTISIG_EXPIRATION_DELTA) would require a signature from either PRIMARY_RECEIVE_PRIVATE_KEY or SECONDARY_RECEIVE_PRIVATE_KEY (but not TERTIARY_RECEIVE_PRIVATE_KEY).
Users would use their wallet root key to deterministically generate the primary key, randomly generate a secondary key and safely store it offline, assign TERTIARY_PUBLIC_KEY to the well known public key of a third-party validator, and set MULTISIG_EXPIRATION_DELTA to some reasonable value like 6 months. As long as they move their unspent transactions at least every 6 months (they already have to do it once a year anyway to avoid the inactivity fee), they get the security benefits described in my previous post. But there are additional benefits with this approach. The validator can also act as an observer for received funds. The validator would only have to scan the blockchain with just one key and then look in the tertiary memo to see which of their customers the funds belong to. They could then alert each customer with just the subset of relevant transaction for thin client wallet setups. The validators would not be able to see the primary memo field or who the money came from. They would only see the user's account balance as a function of time for the duration of time that the user had chosen that validator. If the user loses access to their wallet root key but is able to recover the offline SECONDARY_PRIVATE_KEY, they can still get access to all of their funds after at most 6 months; however, they won't be able to see their old transaction history. Also, if the user dies but had given a copy of SECONDARY_PRIVATE_KEY to their beneficiary, the beneficiary can claim the funds after at most 6 months after the benefactor's death. The beneficiary would of course not be able to claim the funds while the user was still alive and active.