How to Write Policy

• principal
• action (represented as operation)
• resource
• context

​

Why PARC

• It keeps authorization intent explicit instead of hiding behavior in ad hoc payload fields.
• It supports both RBAC and ABAC patterns without changing the contract shape.
• It maps well to relationship operations like associate, where actor and resource context matter.

​

Request Shape

• workspace_id (required)
• object_type (required)
• operation (required)
• principal (required object)
• payload (required object)
• resource (optional object)
• context (optional object)
• policy_context (optional object)

{
  "workspace_id": "workspace-demo",
  "principal": {
    "type": "token",
    "id": "api:ops-bot",
    "attributes": {
      "role": "admin",
      "hasVerifiedEmail": true
    }
  },
  "object_type": "association_edge",
  "operation": "associate",
  "resource": {
    "type": "association_edge",
    "id": "assoc-edge-001"
  },
  "context": {
    "source": "internal"
  },
  "payload": {
    "source_id": "record-001",
    "target_id": "record-002"
  }
}

​

Policy Conditions (when-style)

• left: dot-path into normalized request context
• op: eq or neq
• right: comparison value

• operation
• object_type
• principal.*
• resource.*
• context.*
• payload.*

{
  "policy_key": "association_admin_only",
  "effect": "deny",
  "conditions": [
    { "left": "operation", "op": "eq", "right": "associate" },
    { "left": "principal.attributes.role", "op": "neq", "right": "admin" }
  ],
  "deny_reason_code": "associate_forbidden_non_admin",
  "deny_reason_message": "Only admin can associate records.",
  "rules": []
}

​

Validation and Execute Boundary

1. request validation and normalization
2. policy evaluation

​

Compatibility Notes

• operation=associate is supported in v0.1.2.
• Existing v1 response contract fields remain stable.
• conditions are additive and optional; policies without conditions keep previous behavior.