Guardian scheme for account recovery

[s8sato]

The risk of key loss can be mitigated by using a social-recovery pattern commonly called a guardian scheme. In Iroha, a guardian scheme can be implemented as library triggers. However, it requires finer-grained access control over metadata.

Implementation Overview

This involves two accounts and two triggers:

• Alice: the user who lost their private key
• Guardian: a trusted friend (ideally a multisig account) pre-authorized to schedule Alice's account migration
• Reception desk: a data trigger that accepts account-migration requests
• Migrator: a time trigger that executes the account migration

1. Alice grants the Guardian write permission on the Reception desk's metadata entry (Alice, *).
2. Alice loses her private key.
3. Off-chain, Alice informs the Guardian of her new public key NewAlice.
4. The Guardian writes (Alice, NewAlice) into the Reception desk metadata.
5. The Reception desk detects this and writes (Alice, NewAlice, migrate_at) for the Migrator—where migrate_at is a future timestamp.
6. A notification about the scheduled account migration is sent to Alice.
7. If Alice did not intend this (e.g. malicious Guardian action), she can cancel the reservation by deleting the corresponding metadata entry.
8. When the Migrator's periodic check runs, if the metadata entry is still present and valid, Alice's identity in the world state is replaced with NewAlice.
9. Alice can then access her previous assets under the new key NewAlice.

Addendum

Considering that triggers inherit authorities (#5475), the intermediary Reception Desk is redundant. The key point is that the delay before executing the migration should be a sufficiently long period approved by Alice, and must not be configurable by the guardians.

[aoyako]

It looks doable, but I have a few questions:

1. How can malicious guardians be identified? Shouldn't there be multiple guardians' verification (at least 3)?
2. At steps 5-7, Alice cannot use her account because the new key has not been issued yet. So, how can she approve/deny the migrate request?

[s8sato]

@aoyako

• By making the guardians a multisig account, you gain that protection. If you inspect the transaction history for the Propose and Approve instructions, you can see exactly who attempted an account migration.

• In step 7, we assume that Alice still holds her original key and the scheduled account migration was not initiated by her. In this design there is no remedy if she loses her key and the guardians betray her. That risk-versus-convenience trade-off applies to every recovery method. One way to rebalance it is to restrict, in step 1, the possible migration targets to keys that Alice has already generated and is securely holding.