Permissions

Two types of permissions are used in Keeta Network: “base permissions” and “external permissions.” Base permissions are represented by a symbolic name that corresponds to a specific value. External permissions are not managed by Keeta Network and can hold arbitrary flags (offsets) managed by an external party.

Encoding: Both base and external permissions are encoded using a bit-field of offsets to leverage bitwise operations for combining and checking permissions in a compact, fast bit-based expression. Subsequent modifications are likewise very efficient. Within the network, bit-fields will always be represented as one of the following:

• An array of numbers representing the index of true offsets within the bit-field

• The integer output of the bitwise operations

• For the case of base flags, an array of the flag names

Access Control List: On Keeta Network, permissions are stored and represented alongside information that describes their use. An access control list (ACL) entry will contain the following fields:

• Principal: The address identifying the actor on the network accessing an entity

• Entity: The network address that is being acted upon by the principal, and the address whose chain in which the ACL modifications occur

• Target: An optional address narrowing the scope of a permission

• Permissions: The list of base and/or external permissions granted, both represented as bitfields.

Permission Hierarchy: Permissions on Keeta Network are always read from most to least specific, with the default if none are set being empty. They will always be read with this priority. Permissions do not inherit from level to level. If one is defined it will override the less specific entry.

1. ACL entry that matches the principal + entity + target exactly

2. ACL entry that matches the principal + entity exactly, but does not include a specific target

3. (If the entity is able to) The default permission set by the entity

4. If none of the above are found, the permissions are assumed to be empty.

For example, if a storage address grants the ability for one user “SEND ON BEHALF” with no target, that user will be able to send any token from the storage account. If the storage account then creates an ACL entry for the same user with a specific token as a target not including “SEND ON BEHALF" that user will still be able to send any token, just excluding the specific token in which permissions were removed from.

Base Permissions: Base permissions each have a symbolic name and use case defined by Keeta Network. Each symbolic name is tied to a specific offset to be used in the bit-field, and a specific use on the network.

External Permissions: External permissions are not managed by Keeta Network. They can hold arbitrary flags managed by an external party. External parties can set these to arbitrary values using the same bitfield format as their counterpart. Within the network each offset is not tied to a symbolic name, and such are always only represented as a bitfield. If an external party wants to represent these using symbolic names, there is a client-side method to do so.

Ownership: The “OWNER” base permission represents ownership of an address. This is only applicable to generated account identifiers, as the owner of other accounts is the holder of the private key. On identifier creation, the creator is automatically given this permission. After that point, there must always be exactly one address with the “OWNER” flag, if any modifications are made, they must be done within the same vote staple as to not have the end count not equal to one. Some examples where an account created a storage account and is trying to transfer ownership include:

• Invalid Ownership Modification

  • The owner of a storage account signs a block granting a different address the OWNER permission, leaving two owners

  • The owner of a storage account signs a block lowering their own permissions to ADMIN, leaving no owners

  • The owner of a storage account performs both the correct addition and removal, but performs the action in two vote staples, making each one invalid alone.

• Valid Ownership Modification

  • The owner of a storage account signs a block in which the new owner is granted the OWNER permission and the previous owner is re-assigned a bitfield not including OWNER.

Delegation: On Keeta Network, the “PERMISSION DELEGATE ADD” and “PERMISSION DELEGATE REMOVE” flags both represent the ability for the principal to re-assign permissions to other addresses for the entity that these were granted from. Both of these flags work in a similar way, but each representing a different method (“AdjustMethod”) that is being used in the “MODIFY PERMISSIONS” block operation. A principal with either of these flags is only able to add or remove a subset of the permissions that they have on the same entity, and is not able to re-grant either of the delegation flags unless they are an admin of the entity.