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

Hi Chris,

Really appreciate you sharing this—I've spent time going through the
Blockchain Commons stack, and it's clear you've done deep work here.

What stands out to me is how your layers map to different failure
scenarios. SSKR/CSR address the "I lost my shards" problem cleanly, but CKM
with FROST goes a step further by eliminating the reassembly attack surface
entirely. That's a meaningful advancement for cases where Shamir's
momentary key reconstruction is a real risk. Your work doesn't just
complement what we're discussing—it pushes it forward,  We're aligned on
the problem space and the direction.

We'd definitely want to build on existing work rather than reinvent, and
having your feedback and input along the way would be genuinely helpful.
Your team's experience here is exactly the kind of practical grounding this
effort needs.

Thanks again for sharing this. Good to know there's running code behind the
concepts.

Cheers,

Amir

On Thu, 19 Mar 2026 at 11:06, Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> 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
>
>>