tegwick
f67e7a3566
Reviews security-layer-model v0.8 as text (net-kingdom@66eeaba), completing the round this repo promised after sending only one finding and explicitly telling gate-house to treat it as one finding rather than an assent. Three findings. The substantive one is that §6.4 announces "Four obligations" and lists five: v0.7 had four, v0.8 added obligation 5 and left the count. That obligation is the one carrying correspondence-by-identity, the PIP/PDP separation and the replay-identity property -- the whole GH-DEC-2026-003/005/008 chain, and the rule that binds this engine at issue time. A consumer implementing "the four obligations of §6.4" can omit precisely the one governing how it compares an approval to a decision. It has already propagated into gate-house's own correspondence. Second, §17 states four artifacts are required and owned by Taxonomy while its body removes two from Taxonomy, then calls three artifacts' ownership "still proposed" and settles one of them in the same sentence. Two are genuinely unsettled. §15 claims §17's stale ownership paragraph was corrected; the correction did not reach the count sentence or the closing status. Third and minor, the §18-to-§20 numbering hole is explained only in a late §16 bullet. The record is marked as a derived, dated artifact naming its source commit, per §12's own rule -- the rule this repo proposed and asked to own none of. Also records what was read and what was not, what was found sound, and two candidate findings dropped after checking, since a finding count means nothing without the count checked and discarded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PM5HnEAhokxdfcPqBNpT7D Assistant: claude-code Assistant-Model: opus Assistant-Process: 715850@bnt-lap001 Assistant-Session: eb557e93-7cb1-45d0-9e57-7d15b3edc60e |
||
|---|---|---|
| approval_engine | ||
| deploy | ||
| docs | ||
| examples | ||
| history | ||
| intakes | ||
| schemas | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| cadence.yaml | ||
| Containerfile | ||
| INTENT.md | ||
| layer.yaml | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
approval-engine
The approval as a durable, authenticated, consumable object — issued before an action, verified at the moment of use, and provably not replayable.
An Engine, role PIP, in the NetKingdom security layer model (statute v0.7,
accepted; operative form net-kingdom/SECURITY-COMPANION.md). It answers one
question, totally and decidably:
Is this approval valid right now — for this exact action, target, actor, and purpose — and has it already been used?
It does not decide whether the action is permitted. That is access-engine,
which stays NetKingdom's only policy decision point. An approval is one input to
that decision.
Deliberately small, boring, and strict: atomic supersession and single
consumption are what make Canon test T-06 — Approval Replay passable.
Flexibility here would be a defect. Graded, evidence-based progression belongs to
maturity-engine; the two engines are deliberate opposites.
See INTENT.md and SCOPE.md. Declaration: layer.yaml.
Claim: docs/approval-claim.md.
Consume: docs/approval-consumption.md.
Caller auth: docs/caller-authentication.md.
PEP sequence: docs/pep-integration.md.
Origin: flex-auth FLEX-DEC-2026-001, raised while assenting to the security
layer model.
make test
approval-engine migrate --db approvals.sqlite
approval-engine verify --db approvals.sqlite
approval-engine serve --db approvals.sqlite \
--jwt-issuer https://auth.netkingdom.local \
--jwt-audience approval-engine \
--jwks-url http://key-cape.sso.svc.cluster.local:8080/jwks
POST /v1/approvals/{id}/consume implements GH-DEC-2026-003: the PEP
atomically spends the approval before the protected side effect. Same-digest
retries are idempotent; a different digest conflicts.
Production operations, caller scopes, audit delivery, and PEP sequencing are
documented in docs/storage-operations.md, docs/caller-authentication.md,
docs/outbox-contract.md, and docs/pep-integration.md. The checked-in
StatefulSet deliberately refuses production startup without a migrated
persistent store, KeyCape JWT verification, and authenticated audit delivery.