Files
flex-auth/workplans/FLEX-WP-0002-standalone-policy-as-code-core.md

191 lines
4.6 KiB
Markdown

---
id: FLEX-WP-0002
type: workplan
title: "Standalone Policy-as-Code Core"
domain: netkingdom
status: todo
owner: flex-auth
topic_slug: flex-auth
planning_priority: P0
planning_order: 20
depends_on_workplans:
- FLEX-WP-0001
created: "2026-05-04"
updated: "2026-05-04"
state_hub_workstream_id: "aa60e183-9a87-4e03-99b0-15786bfa11ae"
---
# FLEX-WP-0002: Standalone Policy-as-Code Core
## Purpose
Implement the standalone flex-auth core: resource registry, subject/group/team
registry, relationship facts, policy packages, deterministic check APIs,
decision envelopes, explainability, local decision logs, and CLI/service entry
points.
This is the first implementation workplan. It should produce a useful local
authorization system before delegating to Topaz, OpenFGA, OPA, or other
external policy engines.
## Design Direction
The core should define flex-auth's own stable vocabulary:
```text
subject + action + resource + context + policy version -> decision
```
Backends may change later, but these envelopes must stay stable:
- protected system
- resource namespace and hierarchy
- action vocabulary
- subject/group/team/tenant identity
- relationship facts
- policy package and version
- decision effect, reason, obligations, diagnostics, provenance
## P2.1 - Define canonical schemas
```task
id: FLEX-WP-0002-T001
status: todo
priority: high
state_hub_task_id: "534e5251-8529-48fe-8cf8-b3b6bc4ec1f4"
```
Define machine-readable schemas for:
- protected system manifest
- resource manifest
- subject/group/team manifest
- relationship fact manifest
- policy package
- policy fixture/test case
- check request
- decision envelope
- audit event
Output: docs, examples, schema files, and validation tests.
## P2.2 - Implement local registry store
```task
id: FLEX-WP-0002-T002
status: todo
priority: high
state_hub_task_id: "d8045124-f0ae-495d-87b5-24fd9528ef93"
```
Implement a local registry for systems, resources, subjects, groups, teams,
tenants, and relationships.
Start with a deterministic file-backed or SQLite-backed store that supports
tests and local development.
## P2.3 - Implement policy package loader and validator
```task
id: FLEX-WP-0002-T003
status: todo
priority: high
state_hub_task_id: "09be0f25-e5ba-42b5-8b2f-36fd0ef2fe6b"
```
Load policy-as-code packages with metadata, rules, fixtures, tests, and
activation metadata.
The first implementation may use a simple declarative rule format as long as
the package boundary leaves room for OPA/Rego, Cedar, and Topaz later.
## P2.4 - Implement deterministic check and batch_check APIs
```task
id: FLEX-WP-0002-T004
status: todo
priority: high
state_hub_task_id: "f6427575-00af-4f3e-ab30-5b9a158343ef"
```
Implement:
```text
check(subject, action, resource, context) -> decision
batch_check(subject, action, resources, context) -> decisions
```
Decisions must include effect, reason, matched policy version, matched rule,
resource metadata, subject metadata, obligations, diagnostics, and provenance.
## P2.5 - Implement list_allowed and explain
```task
id: FLEX-WP-0002-T005
status: todo
priority: medium
state_hub_task_id: "e8fcbabd-4eb6-41d2-a4d5-6f40cc245a7e"
```
Implement:
```text
list_allowed(subject, action, resource_type, filters, context)
explain(decision_id)
```
Use the same decision model as `check` and keep explanations useful for policy
authors and protected-system developers.
## P2.6 - Add local decision log
```task
id: FLEX-WP-0002-T006
status: todo
priority: medium
state_hub_task_id: "2def10c1-4b5f-44a8-8e6b-4c8592fffd43"
```
Persist compact JSONL or SQLite decision logs for local development and audit
experiments. Always record denies, redactions, exports, and emergency actions.
## P2.7 - Add CLI and service skeleton
```task
id: FLEX-WP-0002-T007
status: todo
priority: high
state_hub_task_id: "ee9ae6dd-c31f-4d4e-b238-533a2b8040d4"
```
Provide command-line workflows for:
- validate manifests
- load registry data
- test policy packages
- check one request
- batch check
- explain a decision
Add a minimal service skeleton only after CLI/library behavior is stable.
## P2.8 - Add tests and examples
```task
id: FLEX-WP-0002-T008
status: todo
priority: high
state_hub_task_id: "6cbe572a-2877-4936-8ef3-63b79900fae2"
```
Add examples for local users, groups, teams, project resources, inherited
relationships, and policy fixtures.
## Exit Criteria
- flex-auth can run standalone for local development.
- Policy packages are versioned, validated, and testable.
- Resource registration and relationship facts can drive authorization.
- `check`, `batch_check`, `list_allowed`, and `explain` are implemented.
- Decision output is stable enough for protected systems to integrate against.