Permissions

zoom_0.mp4

Background

Iroha Special Instructions and Iroha Queries processing requires a permissions based security model.

Whitepaper and Iroha v1 documentation were researched.

Problem

The White Paper requires protection of data from unauthorized read and write access.

Iroha 1 documentation gives a Permission's definition:

A named rule that gives the privilege to perform a command. Permission cannot be granted to an account directly, instead, account has roles, which are collections of permissions. Although, there is an exception, see Grantable Permission.

and Grant-able Permission:

Only grantable permission is given to an account directly. An account that holds grantable permission is allowed to perform some particular action on behalf of another account. For example, if account a@domain1 gives the account b@domain2 a permission that it can transfer assets — then b@domain2 can transfer assets of a@domain1 to anyone.

As you can see permissions were a first-level entities in Iroha 1 and had a strict hardcoded verification logic. Iroha1 was mainly planned to be used as a private blockchain and this system would work there. Yet Iroha2 is planned to be used in both private and public blockchains and therefore needs some degree of customization on how permissions are checked to implement some more complex cases.

Solution

Decisions

• Store permissions as Iroha Assets
• Check permissions by Iroha Triggers
• Place initial configuration inside additional Permissions Iroha Module and apply it from the Genesis Block

Alternatives

1. Use Iroha 1 approach with roles and grantable permissions and do hardcoded permissions checks inside instructions
   1. Pros:
      
      1. Tested in already running blockchains like bakong and byacco
   2. Cons:
      
      1. Hardcoded permission model - not possible to suit to different types of blockchains
2. Use Iroha Special Instructions as scripting for checking permissions + Assets mechanisms to store. With two options: implement permission checks as triggers, or simply another part of validation pipeline.
   1. Pros:
      
      1. Customizable permissions check logic
      2. Can be changed at runtime and stored in file
   2. `+` customizable permissions check logic
   3. `+` can be changed at runtime and stored in file
   4. `-` no ability to clean genesis block  processing and configuration
3. Use WASM permission check functions so that they can be fully customized and written in any programming language (at runtime can be swapped)

Concerns

• Additional requirements to Iroha Special Instructions, Queries and Triggers will slow down development
• Additional high-level functionality would be needed to simulate "Roles"

Assumptions

• Iroha Triggers support pre-instruction hooks because it will be more effective to check permissions before instructions execution

Risks

• This solution will impact Iroha Triggers design `[9;6]`

Additional Information