Permission Rights Model
While Catenis uses the public Bitcoin blockchain, it has incorporated a robust access control and permissions rights system within its second layer technology. Customers have the convenience of applying access control, allowing and denying access across all of its connected applications and devices. The ability to set the permission of decentralized endpoints is a key differentiator that this technology brings to an open auditable ledger. Catenis brings functionality typically associated with closed private blockchains to the world’s most powerful and proven public blockchain while providing all the regulatory needs of an Enterprise application.
A controlling device (the device that initiates a message transmission) can designate how and which devices (controlled devices) are allowed or denied interactions with it based on permission events. System events in the context of the permission layer are called permission events.
Customers can use this permission system to restrict communication to a single device, groups of devices, company or network-wide. Larger trusted connected systems can be built to include outside partners and customers as well.
Permission events are specific actions that can be either allowed or denied. All permissions events are set on the device you want to allow or deny interactions with. This device is referred to as being the subject device or controlling device (the device that controls what can or cannot be done to it) and sets its permission as to which other virtual devices can or cannot interact with it. The following permission events are currently defined:
- Receive-notify-new-msg – Receive notification of a new message from a device
- Receive-notify-msg-read – Receive notification of message read by a device
- Receive-notify-asset-of – Receive notification of asset received for assets issued by a device
- Receive-notify-asset-from – Receive notification of asset received from a device
- Receive-notify-confirm-asset-of – Receive notification of confirmation of pending asset issued by a device
- Receive-notify-confirm-asset-from – Receive notification of confirmation of pending asset transferred by a device
- Send-read-msg-confirm – Send read message confirmation to a device
- Receive-msg – Receive messages from a device
- Disclose-main-props – Disclose device’s main properties (name, product unique ID) to a device
- Disclose-identity-info – Disclose device’s basic identification information to a device
- Receive-asset-of – Receive an amount of an asset issued by a device
- Receive-asset-from – Receive an amount of an asset from a device
Permission Right Levels
All right across permission events can be set to either “allow” or “deny” at 4 different levels. Setting permission rights at a higher level will affect all devices within the context of that level. For example, permissions set at the node level will affect all devices across all clients within that node.
- System-level: controls permissions rights across the entire Catenis network where the default permission rights are defined.
- Catenis Node level: controls the permission rights for all devices that belong to all clients defined for that Catenis node. Catenis nodes are computers referred to as either “hubs” or “gateways”. Each hub or gateway has a specific index number. If you are using our cloud implementation the index number is always 0.
- Client Level: controls the permission rights for all devices that belong to this client. Clients are Catenis system entities within a Catenis node. A Hub or gateway, for instance, may have one or more clients.
- Virtual Device level: controls the permission rights for specific virtual device
How Permissions are Evaluated
Setting permission rights at a higher level will affect how all virtual devices within the context of that level and levels below it can or cannot interact with the subject device. For example, permissions set at the node level will affect all devices across all clients within that node. However, the system evaluates permissions giving precedent to the more granular levels over the very broad system level. The system first looks to see if a device is allowed or denied permission for a permission event at the device level. If there are no permissions set then it evaluates the next level which is the Client level, then the Catenis node level, and finally the System level. Keep in mind that within this hierarchy it is possible to set what seems to be (yet are not) conflicting permissions. This is because permissions that are set at a more granular level will always override what is set at a higher level.
Let’s review an example: You may set the “receive-asset-from” permission event for virtual device A to “deny” for all devices at the Catenis Node Level. This means virtual device A will not be able to receive any assets from any device that is part of that Catenis node. However, if you had previously set the same “receive-asset-from” permission event for virtual device B at the Virtual Device Level to “allow”, then device A will be allowed to receive assets from device B even though device B is part of the same Catenis node you recently denied access to all devices. Always review granular permissions for each event before setting permissions more broadly. If ever in doubt use the “check effective permission right” node using the subject device to connect and supplying the device ID of the device that is attempting to execute a permission event with the subject device.