Skip to main content

Credential RBAC for State Transition

It is a common requirements for applications that requires collaboration from many parties use role based access control (RBAC).

In the context of D-Chain, notarised objects may have a life cycle where state transitions are based on roles and access control. The roles and access control are defined by the application administrators and enforced by the chain's modules.

This builds on the work of AVIDA for notarised objects, see verifier as a service in x/vcv for more details.

This is a scalable approach compare to other forms of access control - blockchain applications that white list certain addresses. This is because verifiable credentials can be issued off-chain by a list of trusted issuers selected by the application, the applications are not "issuing" (by using admin rights to maintain a white list) and verifying the right to use the application themselves, which is an anti-pattern for verifiable credential design.

Example usage​

A surety bond between three parties:

  • Principal: The party that requires the bond
  • Obligee: The party that requires the bond to be issued
  • Surety: The party that issues the bond

The bond can be a notarised object on D-Chain, which has a life cycle of issuance, claims and settlement.

At any given time, the state of the bond can only be transitioned by the party that has the right to do so.

The Credential RBAC allows the smart contract, representing the bond, to verify the verifiable presentation of the party that is performing an onchain execution for state transition.