You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.
A guardian should have to accept being chosen as a guardian, as opposed to the owner of the account just adding something like the guardian hash on-chain, and not having some sort of confirmation with the guardian.
This is more secure as:
The guardian consents they are happy to recover the specific account
It confirms guardians have ownership of the email address in question
Protects against scenarios where the guardian account/email address is entered incorrectly in the guardian hash.
While this does add a bit of friction to the recovery process. The benefits to security probably outweigh the negatives to UX. A similar mechanism is used by Apple when setting up recovery contacts and adding non-family contacts:
If you select a family member, they'll be added automatically. If you select a contact, they'll need to accept the request.
A possible mechanism:
The owner of the account adds a guardian hash on-chain.
The relayer could then monitor for events on that contract, or the owner just calls an api endpoint on the relayer that initiates setting up a guardian.
The relayer could then email the guardian in question and all the guardian has to do is email back the relayer to confirm acceptance.
The relayer would then have the information it needs from the guardian to regenerate the hash the owner stored on-chain. It would confirm the hash matches the one the owner stored earlier.
There would be a salt involved that would have to be shared between the owner and guardian securely too.
The above implementation is just an initial idea that we came up with on a call. We should consider if there are more robust implementations. We should also be mindful about options for how confirmation can be done without the relayer so the confirmation is less censorable.
The text was updated successfully, but these errors were encountered:
A guardian should have to accept being chosen as a guardian, as opposed to the owner of the account just adding something like the guardian hash on-chain, and not having some sort of confirmation with the guardian.
This is more secure as:
While this does add a bit of friction to the recovery process. The benefits to security probably outweigh the negatives to UX. A similar mechanism is used by Apple when setting up recovery contacts and adding non-family contacts:
A possible mechanism:
The above implementation is just an initial idea that we came up with on a call. We should consider if there are more robust implementations. We should also be mindful about options for how confirmation can be done without the relayer so the confirmation is less censorable.
The text was updated successfully, but these errors were encountered: