Distribute frozen federation corpus by concept destination

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b

infospace/assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md

@@ -0,0 +1,114 @@
+# Cedar Principal Action Resource Context
+
+## Source Type
+
+Standard and product reference. Cedar policy language (AWS Verified Permissions)
+with principal-action-resource-context evaluation model.
+
+## Domain
+
+Fine-grained authorization, policy-based access control, and ABAC/RBAC
+hybrid evaluation.
+
+## Why This Source Matters
+
+Cedar's principal-action-resource-context distinction preserves orthogonality
+between identity, action, resource, and request context.
+
+## Key Concepts
+
+- **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
+
+| 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
+
+- **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
+
+- 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
+
+- **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
+
+| 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
+
+- 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
+
+- 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/

infospace/assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md

@@ -0,0 +1,114 @@
+# Cerbos ABAC Derived Roles
+
+## Source Type
+
+Product documentation and open-source implementation reference for Cerbos
+policy decision point with derived roles and attribute-based conditions.
+
+## Domain
+
+Policy-based authorization, attribute-driven role derivation, and resource-centric
+access control.
+
+## Why This Source Matters
+
+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
+
+- **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
+
+| 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
+
+- **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
+
+- 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
+
+- **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
+
+| 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
+
+- 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
+
+- 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

infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md

@@ -0,0 +1,111 @@
+# OpenFGA Modeling
+
+## Source Type
+
+Product documentation and open-source implementation reference for OpenFGA
+authorization modeling (Zanzibar-inspired).
+
+## Domain
+
+Relationship-based access control modeling, authorization schema design, and
+multi-tenant permission systems.
+
+## Why This Source Matters
+
+OpenFGA provides a concrete, documented modeling language for Zanzibar-style
+relationship tuples with authorization models, stores, and checks.
+
+## Key Concepts
+
+- **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
+
+| 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
+
+- **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
+
+- 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
+
+- **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
+
+| 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
+
+- 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
+
+- OpenFGA documentation — https://openfga.dev/docs
+- OpenFGA modeling guide — https://openfga.dev/docs/modeling
+- OpenFGA configuration language — https://openfga.dev/docs/configuration-language

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

@@ -0,0 +1,111 @@
+# 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