RBAC and ReBAC Scope

Use this page when deciding whether a permission belongs in the current role/group model or needs a later relationship-aware rule. v1 keeps access predictable and RBAC-first.

v1 Rule

Permissions v1 is RBAC-first.

Roles remain the primary grant path, groups organize users and roles, and direct overrides stay exceptional.

ABAC Layer

ABAC is allowed only as a governed conditional layer on top of RBAC.

Examples:

• owner can edit own content
• action allowed only in a workflow state
• action limited to a verified account or department

ABAC must not replace roles or hide permission meaning.

ReBAC Direction

ReBAC is future scope, not v1 foundation.

Relationship-based rules may be introduced later for cases such as manager of a team, member of an organization, or operator assigned to an object.

When introduced, ReBAC must arrive through a governed extension path and must not muddy Roles and Groups.

Separation Rule

Keep these concepts distinct:

• role grants
• direct overrides
• conditional policies
• relationship policies
• Super Admin authority

See Permission Manifest Declarations.