delegate from interactive signer to background signer for low-privilege actions

[michaelfig]

What is the Problem Being Solved?

refs: #4398

The on-chain wallet backend needs explicit approvals for operations that withdraw from purses, but we don't want to require explicit approvals for most user gestures.

Description of the Design

Our CosmJS integration is intended to be used as follows:

• start with a "warm" or "cold" keypair in the Signer (Keplr/MetaMask)
• UI guides user through an optional preapproval process. If not preapproved, then the wallet uses the "warm" keypair for every chain-modifying operation tx (with the full Signer approval process)
  • generate a "hot" Agoric CosmJS keypair, store encrypted with user password in browser
  • submit a batch of authorisation messages as one Signer transaction:
    • feegrant from the cold account to the hot account
    • authz to allow MsgWalletAction from hot account on behalf of cold account
    • optional - authz to allow MsgWalletSpendAction from hot account on behalf of cold account
• if user has a "hot" keypair, they must enter a password once on load to use it instead of the Signer
• in order to withdraw anything from a purse, the eventual send needs to be done via "MsgWalletSpendAction", where the backend basically remaps the marshalled input slot references as:
  • refs.map(ref => (spendActionAmplifier.get(ref) || ref))
  • and then handles the eventual send in the same way as MsgWalletAction
• categories of restricted "spend" behaviour:
  • sending from a purse to Zoe escrow as part of offer approval
  • sending from a bank purse (Cosmos-level account, urun, ubld) to anywhere else
  • NOT sending between purses otherwile

Security Considerations

Needs review by security folks.

Test Plan

[dckc]

re

• generate a "hot" Agoric CosmJS keypair, store encrypted with user password in browser

Managing another password is a pain both for users and for us.

@dtribble doesn't think we want any code dealing password management; nor do I. (I prototyped something like this in 2018 using tweetnacl, but I very much avoided productizing it: https://github.com/rchain-community/RSign/blob/master/src/sigTool.js )

localStorage APIs don't include encryption, though there are emerging web crypto APIs.

Outsourcing to keplr would be nice; there's some hint of this feature:

https://github.com/chainapsis/keplr-wallet/blob/a8f6e01783eabfd7fb181b3588dbca4566a1f22e/packages/background/src/secret-wasm/handler.ts#L23

But I don't see it in https://docs.keplr.app/api/

[dckc]

discussion yesterday suggested not managing a separate password but rather

• storing the ephemeral key in localStorage in the clear
• limiting the duration of authz grants

[dckc]

@rowgraus referred to these as "background" actions, which @michaelfig and I like enough to go with for now, so I'm changing the title.

The scope still has some fuzzy edges around it...

I also like @turadg 's suggestion that the names should make clear just what authority we grant to the background signer; we came up with nonSpending but that didn't survive discussion with @michaelfig , whose position is that the background signer is limited to actions within the wallet itself, such as transferring between purses. I had assumed that getting an invitation was a background thing, but that's not the design that MFig has in mind.

Earlier, I asked @dtribble for uses of the "ephemeral" (aka background) key:

Creating a vault should get the subsidiary vault manager facet form the vault director and then get a vault from there. The old protocol did that in one step, but now it should be two pipelined messages. Most things you would do in the REPL are ephemeral key. A few steps in getting a lien should be ephemeral key? (to get/redeem the SFT). I think there are several multistep things that don’t require approval for governance