coulomb/identity-canon
Archived
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Complete IDENTITY-WP-0003 corpus backfill and model refinement

Browse Source 
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:
Bernd Worsch
2026-06-21 20:22:20 +02:00
parent 790a2f2041
commit 1c1b5c9bc6
32 changed files with 2676 additions and 623 deletions
Download Patch File Download Diff File Expand all files Collapse all files

96
research/authorization-relationships/cedar-principal-action-resource-context.md
View File

@@ -2,49 +2,113 @@
## Source Type
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
Standard and product reference. Cedar policy language (AWS Verified Permissions)
with principal-action-resource-context evaluation model.
## Domain
TODO: Classify the source domain.
Fine-grained authorization, policy-based access control, and ABAC/RBAC
hybrid evaluation.
## Why This Source Matters
Cedar principal-action-resource-context model and policy terminology.
Cedar's principal-action-resource-context distinction preserves orthogonality
between identity, action, resource, and request context.
## Key Concepts
TODO:
- concept 1
- concept 2
- concept 3
- **Principal**: entity requesting access; typed entity reference (`User::"alice"`,
`Role::"admin"`).
- **Action**: operation being attempted (`Action::"view"`, `Action::"delete"`).
- **Resource**: entity being accessed (`Document::"report"`).
- **Context**: request-time record with additional attributes (IP, time,
delegated-by).
- **Policy**: Cedar statement allowing or forbidding `(principal, action, resource)`
under conditions.
- **Entity**: typed object in entity store with attributes and parents.
- **Schema**: defines entity types, actions, and attribute shapes.
- **Group / Role entity**: principal may be member of groups; roles as entities.
- **Authorization request**: tuple of principal, action, resource, context
evaluated against policies.
- **Conditional policies**: when-clauses over context and entity attributes.
## Relevant Terminology
TODO: Extract terms used by the source and note their source-specific meaning.
| Term | Source meaning |
| --- | --- |
| Principal | Entity requesting access in authorization decision. |
| Action | Verb/operation being authorized. |
| Resource | Target entity of the action. |
| Context | Ephemeral request attributes. |
| Entity | Typed node in entity store with UID and attributes. |
| Policy | Rule governing allow/deny. |
| Schema | Type system for entities and actions. |
| Role | Entity type principals can assume or belong to. |
| Group | Entity type with membership edges. |
| UID | Unique entity identifier string (`Type::"id"`). |
## Modeling Assumptions
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
- **Authorization is a decision over four orthogonal dimensions** (PARTICIPANT,
ACTION, TARGET, CONTEXT).
- **Principals are entity references**, not full identity records.
- **Entity store is separate** from identity directory; may sync from IAM.
- **Roles and groups are entities**, not free-floating strings.
- **Context carries delegation and environmental facts** at decision time.
- **Policies are declarative** and evaluated without imperative code.
- **No social or legal relationship model** beyond entity parent/group links.
## Identity-Canon Implications
TODO: Explain what this source suggests for the canonical identity model.
- Cedar **Principal** maps to **Authorization Principal** projection.
- **Resource** maps to **Authorization Resource** projection.
- **Action** maps to **Authorization Action** projection.
- **Context** maps to request **Context** projection (may carry Delegation
evidence).
- **Entity** in store may represent Account, Group, Role, or Organization
projection — not canonical Actor directly.
- Parent/group entity links parallel **Membership** in authz layer.
- Context `delegatedBy` or custom attributes support S11 (AI agent delegation).
- Strong evidence for **P6** and **P2** (principal ≠ actor ≠ account).
## Terminology Conflicts
TODO: Record where this source uses terms differently from other sources.
- **Principal vs. Actor**: Cedar principal is decision participant; actor is
conceptual entity.
- **Principal vs. Subject**: OIDC subject is identifier; Cedar principal is
typed entity UID.
- **Role**: Cedar Role entity vs. IAM role vs. social role.
- **Group**: Cedar group entity vs. LDAP group vs. community.
- **Entity**: Cedar entity vs. canon Entity family (actor layer).
## Candidate Canonical Mappings
TODO: Map source-specific concepts to identity-canon candidate concepts.
| Cedar concept | Candidate canonical concept |
| --- | --- |
| Principal | Authorization Principal |
| Resource | Authorization Resource |
| Action | Authorization Action |
| Context | Request context projection |
| Entity (User) | Authorization Principal (Account projection) |
| Entity (Group) | Group (authz projection) |
| Entity (Role) | Role (authorization projection) |
| Policy | Authorization Policy (downstream artifact) |
| Schema | Authorization schema (downstream) |
| parent relation | Membership/inheritance (authz projection) |
| Context.delegatedBy | Delegation Relationship (context reference) |
## Open Questions
TODO:
- Question 1
- Question 2
- Should canon define a minimal Context projection schema for delegation and
assurance attributes?
- How should Cedar User entities map to Account vs. Service Account vs.
Artificial Agent?
- Are Cedar Role entities always authorization projections, or can they mirror
canonical Role relationships?
- Should entity UID format be standardized in downstream recommendations?
## References
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
- Cedar policy language — https://www.cedarpolicy.com/
- Cedar schema format — https://www.cedarpolicy.com/policies/syntax-schema.html
- AWS Verified Permissions — https://docs.aws.amazon.com/verifiedpermissions/

