[Feature]: Allow more than one authorisation with authz at any given time

[womensrights]

This issue is now about updating the documentation to make aware client how to update a grant.
ref: #18567 (comment)

The original issue can be found below:

---

Summary

Currently a user can only grant a single authorisation at a time with authz, the feature request is to enable more than one authorisation at a time.

Problem Definition

If an authorisation already exists for a user and they want to create another, then the authorisation is overwritten so there currently can't be multiple authorisations at a given time.

In IBC, we have authz enabled ICS-20 transfers, so a user can grant privilege to transfer tokens on their behalf. Yieldmos outlined a user flow they wanted to explore which would require multiple transfer authorisations, so that small balances of different tokens accumulated on a given chain, say the hub, could then be transferred to Osmosis, swapped to ATOM and returned to the Hub to stake.

Proposed Feature

To enable more than one authorisation to be granted at a time rather than automatically overwriting the authorisation upon a new authorisation, there could be flexibility to overwrite or at to the existing authorisation(s)

[tac0turtle]

It seems like this feature would be to allow a authorisations to be for multiple tokens instead of one, is that correct?

[womensrights]

yes that's correct, I've asked the Yieldmos folks to follow up on this issue as well

[tac0turtle]

This seems like a client side issue. When wanting to modify an existing grant, the client can query the existing and add the new information then submit it. It seems like a easy enough to do at the client level.

The issue with the state machine allowing to append things is the complexity grows in how do you override the current values with new ones. We would need a way for the client to let the chain know if its modification or overwrite. This complexity could confuse implementors.

[NoahSaso]

thanks for posting this @womensrights, i think this is a critical feature (imo it's a bug fix)

@tac0turtle i see your point about this being technically possible to resolve on the client side, but it seems to me like every client has to implement it correctly or all of them break. i as a client can ensure that i update grants appropriately, but i have no way to guarantee that other clients don't overwrite my usage, so it's basically unusable as it cannot be relied upon.

i could be missing a critical piece, so please let me know if my understanding is inaccurate!

also imo it's more confusing to expect a client to know they have to query previously created state and update it than to require them to decide between a create and an update action. create and update are very familiar operations.

wouldn't the complexity be solved by assigning a unique ID to an authorization on creation? maybe an incrementing ID, a hash of block height and message index, or something like that. it's easy to query and update an ID with constant time complexity, and clients could track which authorizations they created. a client should always be able to verify if they authorized something or not, which is also currently not the case.

there would be a space complexity issue with infinite appends, and a time complexity issue while checking all existing authorizations in MsgExec. though there's probably a reasonable max that could be set to prevent that too 🤷🏻‍♂️

[NoahSaso]

an example use case that requires multiple authorizations with an append message: DAOs

the key distinction between a wallet and a DAO that is relevant here is that DAOs separate message creation and message execution. a DAO can create messages in any order (ie open proposals for voting) and execute them in any order, and more than one message can simultaneously exist in the pending (voting) state. thus, each message must be able to perform its own action independent of others.

if i want to authz grant from a DAO right now, i'll always have to wait for all other authz grant proposals to finalize, and same for authz revoke. this poses a security risk if action needs to be taken to revoke access from a malicious or compromised account while other grant or revoke proposals are still pending.

essentially DAO DAO pretty much needs authz adjusted to support multiple grants in order to safely take advantage of authz.

[julienrbrt]

Hi! We are trying to not increase the feature set nor complexity of x/authz
I'd say, let's add this to the documentation: #18567 (comment) to let client know how to update a grant.

[NoahSaso]

Hi! We are trying to not increase the feature set nor complexity of x/authz I'd say, let's add this to the documentation: #18567 (comment) to let client know how to update a grant.

that's unfortunate to hear