What is the difference between a relation and a permission in a Zanzibar-style authorization model?

A relation defines a direct relationship between objects or subjects, such as a reader or writer link. A permission is a computed authorization decision built from one or more relations or other permissions, such as read or write. This distinction helps teams model ownership and access logic more accurately and avoids mixing raw relationships with effective privileges.

Relations and permissions live at different layers of the authorization model

A Zanzibar-style model separates raw object graph facts from effective access. Relations are the primitives that say how one subject connects to an object, while permissions are derived outcomes that answer whether a subject can act. That separation makes the schema easier to reason about, easier to audit, and less likely to collapse ownership structure into policy logic.

In practice, a relation is usually written as a named edge, such as editor, viewer, or member. It describes a direct link that can be stored or inferred from membership. A permission is then computed from one or more relations, or from other permissions, so that the system can express higher-order rules like can_view, can_comment, or can_manage without redefining the underlying relationships each time.

This is why the same object can have many relations but only a smaller set of business-facing permissions. Relations are closer to the data model, permissions are closer to the decision model. If teams treat them as interchangeable, the schema becomes hard to evolve, because changing a raw relationship would then also change the meaning of every access check built on top of it.

Why the distinction matters in real authorization design

The distinction is most useful when authorization needs to remain composable. A permission can aggregate multiple relations, inherit through nesting, or depend on other computed permissions, which lets teams express rules like direct access, group-based access, or transitive access in one place. That keeps application code from hard-coding access logic and reduces the chance that one team implements a shortcut that bypasses the intended policy graph.

It also helps with naming discipline. Relations should describe facts that can be asserted about the graph, while permissions should describe the outcomes the application actually cares about. If a system exposes everything as a permission, the model loses visibility into who is related to what. If it exposes everything as a relation, the product code has to reconstruct business intent at every check.

For teams building or reviewing authorization model, the practical question is whether a statement belongs in the graph as a reusable fact or in the policy as an evaluative result. That distinction becomes especially important when access rules must be extended later, because permissions can be redefined without changing the underlying relations, as long as the model keeps those layers separate.

Risk and Threat Considerations

When relation and permission are mixed together, organisations can end up granting effective access through a structure that was only meant to describe membership or ownership. That creates hidden privilege paths, makes access reviews unreliable, and increases the chance that a seemingly harmless relationship expands into broader authorization than intended.

Failure mechanism: A direct relation is treated as if it were already an effective privilege, or a derived permission is granted without understanding which underlying relations it depends on. In larger graphs, this can mask transitive access and make policy changes produce unexpected authorization effects.

Impact: Teams may overgrant access, miss toxic combinations, or fail to remove access when a relationship changes. In mature environments, this is one of the easiest ways for authorization drift to appear, because the graph still looks logically correct while the effective decision no longer matches the business rule.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations	Separates access decisions from underlying relationships and entitlements.
Recommendation — Define permissions as explicit authorization rules, not as raw relationship facts.
CIS Controls v8	6.3 — Access Rights Management	Maps directly to managing entitlements and preventing overbroad effective access.
Recommendation — Review effective permissions against intended access and remove excess rights.
OWASP Non-Human Identity Top 10	NHI-03 — Overprivileged Non-Human Identities	Derived permissions can hide excessive access when relationship facts are mistaken for privileges.
	NHI-05 — Lifecycle and Revocation	Changing a relation should not leave stale effective permissions behind.
Recommendation — Model derived access separately so excess privilege is visible and reviewable. Recompute and revoke permissions whenever the underlying relationship changes.
NIST SP 800-63	AAL2 — Authentication Assurance Level 2	Strong auth supports trustworthy enforcement, but the model still must distinguish facts from decisions.
Recommendation — Pair access checks with strong authentication to ensure the right subject is evaluated.

Practitioner Guidance

What to verify: Check that every relation in the schema answers a factual question about how objects connect, and every permission answers a decision question about what a subject may do. If the same name could plausibly fit both, the model is probably too ambiguous for safe maintenance.

Decision rule: If the value is something you would want to inspect during an access review, keep it as a relation or a derived input. If the value is something you would enforce at request time, model it as a permission. That keeps the graph usable for both human review and runtime authorization.

Practitioner takeaway: The safest Zanzibar-style designs keep relations descriptive and permissions evaluative, because that separation preserves explainability, supports composition, and makes privilege creep much easier to spot before it becomes an incident.