diff --git a/docs/bounded-execution-contract-table.md b/docs/bounded-execution-contract-table.md index 8bde1f5..e2f6d73 100644 --- a/docs/bounded-execution-contract-table.md +++ b/docs/bounded-execution-contract-table.md @@ -96,12 +96,14 @@ Two facts frame this column: - `principal_type` is human; - the assurance is aal2; - the subject is not the executor itself. - - approval-engine also has `required_assurance`. The executor doesn't send it, and checks aal2 itself - ("recorded, not enforced"). -- **Proposal:** - - `approval_entry` names the failed field: subject, principal type or assurance. That alone would have replaced - diagnostic pod 4. - - Whether to send `required_assurance` is a question for approval-engine, not a local change. + - the deployed approval-engine records assurance but doesn't enforce it, so the executor checks aal2 itself. +- **Proposal:** `approval_entry` names the failed field: subject, principal type or assurance. That alone would + have replaced diagnostic pod 4. +- **Already answered by the owner:** approval-engine replied on 2026-10-31 (message `756016f9`, + `docs/decision-services-alignment-answer.md`, `e9e9f93`). `required_assurance` is in source as schema v7: entries + below the floor are refused with 403, the claim with `assurance_unsatisfied`, and consume with 409. It waits for a + v7 image release and a founder-run rollout with a pre-v7 backup. The executor keeps its own aal2 check until then, + and sends `required_assurance` once v7 is live. This is a dependency, not an open decision. ### E4: informed-decision intake @@ -220,7 +222,7 @@ resolve through the rapp config and must equal the routing recipient for the mem - E5: who owns the approver and routing; - E2: KeyCape client registration with no KeyCape rapp; - E7: the LLDAP, Authelia and KeyCape runtime owner in `sso`; - - E3: whether approval-engine should enforce `required_assurance`. + - E3 is not open: approval-engine enforces `required_assurance` from v7, which waits for its release. - **Transparency findings for T03:** - `executor-lanes.py` lane errors without a cause; - `approval_entry` without the failed field. @@ -234,7 +236,7 @@ NK-WP-0058-T09, as of 2026-11-05. It uses the same revisions as part 1, plus acc | --- | --- | --- | --- | --- | --- | --- | | C1 | CCR lifecycle ↔ net-kingdom lane tooling | railiance-platform: `credential-change-requests/CCR-2026-0058`, `-0059`, `scripts/credential-change.py` | `tools/service-binds/executor-lanes.py`, which imports three platform helper modules; `pilot-run.sh` | Local: `tests/test_executor_lanes.py` copies `railiance-platform/scripts` | `window-close` failed as bare `LaneError` (identity phase) | **merge**; **owner decision** on a supported interface | | C2 | Case-type bytes ↔ broker admission | net-kingdom `security-case-types/*/type.yaml` (canon). Pin: railiance-platform `scripts/keycape_client_secret_generate.py ACKNOWLEDGED_TYPES` (sha256) | railiance-platform credential broker | none in net-kingdom. The README errata warns against edits | none (both hashes match today) | **keep**; add a net-kingdom guard test | -| C3 | Case status ↔ broker gate | net-kingdom `security-cases/*.yaml` (`status`, `acceptance`); canon `canon/standards/security-case-types_v0.1.md` | broker (`case_not_materialized`), founder runbooks | Local: the broker case check on a synthetic copy | none. The status is committed by hand from a founder message | **keep**; small **owner decision** on who materializes | +| C3 | Case status ↔ broker gate | net-kingdom `security-cases/*.yaml` (`status`, `acceptance`); canon `canon/standards/security-case-types_v0.1.md` | broker (`case_not_materialized`), founder runbooks | Local: the broker case check on a synthetic copy | none. The status is committed by hand from a founder message | **keep** (who materializes: tracked in MASON-WP-0010-T03) | | C4 | KeyCape client secret delivery | railiance-platform: CCR-2026-0060 and -0061, `manifests/nk-bind-executor-eso.yaml`, template `keycape-issuer-eso.yaml` | net-kingdom `sso-mfa/k8s/keycape/deployment.yaml` env `KEYCAPE_NK_BIND_EXECUTOR_APPROVAL_CLIENT_SECRET`; `keycape-client.py env_secret_name()`; executor E1 lane | railiance-platform `tests/test_nk_bind_executor_custody.py`, `test_keycape_client_secret_generate.py`; net-kingdom `sso-mfa/k8s/keycape/test_keycape_client.py`; no cross test | none (custody verify passed 2026-11-04) | **merge** | | C5 | audit-core sender bearer custody | railiance-platform: CCR-2026-0063 (path `platform/workloads/net-kingdom/bounded-executor/audit-sender`, field `AUDIT_TOKEN`), ESO to `sso/bounded-executor-tokens` key `audit-core`. Seed: audit-core `scripts/seed-nk-bounded-executor-sender.py` (single seeder) | rapp `templates/job.yaml` mount; executor `audit_core.token_file`; railiance-platform `nk_bind_executor_custody.py verify` | audit-core `tests/test_seed_nk_bounded_executor_sender.py`; railiance-platform custody tests; no cross test | While being prepared: competing seeders in two repos and two Secret names. Settled in RPF-WP-0069 and AUDIT-WP-0018-T04; one stale copy remains | **merge**; **delete** the stale design text | | C6 | Executor's submitter profile | **Two owners, one fact.** informed-decision `deploy/lifecycle/intake-submitters.json` and access-engine `examples/informed-decision-present-existing-review/policy.md present_existing_profiles` (v14) | informed-decision intake; access-engine decisions; executor `executor_identity` (rapp config) | none across the three | none | **merge**; **owner decision** on which is the source | @@ -274,8 +276,10 @@ NK-WP-0058-T09, as of 2026-11-05. It uses the same revisions as part 1, plus acc - **Gap:** - the status is committed by hand by claude-code after the founder reports steps 0–3. No receipt links them; the T04 state file could record that link. - - the canon names ops-mason as the materializer, but railiance-platform's go-live steps did it here. Small - **owner decision:** amend the canon, or route materialization through ops-mason. + - the canon names ops-mason as the materializer, but railiance-platform's go-live steps did it here by hand. + That isn't a new question: ops-mason's case build path (`ops-mason build --case`, MASON-WP-0010-T03) exists and + waits on railiance-platform's structural evidence. ops-mason reviewed and test-rendered this case on + 2026-10-31 (message `91e2205f`). Tracked there; no new routing. ### C4: KeyCape client secret delivery @@ -346,7 +350,6 @@ access-engine's policy is the source, with the other checked against it. Until t (an owner request). - **owner decision:** - C1: a supported platform interface for window roles (railiance-platform); - - C3, small: who materializes. The canon names ops-mason; railiance-platform did it here; - C6: the source of the submitter profile (informed-decision and access-engine); - C7: routing and visibility (NK-WP-0057, together with E5). - **For T07:** the hard-coded path and cluster UID in audit-core's seeder. diff --git a/workplans/NK-WP-0057-decision-routing-by-responsibility.md b/workplans/NK-WP-0057-decision-routing-by-responsibility.md index ca812d6..c5b43e7 100644 --- a/workplans/NK-WP-0057-decision-routing-by-responsibility.md +++ b/workplans/NK-WP-0057-decision-routing-by-responsibility.md @@ -89,6 +89,27 @@ Cover at least: For the bounded-execution path, start from the NK-WP-0058 contract table (NK-WP-0058-T01, T09, T10) instead of inventorying it again. Its rows marked "needs an owner decision" are inputs here. +**Inputs routed from NK-WP-0058 (2026-11-05).** All are in `docs/bounded-execution-contract-table.md`: + +- **E5 + C7, approver and routing.** The approver is defined in four places: the admission's `approvers`, the + rapp's `approver_subjects`, informed-decision's `review-groups.json`, and KeyCape's `sub` format. Nothing checks + that they agree. access-engine policy v14 lists a memo only to its `review_recipient`, so informed-decision's + routing table decides who can approve, without the admission seeing it. This cost the 2026-11-04 window. The + interim check is NK-WP-0058-T03. +- **E2, KeyCape client registration.** ADR-0015 moves runtime packages to `rapp-*`, but there is no KeyCape rapp, + so client registration (env binding and `keycape-client.py apply`) runs from net-kingdom's reference manifests. + Who owns it: net-kingdom, key-cape, or a new rapp? +- **E7, `sso` runtime owners.** `docs/responsibility-map.md` names no runtime owner for LLDAP, Authelia or KeyCape + in `sso`. SCOPE calls `sso-mfa/k8s/` "migration inputs, not blanket authority". + +Routed to their owners instead (NK-WP-0058 records the message ids): + +- C1 and O1 to railiance-platform; +- O2 to ops-warden; +- C6 to informed-decision and access-engine. + +E3 was already answered by approval-engine on 2026-10-31. C3 is tracked in ops-mason MASON-WP-0010-T03. + **Done when:** an inventory table with sources, and the list of routing points in use today (file, owner, what it decides), is in `docs/proposals/`.