Skip to content
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.

Guardian role confirmation #207

Open
JohnGuilding opened this issue Feb 13, 2024 · 0 comments
Open

Guardian role confirmation #207

JohnGuilding opened this issue Feb 13, 2024 · 0 comments

Comments

@JohnGuilding
Copy link
Contributor

JohnGuilding commented Feb 13, 2024

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:

  1. The owner of the account adds a guardian hash on-chain.
  2. 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.
  3. The relayer could then email the guardian in question and all the guardian has to do is email back the relayer to confirm acceptance.
  4. 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.
  5. 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.

@JohnGuilding JohnGuilding moved this from 📋 Backlog to 📤 Up Next (Current Sprint) in Wallet Account eXperiments (WAX) Feb 13, 2024
@jacque006 jacque006 added this to the ZKEmail Recovery milestone Feb 14, 2024
@JohnGuilding JohnGuilding moved this from 📤 Up Next (Current Sprint) to 📋 Backlog in Wallet Account eXperiments (WAX) May 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants