Re: Seeking Parters for CSR (Collaborative Seed Recovery) of Identities

>
> We are looking for an identity vendor, in particular an issuer of
> credentials, to come on board as a sustaining sponsor to join with digital
> assets and hardware companies that we already have working on the design.
> Our goal is to ensure that digital identity gets an equal voice in this
> architecture, allowing it to be even more helpful for our community as a
> whole.


Just curious, why would you need an identity issuer/vendor for
Collaborative Seed Recovery?  Is it to leverage KBA (Knowledge-Based
Authentication) for seed recovery, or is it for something else?

Thanks,
Harrison

On Mon, Sep 12, 2022 at 3:14 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> Blockchain Commons has recently begun work on a new architecture called
> Collaborative Seed Recovery, or CSR, intended to improve the resilience of
> cryptographic seeds used for digital assets and digital identity. We are
> actively working with multiple partners, ranging from wallet software
> developers, hardware manufacturers, and silicon chip designers, to release
> our first public implementations late this fall.
>
> The idea behind CSR is to make it easy to recover cryptographic seeds in
> an automated way. This is done primarily through Shamir’s Secret Sharing
> and our security-reviewed `bc-sskr` library.
>
> SSKR allows us to shard a secret in and then send shares to other parties,
> but our scenarios allow for many different scenarios ranging from simple "2
> of 3" quorum, to more complex scenarios with multiple sub-groups, such as
> "two of three of three 2 of 3s", which is useful for several anti-collusion
> scenarios (for some more detail see
> https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Sharing.md
> ).
>
> However, we want to go beyond solely specifying a cryptographic format for
> sharding (such as those used by some early social-key recovery systems that
> leverage friends and family members). Instead, with CSR we are focused on
> storing your shares in places that are more likely to be accessible for the
> long term because they are your trusted partners or are incentivized to
> properly be a steward for your shares.
>
> For instead, one share might thus be stored in the cloud platform of the
> device you’re using, and the other shares are sent out, potentially to
> offline archives or friends or family, but most likely to “Share Servers”
> who exist primarily to store shares for you. We already have two wallet
> vendors committed to offering seed recovery services for each other's
> customers, and several others considering doing so.
>
> Given this is an ecosystem design, our requirements must also include
> things like defining APIs to re-establish secure authentication between
> parties after a major failure, not a common design requirement elsewhere.
> Other challenges are securely storing additional recovery metadata, such as
> VCs, NFTs, descriptors, etc., as well as future-proofing for emerging
> technologies like musig, FROST, and new zk technologies that allow
> for distributed key generation & management.
>
> We’ve written a document that includes more details on CSR 1.0:
> https://github.com/BlockchainCommons/Gordian/blob/master/Docs/CSR.md
>
> We also have some video archives of our recent CSR-related presentations
> and meetings in a YouTube playlist at
> https://www.youtube.com/playlist?list=PLCkrqxOY1Fbp-P1Yv-7gmu75i2QS2Z6vk
>
> We are looking for an identity vendor, in particular an issuer of
> credentials, to come on board as a sustaining sponsor to join with digital
> assets and hardware companies that we already have working on the design.
> Our goal is to ensure that digital identity gets an equal voice in this
> architecture, allowing it to be even more helpful for our community as a
> whole.
>
> If you’re interested in more information, or if you’re already ready to
> join up and take part in our bi-weekly calls developing this architecture
> (to restart after RWOT11), please chat me up at RWOT11 in the Hague, or
> send me an email.
>
>
> -- Christopher Allen
>
>