98
research/authorization-relationships/cerbos-abac-derived-roles.md
View File

@@ -1,50 +1,114 @@
# Cerbos Abac Derived Roles
# Cerbos ABAC Derived Roles
## Source Type
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
Product documentation and open-source implementation reference for Cerbos
policy decision point with derived roles and attribute-based conditions.
## Domain
TODO: Classify the source domain.
Policy-based authorization, attribute-driven role derivation, and resource-centric
access control.
## Why This Source Matters
Cerbos ABAC/RBAC policy concepts, derived roles, resources, principals, and conditions.
Cerbos combines resource policies, principal attributes, and derived roles —
a pattern common in SaaS where permissions depend on both identity attributes
and resource ownership context.
## Key Concepts
TODO:
- concept 1
- concept 2
- concept 3
- **Principal**: subject of authorization request with `id` and `roles` plus
optional attributes.
- **Resource**: target with `kind`, `id`, and attributes (owner, department,
classification).
- **Action**: operation requested on resource.
- **Policy**: YAML/JSON rules binding roles and conditions to allow/deny/effect.
- **Derived roles**: dynamically computed roles from principal + resource
attributes (e.g., `owner` when `principal.id == resource.attr.owner`).
- **Static roles**: assigned roles on principal at request time.
- **Condition**: CEL expression over principal, resource, and request metadata.
- **Scope**: policy namespace for multi-tenant isolation (`scope` field).
- **AuxData**: JWT claims or external data enriching principal at check time.
- **Effect**: ALLOW, DENY, or conditional variants with rule ordering.
## Relevant Terminology
TODO: Extract terms used by the source and note their source-specific meaning.
| Term | Source meaning |
| --- | --- |
| Principal | Requesting party with id, roles, attributes. |
| Resource | Entity with kind, id, and attributes. |
| Derived role | Role computed from attribute matching rules. |
| Static role | Pre-assigned role on principal. |
| Policy | Declarative allow/deny rules. |
| Scope | Tenant or environment partition for policies. |
| Condition | Boolean expression over request context. |
| AuxData | Supplemental principal data (e.g., JWT). |
| kind | Resource type discriminator. |
| attr | Attribute bag on principal or resource. |
## Modeling Assumptions
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
- **Authorization is resource-centric** with policies attached to resource kinds.
- **Roles can be derived at evaluation time** from attribute equality or
relationships encoded in attributes.
- **Principal attributes may come from JWT** or external identity system.
- **Ownership is often modeled as resource attribute**, not explicit relationship.
- **Scope provides tenant isolation** for policy sets.
- **No graph traversal** for permissions; derivation is attribute-based.
- **Identity system supplies principal id and roles**; Cerbos does not store
identity records.
## Identity-Canon Implications
TODO: Explain what this source suggests for the canonical identity model.
- Cerbos **Principal** maps to **Authorization Principal** projection.
- **Resource** maps to **Authorization Resource** projection.
- **Derived role** (e.g., owner) should trace to canonical **Ownership
Relationship** or **Membership** when possible, not only attribute equality.
- Encoding `resource.attr.owner = principal.id` collapses relationship into
attribute — canon should prefer explicit Relationship with authz projection.
- **Scope** maps to **Scope** / **Tenant** for policy partition.
- **AuxData JWT claims** map to **Claim** inputs to authorization projection.
- Supports S05 (admin roles), S10 (service principal attributes), but risks
hiding relationships in attributes (tension with **P5**).
## Terminology Conflicts
TODO: Record where this source uses terms differently from other sources.
- **Principal vs. User**: Cerbos principal id often equals user id from app DB.
- **Owner**: derived role "owner" vs. Ownership Relationship vs. resource
attribute.
- **Role**: derived role vs. static IAM role vs. canonical Role relationship.
- **Scope vs. Tenant**: Cerbos scope is policy namespace; may not equal tenant.
- **Attributes vs. Profile**: principal attributes overlap with profile fields.
## Candidate Canonical Mappings
TODO: Map source-specific concepts to identity-canon candidate concepts.
| Cerbos concept | Candidate canonical concept |
| --- | --- |
| Principal | Authorization Principal |
| Resource | Authorization Resource |
| Action | Authorization Action |
| Static role | Role (authorization projection) |
| Derived role | Role derived from Relationship (preferred) or attribute rule |
| Policy | Authorization Policy (downstream) |
| Scope | Scope / Tenant (policy partition) |
| Principal attributes | Profile/Claim inputs to projection |
| Resource attributes | Resource metadata + Ownership hints |
| AuxData (JWT) | Claim + Authenticated Subject context |
| Condition | Request context projection |
## Open Questions
TODO:
- Question 1
- Question 2
- Should canon explicitly discourage encoding Ownership as resource attribute
without a backing Relationship?
- How should derived roles from group membership sync with canonical Membership
edges?
- Does Cerbos scope map 1:1 to Tenant, or also to Application Scope?
- Should JWT AuxData be documented as standard Authenticated Subject →
Principal projection path?
## References
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
- Cerbos documentation — https://docs.cerbos.dev/
- Cerbos derived roles — https://docs.cerbos.dev/cerbos/latest/policies/derived_roles
- Cerbos scopes — https://docs.cerbos.dev/cerbos/latest/policies/scope_policy

