generated from coulomb/repo-seed
Complete IDENTITY-WP-0003 corpus backfill and model refinement
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
This commit is contained in:
@@ -1,50 +1,111 @@
|
||||
# Zanzibar Rebac
|
||||
# Google Zanzibar ReBAC
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Architecture pattern and research paper. Google Zanzibar (2019) defines
|
||||
relationship-based access control at global scale.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Relationship-based authorization, permission inheritance, and large-scale
|
||||
access control graphs.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Google Zanzibar-style relationship-based authorization concepts.
|
||||
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
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **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
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| 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
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **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
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- 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
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **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
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| 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
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- 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
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- Google Zanzibar paper — https://research.google/pubs/pub48190/
|
||||
- Zanzibar ACL language (related) — referenced in paper §2
|
||||
- OpenFGA (Zanzibar-inspired OSS) — https://openfga.dev/docs
|
||||
Reference in New Issue
Block a user