Access

​

Capabilities

• Create roles that encapsulate operational capabilities (operator, maintenance)
• Define permissions (e.g., store_telemetry, emit_intent)
• Assign permissions to roles and grant roles to robot or user DIDs
• Query existing policies for audit trails or dashboards

​

Service Reference

​

Example Workflow

# 1. Create role
ros2 service call /peaq_core_node/access/create_role \
  peaq_ros2_interfaces/srv/AccessCreateRole \
  '{role_id: "operator"}'

# 2. Create permission
ros2 service call /peaq_core_node/access/create_permission \
  peaq_ros2_interfaces/srv/AccessCreatePermission \
  '{permission_id: "telemetry:write"}'

# 3. Assign permission to role
ros2 service call /peaq_core_node/access/assign_permission \
  peaq_ros2_interfaces/srv/AccessAssignPermToRole \
  '{role_id: "operator", permission_id: "telemetry:write"}'

# 4. Grant role to robot DID
ros2 service call /peaq_core_node/access/grant_role \
  peaq_ros2_interfaces/srv/AccessGrantRole \
  '{user_did: "did:peaq:5G...", role_id: "operator"}'

​

Automation Pattern

• Trigger RBAC provisioning from CI whenever a new robot identity is created.
• Use a ROS 2 Node (Python/C++) that batches service calls and verifies outcomes before declaring a robot operational.
• Persist granted roles using your fleet management system for quick audits.

​

Best Practices

• Prefix permissions with domain context (telemetry:write, mission:cancel) to avoid collisions.
• Use different roles for humans vs. robots even if they share capabilities—this keeps grants revocable per actor type.
• Log RBAC service responses for compliance; they already include block hashes and timestamps.