Re: [PROPOSAL]: Adopt DID-KR Key Recovery Extension as a CCG Work Item

One more resource worth flagging:

At Blockchain Commons, we've been building a layered stack for
cryptographic key and seed recovery that several wallet developers have
already adopted. I'll outline the layers from most mature to most
experimental:

**SSKR (Sharded Secret Key Reconstruction)** —
https://developer.blockchaincommons.com/sskr/ — This is Shamir Secret
Sharing, but with two layers. Instead of a single quorum, you can express
policies like "2 of 3 subgroups, each requiring 2 of 3 members" —
essentially a quorum of quorums. It's well-suited to multi-stakeholder
custody scenarios.

**CSR (Collaborative Seed Recovery)** —
https://developer.blockchaincommons.com/csr/ — CSR builds on SSKR to handle
not just the seed itself but all the metadata needed to actually recover a
wallet — output descriptors, multisig parameters, account derivation paths,
and so on.

Both SSKR and CSR are production-mature and have had security reviews.

**ZeWIF** — https://developer.blockchaincommons.com/chains/zcash/zewif/ —
Above CSR, we've been working on full wallet interoperability formats.
ZeWIF, developed with the Zcash community, encrypts the entire wallet state
— private transaction history, notes, metadata — not just the seed. Two
other blockchain projects have reached out to adopt the same model. More
background: https://www.blockchaincommons.com/musings/musings-interop/

**CKM (Collaborative Key Management)** —
https://developer.blockchaincommons.com/ckm/ — This is our most
experimental layer, and the most relevant to the DID recovery problem at
its hardest. CKM uses MPC threshold signatures (specifically FROST —
https://developer.blockchaincommons.com/frost/) so that a complete private
key never exists on any single machine. This is a meaningful improvement
over Shamir-based approaches, where reassembling shards creates a momentary
but real attack surface.

We have working CKM proof-of-concepts, including one that does FROST-based
Bitcoin multisig with no direct peer-to-peer communication between parties
— not even over Tor. Coordination happens entirely via a dead-drop model
using BitTorrent Mainline DHT and/or IPFS. The FROST libraries underpinning
this (from the Zcash ecosystem) have been independently reviewed.

Finally, if the group is still working through the conceptual framing of
key recovery — not just the mechanisms but the threat models, adversary
analyses, and custody design principles — our #SmartCustody project may be
useful background: https://www.smartcustody.com

It includes a free book covering risk modeling, adversary scenarios, and
digital custodianship responsibilities, as well as standalone articles on
SSKR sharing schemes, multisig design, and the dangers of secret-sharing.
It's written with both practitioners and standards authors in mind.

Happy to share more detail on any of these if helpful.

-- Christopher Allen

>