95
research/authorization-relationships/openfga-modeling.md
View File

@@ -1,50 +1,111 @@
# Openfga Modeling
# OpenFGA Modeling
## Source Type
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
Product documentation and open-source implementation reference for OpenFGA
authorization modeling (Zanzibar-inspired).
## Domain
TODO: Classify the source domain.
Relationship-based access control modeling, authorization schema design, and
multi-tenant permission systems.
## Why This Source Matters
OpenFGA authorization models, relationship tuples, users, objects, and relations.
OpenFGA provides a concrete, documented modeling language for Zanzibar-style
relationship tuples with authorization models, stores, and checks.
## Key Concepts
TODO:
- concept 1
- concept 2
- concept 3
- **Authorization model**: declarative schema of types, relations, and
permission definitions.
- **Type definition**: object type with relations and optional `define` rules.
- **Relation**: named edge on a type; may allow direct assignment or computed
rules.
- **Define / rewrite rules**: union (`+`), intersection, exclusion, and
inheritance (`from relation`).
- **Tuple**: `user:type#relation@object:type` stored fact.
- **Userset**: indirect reference such as `user:anne#member@group:engineering`.
- **Store**: isolated tuple set with its own model.
- **Check / ListObjects / ListUsers**: query APIs.
- **Contextual tuples**: ephemeral tuples supplied at check time.
- **Conditions**: CEL-based contextual rules on relations (newer versions).
## Relevant Terminology
TODO: Extract terms used by the source and note their source-specific meaning.
| Term | Source meaning |
| --- | --- |
| User (in tuple) | Subject identifier in `user:` namespace. |
| Object | Entity in `object:` namespace with type. |
| Relation | Named permission edge on a type. |
| Type | Schema class for objects (document, folder, organization). |
| Model | Collection of type definitions. |
| Store | Isolated authorization dataset. |
| define | Computed relation rule. |
| from | Inheritance from related object's relation. |
| contextual tuple | Runtime-only tuple for conditional checks. |
## Modeling Assumptions
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
- **Model-first design**: relations are declared in schema before tuples are written.
- **User and object IDs are opaque strings**; no embedded identity semantics.
- **Organization/tenant patterns** are modeled as types (e.g., `organization`,
`tenant`) with `member`, `admin` relations.
- **Inheritance chains** (folder contains document) are common modeling pattern.
- **Store isolation** provides multi-tenant authorization separation.
- **Identity management is external**; OpenFGA consumes identifiers.
- **Permissions are computed**, not stored as standalone grants.
## Identity-Canon Implications
TODO: Explain what this source suggests for the canonical identity model.
- OpenFGA aligns with Zanzibar mappings; adds explicit **authorization model**
as schema artifact (downstream, not canonical).
- Type definitions like `organization#member` parallel **Organization** +
**Membership Relationship** but in authz projection.
- **Store** maps to **Authorization Domain** Scope or tenant-scoped authz partition.
- `user:` prefix in tuples maps to **Authorization Principal** identifier.
- Contextual tuples support request-time **Delegation** context without
persisting relationship.
- Model examples for parent-child org hierarchies support S03, S04, S05.
- Reinforces **P6**: tuples are projections from actors/relationships.
## Terminology Conflicts
TODO: Record where this source uses terms differently from other sources.
- **User**: OpenFGA `user:` is tuple subject prefix, not human or account.
- **Organization type**: authz type ≠ Organization collective actor unless
explicitly linked.
- **Member relation**: authz member ≠ community member without model alignment.
- **Store vs. Tenant**: store is authz isolation; tenant is broader scope.
- **Permission vs. Relation**: permissions are computed from relations; products
often say "permission" for relation name.
## Candidate Canonical Mappings
TODO: Map source-specific concepts to identity-canon candidate concepts.
| OpenFGA concept | Candidate canonical concept |
| --- | --- |
| Tuple | Relationship Tuple (authorization projection) |
| user: (subject) | Authorization Principal |
| object: (entity) | Authorization Resource |
| Relation | Relationship type (authz-implied) |
| Type definition | Authorization schema (downstream) |
| Store | Authorization Domain Scope |
| define/from rules | Authorization derivation (non-canonical) |
| organization#member | Membership Relationship (projection) |
| organization#admin | Administration Relationship (projection) |
| contextual tuple | Delegation context (ephemeral) |
## Open Questions
TODO:
- Question 1
- Question 2
- Should canon document standard OpenFGA type patterns (org/team/resource) as
downstream recommendations only?
- How should principal identifiers be aligned with Account IDs vs. Authenticated
Subject `sub` values?
- Do conditional (CEL) relations require canonical Context as a first-class
projection?
- Should one Store always map 1:1 to a Tenant Scope?
## References
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
- OpenFGA documentation — https://openfga.dev/docs
- OpenFGA modeling guide — https://openfga.dev/docs/modeling
- OpenFGA configuration language — https://openfga.dev/docs/configuration-language

95
research/authorization-relationships/zanzibar-rebac.md
View File

@@ -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