Isn’t stoic just based on II? As long as you maintain control of your II you maintain control of any accounts created with that II. Or am I missing something here?
1 Like
Stoic also will also generate an random seed phrase for you; as an option; to open an wallet. If you use II as a basis, then with stoic you are good.
1 Like
Do you know by chance if there is any possible way to reach a Stoic wallet if the seed phrase is lost?
Not that I am aware off in context of a random seed phrase generated by stoic.
I am reviving this discussion based on the latest Identity & Authentication Working Group meeting.
There are two main options that have been discussed with respect to assisted recovery, one above here in the thread; the other one is a proposal that originates from Dom and has been discussed informally in several venues. For clarity, I’ll give a high-level description of both, compare some pros and cons, and then I hope for a lively discussion 
Threshold recovery
The account holder chooses a group of n friends and a threshold t ≤ n such that any t of the n friends together can gain access to the account, but any subgroup of f < t cannot. Initially, the account holder sends one key share to each of the n friends, which are trusted to keep their share both secret and available. When the account holder needs to regain access to the account, they need to contact at least t of their n friends for help.
There are a few variants in how exactly one implements the scheme, but the core idea is always to use a Shamir Secret Sharing for the threshold property, sending one share to each friend. In the recovery phase, one can then either have each friend send back the share they received and reconstruct the key locally (a bit easier) or actually generate a threshold signature (potentially a bit more secure).
Identity-based recovery
The account holder stores a digest (ensuring the information itself does not leak) of personal information that can be validated from the person’s legal documents with the identity anchor, probably including data such as name, DOB, citizenship, and so forth. When the account holder needs to regain access to the account, they contact one of several service providers which validate the person’s identity and – probably in exchange for some payment – help the person regaining access.
Several details still have to be fixed: How are the service providers chosen, are they appointed by the NNS? (There probably have to be different SPs for different regions.) Can the account holder choose which service providers they trust, can they specify some policy (“at least 2 out of the following have to confirm”, or “only SPs that are actually provide services in Europe”, or …)?
Comparison
Advantages of threshold recovery:
- Implementation in front-end only, no change to the backend required.
- Probably productive much quicker, since identity-based recovery requires an ecosystem with identity verification services to be set up.
Advantages of identity-based recovery:
- Easier to initially set up on the user side (simply enter some personal information compared to sending shares to a group of friends).
- Threshold recovery (at least when implemented in front-end only) requires users to manage key material; making it secure with a group of non-technical people and with acceptable security probably involves sending paper (with printed seed phrases or QR codes) around.
And now …
The two options aren’t exclusive, btw., so we may very well decide on building a threshold-based variant (especially if front-end only) now and build an identity-based version later.
5 Likes
I think the identity based version would be far more complicated to build, far harder to preserve the privacy of the individual, and just have many more practical challenges.
The threshold scheme is rather simple, and yes I think a hybrid solution would be possible very quickly. You could send a share to an identity verification service, and only when verified with the service (providing documents etc) would they provide their share. This would allow you to construct a group to your liking, composed of friends, family, and service providers.
1 Like
I would be happy with both options, but I would prefer the identity based recovery solution. I don’t really like the idea of having to rely on others to recover my internet identity. I would rather preload some secure service provider with personally identifiable information (maybe including info that can be verified by third parties) and then be able to recover based on my own initiative. I think this scales to the general public more effectively than social recovery. I suspect there would be a lot more resistance to social based threshold recovery.
1 Like
That is exactly how GitHub - icdev2dev/bachao: Social Recovery of Internet Identity works. I use it to send qr codes to friends and family around the globe. Any recovery mechanism(and process) must designed to last 20+ years (remember dfinity has a 20 year roadmap)
Some key issues with this:
(a) test the dr every year or so. I found that some friends lost their share…couldnt locate it
(b) be prepared for seed phrase rotation ( friends , relationships change)
The main issue with identity-based recovery is that you are trusting centralized third parties with your recovery.(what if they go bankrupt? What if they are acquired?..) Any solution must overcome this burden.
I’m not sure it needs to be done on paper or last 20+ years. I’m imagining you’ll do this with other people that have II/NFID accounts. All of it will be handled with good UX through the interface. Periodic attestations can be made from the clients, and if you see that any of your friends haven’t logged in for a long while, then you can reach out to them or perhaps increase your threshold. The n of m makes it more resilient to people losing their keys, as it’s probably unlikely that a group of active II users will all lose their keys at once.
1 Like
What i have today is not with II/NFID users (simple custodians of printed qr codes). Incidentally i use the same mechanism for ledger seed phrases.
The UX for OP(me) is terrible right now (though it is better (security wise) than engraving on a steel wallet). Agree that the UX could be a lot better with II/NFID