commerce-canon/research/authorization-relationships/cedar-principal-action-resource-context.md

# 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/