info-tech-canon/infospace/assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md

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