Changelog
- 2019-11-06: Initial Draft
- 2020-10-12: Updated Draft
- 2020-11-13: Accepted
- 2020-05-06: proto API updates, use
sdk.Msginstead ofsdk.ServiceMsg(the latter concept was removed from Cosmos SDK) - 2022-04-20: Updated the
SendAuthorizationproto docs to clarify theSpendLimitis a required field. (Generic authorization can be used with bank msg type url to create limit less bank authorization)
Status
AcceptedAbstract
This ADR defines thex/authz module which allows accounts to grant authorizations to perform actions
on behalf of that account to other accounts.
Context
The concrete use cases which motivated this module include:- the desire to delegate the ability to vote on proposals to other accounts besides the account which one has delegated stake
- “sub-keys” functionality, as originally proposed in #4480 which
is a term used to describe the functionality provided by this module together with
the
fee_grantmodule from ADR 029 and the group module.
Decision
We will create a module namedauthz which provides functionality for
granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations
must be granted for a particular Msg service methods one by one using an implementation
of Authorization interface.
Types
Authorizations determine exactly what privileges are granted. They are extensible and can be defined for anyMsg service method even outside of the module where
the Msg method is defined. Authorizations reference Msgs using their TypeURL.
Authorization
SendAuthorization like this is defined for MsgSend that takes
a SpendLimit and updates it down to zero:
MsgSend could be implemented
using the Authorization interface with no need to change the underlying
bank module.
Small notes on AcceptResponse
-
The
AcceptResponse.Acceptfield will be set totrueif the authorization is accepted. However, if it is rejected, the functionAcceptwill raise an error (without settingAcceptResponse.Accepttofalse). -
The
AcceptResponse.Updatedfield will be set to a non-nil value only if there is a real change to the authorization. If authorization remains the same (as is, for instance, always the case for aGenericAuthorization), the field will benil.
Msg Service
Router Middleware
Theauthz Keeper will expose a DispatchActions method which allows other modules to send Msgs
to the router based on Authorization grants:
CLI
tx exec Method
When a CLI user wants to run a transaction on behalf of another account using MsgExec, they
can use the exec method. For instance gaiacli tx gov vote 1 yes --from <grantee> --generate-only | gaiacli tx authz exec --send-as <granter> --from <grantee>
would send a transaction like this:
tx grant <grantee> <authorization> --from <granter>
This CLI command will send a MsgGrant transaction. authorization should be encoded as
JSON on the CLI.
tx revoke <grantee> <method-name> --from <granter>
This CLI command will send a MsgRevoke transaction.
Built-in Authorizations
SendAuthorization
GenericAuthorization
Consequences
Positive
- Users will be able to authorize arbitrary actions on behalf of their accounts to other users, improving key management for many use cases
- The solution is more generic than previously considered approaches and the
Authorizationinterface approach can be extended to cover other use cases by SDK users