Two Step Method for Adding a new Control Key

[wilwade]

Context

Currently the add_public_key_to_msa method adds a control key to an msa. While this works, it requires three signatures:

1. Signature of a current control key holder
2. Signature of the new additional control key holder
3. Transaction signature of the action payee.

Signatures 1 and 2 can be difficult to coordinate. Proposed in the Community Call was adding method that enables separate chain interactions for those two signatures. This follows a pattern akin to the multisig pallet

For additional context and discussion see the Frequency Community Call on 2023-09-28: https://discord.com/channels/969001918460469250/969308206562164736/1157148627987333261

Additional Flow Proposal

(As transcribed by me, any errors are my own)

1. "Offer Control Step" Current control key holder submits an extrinsic that adds a key to a new "pending" state
   • via a signature with a possible alternative payee
   • Call should "prepay" the cost of the second call below
2. "Claim Control Step" The holder of the new key may then later submit a "prepaid" transaction that completes the action
   • As a prepaid transaction, the new control key does NOT need any tokens
   • The offer once claimed should remove the offer and the resulting MSA change should look no different than one that occurred via add_public_key_to_msa

Questions/Notes

• This would NOT remove the prior method which may be better for some use cases
• Any claim control call that gets into a block that fails must still remove the offer to prevent DOS issues
• Do we need to prevent multiple calls in the same block to claim control? (Is this an issue on other "prepaid" calls?)
• A way to remove an offer would be required
• Do offers need to expire?
• Should this be a different pallet? (I think no)

[enddynayn]

My understanding of what is being asked Currently, most users are tokenless users who are onboarded by providers via custodial wallet. If a user wants to add a new key to their account it would require some coordination between the custodial wallet and the wallet where the new key is stored. For example, a UI that is integrated with both the custodial wallet and the wallet of the new key. What is needed to be signed with the keys stored in custodial is the extrinsic add_public_key_to_msa this extrinsic requires:

• Proof of ownership over the new key.
• Proof of ownership over the msa.
• A key that is funded to pay for the transaction.

We can decouple this coordination by allowing anyone to be able to PROPOSE a new key to be attached to an account. The proposer is required to leave a deposit in addition to paying the transaction. The owner of the MSA can later approve the proposal to add a new key free of cost.

Some thoughts Some decisions to make: who initiates the proposal the owner of the MSA or anyone? If it is the owner who requests to add a new key it would require the owner to have a funded key which is not the case for tokenless users.

If anyone can request a key to be added to an account a user may accidentally add a key to an account that is not wanted. It would be easy for anyone to add a key making it difficult for the user to know which one to accept to add.

Potential stories WIP A User wants to add a new key to an account that they do NOT own. A user is requesting access to the MSA account

• potential future features would be to also include permissions

A user wants to add a new key via a two-step claim and verification process. A user can create a claim leaving a deposit that it wants to add a new key. It claims that a new key should be added to an MSA and wants to add a key to it. This claim provides proof that it has ownership over a key. The owner or authorized provider can approve the key.

As a user I want to be able to add a new key to an MSA

• the user provides the msa-id for which they want to associate the account
• the user provides proof of key ownership
• The user leaves a deposit for adding a key note: giving authority to the service provider to accept a claim can have the risk of a service provider hijacking an account.

Possible ways to confirm:
The transaction is submitted by anyone As a user of frequency who has Capacity, I want to be able to submit and pay for an add-key claim on behalf of a user.

• user providers proof of ownership over MSA by signing.
• the user provides the key they are allowing to be added -- Proof ownership of new key: part of the claim --proof of MSA ownership

The transaction is submitted by the owner of the MSA
As an owner of MSA, I want to be able to submit transactions and verify an add key claim.

• user submits transaction with a key associated with an MSA to prove ownership
• The user submits the key that is being added