ICS 21: Cross-chain access control delegation about ibc HOT 5 CLOSED

This is great, we could design an interchain capability format, like the following:

• Identifier: Unique identifier for a key, an address or UUID
• Capability: one or more of the followings(since we cannot have homogenous closure syntax across the chains):
  • Function signature: the function that this key can call(e.g. bank.SendCoins)
  • Function argument: the argument that this key can call with(e.g. specific destination address)
  • Predicate: function call to a VM predicate which takes (funcsig, funcargs) and returns bool(e.g. cannot send assets to blacklisted addresses)
• Owner capability: the permission of the owner of this key(e.g. the owner cannot transfer the ownership)

Each key could be stored under each address, indicating the ownership of the address on that key.

from ibc.

How do you think if we implement a changable pairing of address(A) and multisig address(M) in current Cosmos-SDK(Cosmoshub).

Then we can

1. Implement a shared asset management with changable pairing.(dynamic multisig key combination, with dynamic weight of each key of multisig)
2. This can be applied to the concept of peg-zone(key-set of multisig can be a validator-set of independent zone)

from ibc.

Would want to understand better how will it work with what @sunnya97 is working on ? So keys with different security constraints eg, transfer only key, governance key, validator key and so on.

I would prioritize key rotation for validators and splitting validator key from account key before ICS 21.

from ibc.

My suggestion is not about IBC so I will move my comment to Cosmos-sdk repo.

from ibc.

Closing in favor of #251 which is a more concrete proposal in this vein.

(although it is not an interchain capability format, per se, so @mossid maybe that should be another proposal, if you think it would be worthwhile - I think it might be)

from ibc.