# Google Zanzibar ReBAC

## Source Type

Architecture pattern and research paper. Google Zanzibar (2019) defines
relationship-based access control at global scale.

## Domain

Relationship-based authorization, permission inheritance, and large-scale
access control graphs.

## Why This Source Matters

Zanzibar/OpenFGA-style relationship tuples are especially close to what
identity-canon needs for memberships, ownership, representation, delegation,
and tenant administration.

Zanzibar is the reference architecture for storing authorization facts as
subject-relation-object tuples with computed permission expansion.

## Key Concepts

- **Relation tuple**: `object#relation@subject` or `object#relation@subject#subject_relation`.
- **Object**: typed entity with namespace and ID (e.g., `document:readme`).
- **Subject**: user, group, or object acting through a relation.
- **Relation**: named edge type on an object type (owner, editor, viewer, member).
- **Userset rewrite**: computed relations via union, intersection, exclusion,
  and arrow operators (e.g., parent->owner).
- **Namespace configuration**: schema defining object types, relations, and
  rewrite rules.
- **Check API**: evaluate whether subject has relation to object.
- **Expand API**: enumerate subjects with relation to object.
- **zookie**: consistency token for read-after-write semantics.
- **Group as subject**: usersets allow group-like indirection in tuples.

## Relevant Terminology

| Term | Source meaning |
| --- | --- |
| Tuple | Stored authorization fact. |
| Object | Resource or entity being authorized. |
| Subject | Actor or userset granted a relation. |
| Relation | Named permission edge on object type. |
| Userset | Indirect subject reference via relation chain. |
| Namespace | Schema for object types and relations. |
| Check | Boolean permission query. |
| Expand | Enumerate authorized subjects. |
| owner / editor / viewer | Common relation names (deployment-specific). |
| parent relation | Hierarchical inheritance via rewrite rules. |

## Modeling Assumptions

- **Authorization facts are relationships**, not role assignments on users alone.
- **Subjects and objects are typed strings**, not rich identity records.
- **Inheritance is computed** from tuple graph via rewrite rules.
- **Identity provisioning is external**; Zanzibar stores authorization state only.
- **Groups are modeled as objects** with member relations, not as separate IAM groups.
- **Consistency matters** for distributed reads (zookie tokens).
- **No canonical person model**; subject IDs are opaque.

## Identity-Canon Implications

- Zanzibar **tuple** maps to **Relationship Tuple** (authorization projection).
- **Object** maps to **Authorization Resource** projection.
- **Subject** maps to **Authorization Principal** projection.
- **Relation** maps to typed **Relationship** with authorization implication.
- **Namespace** maps to **Authorization Domain** Scope.
- **Userset rewrite** is authorization engine logic, not canonical identity.
- Membership tuples (`group:eng#member@user:alice`) parallel **Membership
  Relationship** but live in authz layer.
- Supports S05 (admin delegation), S08 (moderator relations), S10 (service
  account acting for org via tuple).

## Terminology Conflicts

- **Subject**: Zanzibar subject is authz participant; OIDC subject is identifier.
- **Object**: Zanzibar object is authz resource; grammar object ≠ domain object.
- **Relation vs. Relationship**: Zanzibar relation is permission edge; canon
  Relationship is broader (social, legal, operational).
- **Member**: Zanzibar member relation on group object ≠ social membership.
- **User**: Zanzibar user ID is opaque; no person/account distinction.

## Candidate Canonical Mappings

| Zanzibar concept | Candidate canonical concept |
| --- | --- |
| Relation tuple | Relationship Tuple (authorization projection) |
| Object | Authorization Resource |
| Subject | Authorization Principal |
| Relation name | Relationship type (authz-implied) |
| Namespace config | Authorization Domain Scope |
| Group object + member | Group + Membership (authz projection) |
| Userset rewrite | Authorization engine derivation (non-canonical) |
| zookie | Consistency metadata (operational) |

## Open Questions

- Should canonical Membership Relationship be shared between identity and
  authz layers, or always projected into tuples?
- How should representation/delegation map to Zanzibar relations vs. identity-layer
  Representation Relationship?
- Should object namespace prefixes map to Scope identifiers?
- When does a social Following relationship warrant an authz tuple vs. remain
  identity-only?

## References

- Google Zanzibar paper — https://research.google/pubs/pub48190/
- Zanzibar ACL language (related) — referenced in paper §2
- OpenFGA (Zanzibar-inspired OSS) — https://openfga.dev/docs