Confirm the approval-claim as the step-1 PEP artifact
approval-engine raised APPROVAL-IN-0002: secrets-engine's PEP validator expects a flex-auth ActionAuthorization but fetches the approval-claim endpoint that GH-DEC-2026-003 names as step 1. Two objects on one path. GH-IN-0002 records the intake; GH-DEC-2026-005 resolves it. The claim is the step-1 artifact and always was — ActionAuthorization is unratified, has no valid_now field, and cannot be served from a step-1 call. The addition beyond confirmation is doctrine: a PEP validates each artifact against the layer that owns its data, and no PIP republishes the PDP's decision. The provenance.authority == "state-hub" requirement is struck; State Hub is a read model and holds no runtime approval authority. docs/contracts/approval-consumption.md carries the amendment at the sequence itself so implementers find it there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WtJBr77gMFLrN93iEevqQJ Assistant: claude-code Assistant-Model: opus Assistant-Process: 425128@bnt-lap001 Assistant-Session: f5944d8b-dac4-4e1a-87eb-8b3d8f314a63
This commit is contained in:
parent
60e2e7de65
commit
1a920a5490
3 changed files with 115 additions and 3 deletions
|
|
@ -3,8 +3,9 @@
|
|||
**Owner:** gate-house
|
||||
**PIP:** approval-engine
|
||||
**PDP:** access-engine (currently flex-auth)
|
||||
**Status:** normative for GH-WP-0002-T06; recorded as `GH-DEC-2026-003`
|
||||
**Date:** 2026-08-29
|
||||
**Status:** normative for GH-WP-0002-T06; recorded as `GH-DEC-2026-003`,
|
||||
amended by `GH-DEC-2026-005` (step-1 artifact and split validation)
|
||||
**Date:** 2026-09-06
|
||||
**Statute:** `net-kingdom/canon/standards/security-layer-model_v0.7.md` §9.4, §9.7.3–4, §16
|
||||
**Blocks:** `APPROVAL-WP-0001-T05`, `FLEX-WP-0017-T05`
|
||||
|
||||
|
|
@ -30,6 +31,35 @@ companion §5 already treats as PEP-shaped.
|
|||
Holding a claim with `valid_now: true`, or an ALLOW against that claim, is not
|
||||
authority to act. The consume is.
|
||||
|
||||
## What each step's artifact is
|
||||
|
||||
Amended by `GH-DEC-2026-005`.
|
||||
|
||||
**Step 1 serves the approval-claim** (`approval-engine/docs/approval-claim.md`).
|
||||
That is the artifact `valid_now` belongs to, and it is the only object the claim
|
||||
endpoint serves. flex-auth's proposed `ActionAuthorization` is **not** required
|
||||
here, is not served here, and MUST NOT be served from this endpoint: a step-1
|
||||
response cannot contain a step-2 decision.
|
||||
|
||||
**A PEP validates across both artifacts it already fetches**, and each against
|
||||
the layer that owns its data:
|
||||
|
||||
| Artifact | Source | What the PEP checks |
|
||||
| --- | --- | --- |
|
||||
| approval-claim | step 1, `approval-engine` (PIP) | binding digest, validity window, consumption state, observation freshness, issuer |
|
||||
| `DecisionEnvelope` | step 2, `access-engine` (PDP) | exact `CheckRequest` match, policy package and version pin |
|
||||
|
||||
A PIP MUST NOT republish the PDP's decision, and a PEP MUST NOT accept the
|
||||
approval fact from the decision artifact or the decision from the approval
|
||||
artifact. Composing the two into one served object is a separate, post-decision
|
||||
artifact at a separate endpoint if it is ever ratified — not a change to the
|
||||
claim.
|
||||
|
||||
**Claim provenance is not State Hub.** A PEP MUST NOT require
|
||||
`provenance.authority == "state-hub"` on the claim. State Hub is a read model and
|
||||
holds no runtime approval authority; the issuer to check is the engine that
|
||||
served the claim.
|
||||
|
||||
## Why consume is before the side effect
|
||||
|
||||
§9.7.3 says consumption MUST NOT be inferred from a decision record. That
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue