Skip to main content

Role Bindings

Role bindings connect roles with public keys.

For example, to grant a user permission to access a resource, you must first ensure that you have a role that defines the permissions. Then, you bind that role to the user's public key.

A role binding contains the following fields:

  • a unique ID - We recommend using UUIDs as IDs.
  • a name - This is used for easy identification in queries.
  • a role - This is the ID of the role you wish to bind.

Expressions​

Expressions are a way of conditionally applying role bindings and provide a flexible way to restrict access to resources. An expression is evaluated at runtime against the properties of the resource being accessed. This allows you to grant permissions based on criteria instead of a fixed list of instance IDs.

Example: document.owner == public_key - This expression grants access only if the owner field of the resource matches the public_key of the subject attempting to access it.

Expressions are handy when combined with is_universal. It allows a role binding to be used by any public key. You may have noticed that most DRM API requests have a field called owner. The owner field does not give any permissions. Instead, we often create role bindings with an expression like document.owner == public_key.

A role binding supports a list of expressions. Each collection in a role can be assigned its own expression. We use MQL to write Expressions, which has a syntax similar to Rust, and is detailed in the MQL documentation.

Expressions in role-bindings work for all collections that are “registered” (i.e. that provide a type environment) in the system. For collections that are not set up that way, expressions will not work.

Currently supported collections:

  • account-metadata
  • account-set
  • banks
  • ledger-account
  • role-binding
  • roles

The expression compiler supports the following operations:

  • Literals: Numbers, strings, booleans, and bytes.
  • Infix operations: Boolean “and”/“or” and equality checks are allowed. (Other infix operators like arithmetic, union/intersect, etc. are not supported.)
  • Field access: If the object's type is known (e.g. a document with an “owner” field), then you can access its fields.

The following expressions are allowed:

FieldDescription
ownerThe owner field does not provide any permissions. Instead, we often create role bindings with an expression like document.owner == public_key.

Permission to create role bindings​

To grant permission to create role bindings, we use the Create verb on the role-bindings collection. If you have full access (permissions) to your account, you can create a new role-binding and bind it to someone else to provide them access to your account. This empowers users to grant permissions to accounts they own or already have access to.

For example, to add a new public key (from a second mobile device) to your account, create a new role-binding with the new key:

note

You can not grant someone more permissions than you have. That is true whether you create a new role-binding or update an existing one.

Model​

The data model for an DRM hierarchical ledger account is defined in rbac.proto:

API Requests​

Create​

To create a role-binding:

  • Rust
  • TypeScript
  • Dart
  • CLI
M10 REPLFOO




Update​


To update a role binding:


  • Rust
  • TypeScript
  • Dart
  • CLI
M10 REPLFOO




Delete​


To delete a role binding:


  • Rust
  • TypeScript
  • Dart
  • CLI
M10 REPLFOO






List (Find)​


To list role bindings by name:


  • Rust
  • TypeScript
  • Dart
  • CLI
M10 REPLFOO




Get​


To get a role binding:


  • Rust
  • TypeScript
  • Dart
  • CLI
M10 REPLFOO




HTTP/1
To submit requests over HTTP/1 instead of HTTP/2 with the SDKs, use the http option.