diff --git a/INTENT.md b/INTENT.md index ac200e6..0430d5d 100644 --- a/INTENT.md +++ b/INTENT.md @@ -5,23 +5,15 @@ > Staff**, layered by determinism and by the kind of artifact each layer produces. > Findings and the argument behind them: > `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`. -> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed), -> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001. +> The model as currently stated is `gate-house/INTENT.md` § "Where Gate House Sits"; +> it is ruled to become a `net-kingdom/canon/standards/` standard, not yet written. > > The layer rule that binds every repository: **Staff never touches tooling > directly. It acts only through engine APIs.** > -> **This repository is Engine — and the only policy decision point in NetKingdom.** -> Reframed on 2026-08-28 per `gate-house/decisions/decisions.md` GH-DEC-2026-001: -> "control plane" dropped as Staff vocabulary, the layer and the exclusive -> decision-point role stated, policy authoring separated from policy evaluation, -> gate-house's authority context adopted as input claims, and the access -> lane/rule demarcation recorded. +> **This repository is Engine — and the only policy decision point in NetKingdom.** The largest adaptation of the review. (1) **Rename to `access-engine`** — ruled, with sequence: reframe this INTENT first, rename second as a governed migration, since the rename touches `FLEX-WP` prefix ownership, State Hub identifiers, ops-warden's tables, zone-engine's binding boundary text, and secrets-engine integrations. `auth-engine` was rejected because key-cape owns authentication and `auth-` keeps the ambiguity. (2) **Drop the "control plane" self-description** — that is Staff vocabulary for an Engine-layer repository. (3) **Split policy authoring from policy evaluation**: authoring, governing, and versioning policy is Staff work (gate-house); evaluating it deterministically and in-path is this repository's, and stays exclusively so. This is the constructive resolution of the `FLEX-WP-0017` overlap — gate-house designs the approval contract, access-engine validates approvals at decision time. (4) Consume gate-house's **authority context** (principal / actor / runtime identity / mandate / operating mode) as input claims. (5) Record the demarcation: **ops-warden and ops-mason own access lanes; access-engine owns access rules.** > -> *Reframe applied. One item remains: the ruled rename to `access-engine`, which -> is a separate governed migration — it touches `FLEX-WP` prefix ownership, State -> Hub identifiers, ops-warden's routing tables, zone-engine's binding boundary -> text, and secrets-engine integrations — and is not authorized by GH-DEC-2026-001.* +> *This note records what should change. The body below is not yet adapted.* > This file captures **why this repository exists**, the **direction it is > moving toward**, and the **kind of system it is meant to become**. @@ -30,19 +22,10 @@ ## Intent -Flex-auth is a policy-as-code authorization registry and **decision engine** -for organizations that want to grow from simple access rules into -enterprise-grade authorization without giving up clear ownership, local -development ergonomics, or inspectable policy decisions. - -It is an **Engine** in the NetKingdom security layer model -(`net-kingdom/canon/standards/security-layer-model_v0.1.md`): a deterministic -API for a modeled concept, where the same authoritative input state yields the -same result. It is deliberately not described as a control plane — that is -Staff-layer vocabulary, and flex-auth is not Staff. - -Within NetKingdom it is **the only policy decision point** (standard §6). No -other repository, in any layer, may render or cache an authorization decision. +Flex-auth is a policy-as-code authorization registry and control plane for +organizations that want to grow from simple access rules into enterprise-grade +authorization without giving up clear ownership, local development ergonomics, +or inspectable policy decisions. It is the **authorization layer** in the path from verified identity to protected resources: @@ -88,55 +71,24 @@ authenticated; flex-auth decides what that actor is allowed to do. - The canonical identity claim contract and required claims. - Coarse roles, scopes, and assurance claims. -### Flex-Auth Owns the Decision +### Flex-Auth Owns Authorization -- **Evaluation — exclusively.** Rendering the decision, in-path, deterministically. - Protected-system registration. - Resource namespaces and resource hierarchy. - Canonical action vocabulary. -- The policy-as-code mechanism: package format, tests, versions, and rollout. +- Policy-as-code packages, tests, versions, and rollout. - Mapping enterprise groups, app roles, scopes, tenants, and assurance claims into resource-specific authorization. - Relationship facts and inherited access. - PDP adapter coordination. - Decision logging, explanations, and audit export. -### Gate House Owns the Doctrine the Decision Serves - -Authoring and governing security doctrine is Staff work. `gate-house` owns the -invariants policy must satisfy, the authority ceilings, the assistant and -autonomous operating modes, and the **authority context** — principal, actor, -runtime identity, tenant, mandate, operating mode — which flex-auth consumes as -input claims alongside verified identity claims. - -The division is between *authoring the rules of the game* and *rendering a -result*: gate-house designs the approval contract and the invariants; flex-auth -validates approvals and renders decisions at request time. Neither can do the -other's half. Policy **content** for a given protected system remains authored -by that system's owner, within flex-auth's mechanism and gate-house's doctrine. - -Gate House holds no runtime position and never renders a decision. A -deterministic authority boundary inside a non-deterministic layer would violate -the invariant the estate is built on. - ### Protected Systems Own Enforcement Applications remain policy enforcement points. They extract resource metadata, call flex-auth for decisions, enforce allow/deny/redact results, and emit local diagnostics. They do not own central policy administration. -### Access Lanes Are Not Access Rules - -The estate uses "access" for two different things, and the demarcation is -normative (standard §8): - -- **ops-warden and ops-mason own access lanes** — how a worker reaches a host: - routes, tunnels, SSH certificates, credential lanes. -- **flex-auth owns access rules** — whether an actor may act at all. - -A lane delivers someone to the door. This repository decides whether the door -opens. Neither substitutes for the other, and neither owns the other's word. - ## Design Principles - Policy is code: versioned, reviewed, tested, and explainable. diff --git a/intakes/intakes.md b/intakes/intakes.md deleted file mode 100644 index 20854ff..0000000 --- a/intakes/intakes.md +++ /dev/null @@ -1,34 +0,0 @@ -# Intake records - -## FLEX-IN-0001 — Assent requested: Engine framing, access-engine rename, and the authoring/evaluation split - -```yaml -id: FLEX-IN-0001 -kind: intake -title: 'Assent requested: Engine framing, access-engine rename, and the authoring/evaluation - split' -status: open -origin: cross-repo -origin_ref: gate-house GH-DEC-2026-001 -priority: high -owner: flex-auth -requested_by: gate-house -standard: net-kingdom/canon/standards/security-layer-model_v0.1.md -description: 'gate-house asks flex-auth to assent to three items ratified in GH-DEC-2026-001, - following the estate precedent that a boundary is drawn on review by the other side - rather than asserted — as flex-auth itself did to zone-engine. (1) flex-auth is - Engine-layer and is NetKingdom’s only policy decision point; the INTENT reframe - is already applied (commit fe46122) and can be revised or reverted if wrong. (2) - The ruled rename flex-auth -> access-engine, NOT yet authorized to execute: it is - a separate governed migration touching FLEX-WP prefix ownership, State Hub identifiers, - ops-warden routing tables, zone-engine boundary text, and secrets-engine integrations. - auth-engine was rejected because key-cape owns authentication. (3) The split: flex-auth - owns evaluation exclusively plus the policy-as-code mechanism; gate-house owns doctrine, - invariants, authority ceilings, operating modes, and the authority context consumed - as input claims; policy content stays with the protected system owner. This resolves - the FLEX-WP-0017 overlap — gate-house designs the approval contract, flex-auth validates - approvals at decision time. Assent, revision, or rejection all acceptable; the standard - stays proposed until this is answered.' -created: '2026-08-28T19:30:03.602578Z' -updated: '2026-08-28T19:30:03.602578Z' -```