The challenge of safely securing a seed for a single signature is not insignificant. Blockchain Commons has published procedures that we consider the current best practices for cold storage in a free book at http://bit.ly/SmartCustodyBookV101 and in github at https://github.com/BlockchainCommons/smartcustodybook. It currently requires a couple of hours and $200 or more of materials (home safe, 2 ledgers, titanium blanks, etc.) to safely product (significantly less time and money than Glacier Protocol). 

Presumably, people are not going to go to this level of protection for too many keys, thus there needs to be methods to leverage the root seeds that are properly protected.

Currently Blockchain Commons is working on standards for airgap solutions for storing and signing from offline keys. Scenarios include using Shamir and SLIP-39  on an offline device with no-WiFi or Bluetooth, an air-gapped mobile phone in airplane mode, or another dedicated device (for instance the SafeKey device if open source was an option). You would use this device to create and restore seeds, convert seeds from BIP-39 to SLIP-39, derive HD keys, and then use QR code from the device to transfer the generated child keys for use by different apps. In some cases, this offline device could also read QR transactions and sign them. We have working prototypes of this today.

This technique works fine for online Bitcoin apps that accept child keys in the form of xprv (or equivalents) such as those our FullyNoded2 iOS wallet supports, but the problem for other wallets is that you can't go from an xprv back to a seed — the xprv creation is a one-way hmac-sha512 operation (still not convinced this was a good decision). 

What I think Ethan is proposing is the ability to turn any child derived xprv key into a new set valid seed words that could be used by a wallet or other devices that don't understand xprv and will only allow import of new seeds words. This gets even more complicated if the seed words are not the standard BIP-39 set (which BTW, are not an ideal set of words, the selection of the SLIP-39 words is much better). 

Though possibly pragmatic, this approach would be a hack – starting with some raw entropy, convert this to an entropy seed, then to words, then hmac to xprv, then derive child keys, then convert that child key to a new entropy seed, then hmac to xprv, and then derive child keys again, etc.

I'd really prefer to start with finding standards ways to protect the entropy seed (not specifically the bip39 words derived from that but also as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) that can be then be used to create other hierarchies of keys using airgap solutions.

For instance, here is what FullyNoded 2 currently uses to restore a Bitcoin wallet including root seed:

{
  "birthdate": 1584725088,
  "label": "Testnet Single Signature",
  "entropy": "b3b17e8f425bf7b96d68b67867cdc816",
  "walletName": "DEFAULT_EBaiuGgZQS_StandUp",
  "descriptor": "wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PNZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sYiGSf6hcujv/0/*)",
  "blockheight": 1
}

Alternatively, FullyNoded 2 can also restore a wallets without the full seed, so for instance, if this QR restore was missing the entropy field, only derived child xprv from the descriptor could be used, so no other accounts could be created but new addresses as children of the xprv could be created.

The advantage of of an entropy seed storage centered technique is that I can convert that entropy seed into either BIP39 words, or any number of SLIP-39 shards, or Lightning words, and back. We are also looking at using this with the VSS that underlies Schnorr Musig. We can talk other secure tool makers on how to use this raw entropy for other purposes to create chains or hierarchies of keys for their unique needs.

Blockchain Common's doesn't have a full architecture for this yet as we are working on our POC and are seeking suggestions from other wallet vendors (in particular lightning and non-bitcoin secure services) on requirements. Let me know if you'd like to participate in the discussions (currently either Github issues or a Signal group for the group)

— Christopher Allen