From f06f6144a8768035c7279e2bb542ddd1cdb2285d Mon Sep 17 00:00:00 2001 From: codex Date: Sat, 17 Oct 2026 11:28:48 +0200 Subject: [PATCH] Request r4 source review and the four 1.3 owner reviews for NK-WP-0048-T16 Co-Authored-By: Claude Opus 5.5 --- .../nk48-1.3-owner-review/README.md | 53 +++++++++++ .../nk48-1.3-owner-review/net-kingdom.md | 35 ++++++++ .../nk48-1.3-owner-review/ops-warden.md | 26 ++++++ .../nk48-1.3-owner-review/railiance-apps.md | 29 ++++++ .../railiance-platform.md | 32 +++++++ .../nk48-adapters-1.2-review/README-r4.md | 90 +++++++++++++++++++ 6 files changed, 265 insertions(+) create mode 100644 docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/README.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/net-kingdom.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/ops-warden.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-apps.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-platform.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/nk48-adapters-1.2-review/README-r4.md diff --git a/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/README.md b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/README.md new file mode 100644 index 00000000..12440c63 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/README.md @@ -0,0 +1,53 @@ +# Owner review: oidc-browser-relying-party@1.3 successor candidate (NK-WP-0048-T16) + +Requested 2026-10-17 by the founder. **Start only after coordinator review r4** +(`../nk48-adapters-1.2-review/coordinator-review-r4.json`) approves net-kingdom +`1920b13` with no open findings. If r4 rejects anything, these requests are re-frozen +at the fixing revision. + +Admission in Warden (`ops-warden a45cf47`, `case_run.Executor.admit`) requires, for +each step, the type's `execution_descriptors` to contain that exact descriptor +digest. It also requires authenticated evidence for: + +- `owner-descriptor-acceptance:` over the descriptor +- `type-machine-seam-acceptance` over the type +- `catalog-routing-acceptance` over the catalog +- case acceptance, ops-mason materialization and the caller's session + +This review is where each owner decides whether it will give that acceptance for +1.3. Recording the evidence itself is a later step under each owner's own +authenticated path. + +| Owner | Request | Decides | +|---|---|---| +| net-kingdom | [net-kingdom.md](net-kingdom.md) | its three descriptors; the type as a whole (open questions 2 and 3) | +| railiance-platform | [railiance-platform.md](railiance-platform.md) | mint-secret and deliver-secret; mint semantics (question 2) | +| railiance-apps | [railiance-apps.md](railiance-apps.md) | deliver-consumer-secret and hand-over | +| ops-warden | [ops-warden.md](ops-warden.md) | the 1.3 parameter pin (question 1), catalog routing for all seven lanes, question 3 | + +## Common frozen target + +- net-kingdom `1920b134e2b577e74aaac6b59db5fd785f505a3d` +- 1.3 type `security-case-type-revisions/1.3/oidc-browser-relying-party/type.yaml`, + sha256 `3c05a749f28fa25df4d72aa1482a21be4ecc53af44ad17762d673588e2b3a947` +- composition artifact `sso-mfa/k8s/keycape/descriptor-composition-1.3.candidate.json`, + sha256 `64355c314891f7fc951a14e55c197609e892e73628acd43a535974382136961b` +- the open questions are in the 1.3 `README.md`, under "Known limits" + +## How to run each review + +One fresh Claude Code session per owner, started in that owner's repository (for +example `cd ~/railiance-platform && claude`), with none of this or any reviewing +session's context. Each session acts as that repository's owner, reads its own +request file here, and writes `owner-review-.json` in this directory with: + +- a verdict per descriptor it owns: `accept` or `reject`, with reasons +- answers to the open questions assigned to it +- any change it requires to the 1.3 candidate, which would make a new revision and + re-freeze these reviews + +Hard limits for every owner session: source only. No live or native action, no +kubectl, SSH, OpenBao or secret access, and no edits to net-kingdom or ops-warden. +The owner writes only its review file, and records no evidence or acknowledgment. +The founder's 1.3 Decision Memo through informed-decision follows after all four +owners accept. diff --git a/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/net-kingdom.md b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/net-kingdom.md new file mode 100644 index 00000000..0326e8b4 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/net-kingdom.md @@ -0,0 +1,35 @@ +# net-kingdom owner review (1.3 candidate) + +Read [README.md](README.md) first. You own the type, the standard and three steps. + +## Your descriptors + +| Step | Actor | Lane | Effect | Descriptor digest | +|---|---|---|---|---| +| register-client | human | key-cape-oidc-login | change | sha256:3ccc8eed545cf31f8a48feb8afa0c1355e126d9549eef9737d92d0c1b87708a8 | +| ensure-groups | human | key-cape-oidc-login | change | sha256:4411b5cb8944ee76ca1ade62c0c246f061981fb18f0b9afd05934a8935598dc3 | +| bind-env | human | key-cape-oidc-login | change | sha256:d2511dce3d2ff1d380f845920aa168e6fe09c0f0c382482a796a5bf13619905d | + +For each: does the adapter (`sso-mfa/k8s/keycape/*-adapter.py`) do what the type's +follow-through step says, within the step's auth and lane? Accept or reject. + +## Type-level questions you decide + +- **Question 2, with railiance-platform:** the type has mint-secret as + `warden_executes: true, attended: false`, and the descriptor actor is `human`. + The routing catalog's `keycape-client-secret-generate` lane requires an aal2 human + OIDC login, with agents and root refused. Is the type text consistent, or should + 1.3 mark the step `attended: true, warden_executes: false`? +- **Question 3, with ops-warden:** six steps that the type marks as not Warden-executed + (three attended, three owner-path) carry execution descriptors. The kernel ignores + `warden_executes`; only the plan reads it. Should all seven stay in the map, or only + some? +- **Section 6:** confirm that 1.3 is a major change needing the founder's Decision + Memo, and that nothing else in the type changed from 1.2 (diff the two + `type.yaml` files). + +Also note: `ensure-groups` carries its own copy of the provisioner's group binding, +checked by a parity test. Decide whether the provisioner should expose a public API +instead. + +Write `owner-review-net-kingdom.json`. diff --git a/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/ops-warden.md b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/ops-warden.md new file mode 100644 index 00000000..5ef55bda --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/ops-warden.md @@ -0,0 +1,26 @@ +# ops-warden owner review (1.3 candidate) + +Read [README.md](README.md) first. You own the kernel, the routing catalog and +global admission. + +## Questions + +- **Question 1, the 1.3 parameter pin:** `src/warden/case_inputs.py` `PARAMETER_PINS` + has entries only for 1.1 and 1.2. 1.3's parameters are byte-identical to 1.2's, so + its fingerprint is 1.2's (`c04385d176f5f70257fb0fa6fef7e48ab26ed7cf26f6b1c7f14b16237b0ebea6`). + net-kingdom `test_admit_1_3_type.py` shows that an acknowledged 1.3 is refused only + for this missing pin. Will you add it, and on what condition? For example, only + after the founder acknowledges 1.3. +- **Catalog routing for all seven lanes:** `registry/routing/catalog.yaml` has + `key-cape-oidc-login` and `keycape-client-secret-generate`. It has none for + `platform-secret-delivery`, `consumer-owner-deployment` or `apps-consumer-handover`. + What would `catalog-routing-acceptance` need for those? +- **Question 3, with net-kingdom:** `Executor.admit` never reads the type's + `warden_executes` or `attended`; only `case_plan` uses them, for the mode. Should + Warden admit execution descriptors for steps the type marks as owner-path or + attended, or should admission refuse a descriptor whose plan mode is not `warden`? +- **Kernel review:** the original-intent interface (`a45cf47`) that the registration + adapter's reconcile path depends on has had no independent review. Say whether + it needs one before you accept. + +Write `owner-review-ops-warden.json`. diff --git a/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-apps.md b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-apps.md new file mode 100644 index 00000000..2524d9d0 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-apps.md @@ -0,0 +1,29 @@ +# railiance-apps owner review (1.3 candidate) + +Read [README.md](README.md) first. You own the consumer side (Forgejo first). + +## Your descriptors + +| Step | Actor | Lane | Effect | Descriptor digest | +|---|---|---|---|---| +| deliver-consumer-secret | agent | consumer-owner-deployment | change | sha256:9c289f646516923a4c448a2d3cdd45b33115516e6a171b7955924d8b5d852d2b | +| hand-over | human | apps-consumer-handover | change | sha256:84f0fac401ea2f1e7c305fb1753a34838ac062655199fcfbbd998f39268c3000 | + +The adapters are in net-kingdom `sso-mfa/k8s/keycape/deliver-consumer-secret-adapter.py` +and `handover-adapter.py`. The owner is `{consumer_owner_repo}`, which is +`railiance-apps` for the Forgejo example. + +## Questions + +- **deliver-consumer-secret** creates a dedicated ServiceAccount, a SecretStore and + an ExternalSecret in the consumer namespace, under CCR-2026-0042. It assumes you + have already validated ESO's TokenRequest and controller-RBAC admission. Is that + your path, and is actor `agent` right for it? +- **hand-over** requires the consumer to enforce the case's `access_groups` and a + verified login before recording a hand-over receipt. Can your deployment path + supply that observation? +- **The lanes** `consumer-owner-deployment` and `apps-consumer-handover` have no + routing catalog entries. Are they real lanes of yours, or should these steps use + existing ones? + +Write `owner-review-railiance-apps.json`. diff --git a/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-platform.md b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-platform.md new file mode 100644 index 00000000..aff8168a --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/railiance-platform.md @@ -0,0 +1,32 @@ +# railiance-platform owner review (1.3 candidate) + +Read [README.md](README.md) first. You own custody and secret delivery. + +## Your descriptors + +| Step | Actor | Lane | Effect | Descriptor digest | +|---|---|---|---|---| +| mint-secret | human | keycape-client-secret-generate | mint | sha256:c92957227235db04953809d92b260d32c8b947472a8e8fd17a258ade3ae8da70 | +| deliver-secret | human | platform-secret-delivery | change | sha256:75aaa7346aebdea2a0eb0ba993995515b5248ffefc34caf8e713525e9b58da85 | + +The adapters are in net-kingdom `sso-mfa/k8s/keycape/mint-secret-adapter.py` and +`deliver-secret-adapter.py`. Check them against your own custody contracts: the +`keycape-client-secret-generate` lane (RPF-WP-0054, CCR-2026-0043), the custody path +`platform/workloads/keycape/` and the ESO delivery to +`sso/keycape--client`. + +## Questions + +- **The proposed receipt schemas** `railiance-platform.custody-mint.v1` and + `netkingdom.deliver-secret.v1` were confirmed by the founder by name. Confirm + that they match what your custody and ESO paths can actually produce, value-free. +- **The mint/destroy capability interface** the adapter expects: can your custody + path supply it, including destroying exactly the minted version for created-only + rollback? +- **Question 2, with net-kingdom:** is `warden_executes: true, attended: false` for + mint-secret consistent with a human-only, aal2 broker lane? +- **The lane `platform-secret-delivery`** has no routing catalog entry. Is it a real + Platform lane, or should deliver-secret use an existing one? The type says ESO + delivery through role `external-secrets-keycape-{client_id}`. + +Write `owner-review-railiance-platform.json`. diff --git a/docs/changes/netkingdom-target-2026-10-17/nk48-adapters-1.2-review/README-r4.md b/docs/changes/netkingdom-target-2026-10-17/nk48-adapters-1.2-review/README-r4.md new file mode 100644 index 00000000..ae689e4f --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/nk48-adapters-1.2-review/README-r4.md @@ -0,0 +1,90 @@ +# Review request: NK-WP-0048 adapter set and the 1.3 successor type candidate (r4) + +Requested 2026-10-17 by the founder. r3 (`coordinator-review-r3.json`) approved all +nine files at net-kingdom `ff8f597`. Since then: +- three adapters and the composer were changed so they also accept a successor + type `oidc-browser-relying-party@1.3`; +- a 1.3 type candidate was added (`proposed`): 1.2 plus an `execution_descriptors` + map, which Warden's `Executor.admit` requires before it admits any step; +- a real-kernel admission test against that type was added. + +r4 is a source review of exactly those changes. It is not the owner review or the +founder's acknowledgment of 1.3; those follow separately. + +## Provenance, so the reviewer can judge independence + +The original authoring session wrote these changes, one adapter/composer edit +through a subagent worker and the 1.3 package and test directly. Run r4 in a +**new session** with none of the context of the authoring session, the r1/fix +session, the r2 session or the r3 session. + +## Frozen review target + +Repository `net-kingdom`, commit `1920b134e2b577e74aaac6b59db5fd785f505a3d` +(r3 target `ff8f597` plus merge `acda26c` of `835680c`, and `1920b13`). + +| File | sha256 at 1920b13 | Since r3 | +|---|---|---| +| sso-mfa/k8s/keycape/ensure-groups-adapter.py | e631134f20713d441b72ad7a9f49062b48925c4b6051b32bcfe9dadafff89b71 | **changed** (1.3 selectable) | +| sso-mfa/k8s/keycape/handover-adapter.py | 34dcae7ce19f6c7c8c8bb79f6b08e4c11be65269545cf739a9152e3d4dfe9b82 | **changed** (1.3 selectable, 1.3 owner rule) | +| sso-mfa/k8s/keycape/deliver-consumer-secret-adapter.py | fc34f750814bc85616aae158c81a8d9453ecf09ba3acdff0eba1d0eaeab911f5 | **changed** (accepts exactly 1.2 and 1.3) | +| sso-mfa/k8s/keycape/compose-1.2-descriptors.py | 39021cac900b11a59d00c5a1d5491b1ee4c639955cde07d07854c3db8bc04958 | **changed** (`--version 1.2|1.3`) | +| sso-mfa/k8s/keycape/descriptor-composition-1.2.candidate.json | da0b8847c4ea343370fc9f86b7f87025a0765a41e4d2d2f73e354a8db2f0077f | **changed** (regenerated; three digests moved) | +| sso-mfa/k8s/keycape/descriptor-composition-1.3.candidate.json | 64355c314891f7fc951a14e55c197609e892e73628acd43a535974382136961b | **new** | +| security-case-type-revisions/1.3/oidc-browser-relying-party/type.yaml | 3c05a749f28fa25df4d72aa1482a21be4ecc53af44ad17762d673588e2b3a947 | **new** | +| sso-mfa/k8s/keycape/test_admit_1_3_type.py (evidence) | 1e2667b83398b22e02d73bcda3a2f92bd0d14533e9a2e2d9f7492ad9b1eae387 | **new** | +| keycape-registration-adapter.py, mint-secret-adapter.py, deliver-secret-adapter.py, bind-env-adapter.py | 021eee26…, 246323c7…, cd1a515a…, 800e45ec… | unchanged since r3 | + +The rest of the 1.3 package (`README.md`, `examples/`, `tests/`) is in scope as +evidence. Verify that the four unchanged adapters are byte-identical to r3. + +## Reproduce + +```bash +mkdir -p "$SCRATCH/nk" "$SCRATCH/ow" +git -C ~/net-kingdom archive 1920b13 | tar -x -C "$SCRATCH/nk" +git -C ~/ops-warden archive a45cf47 src | tar -x -C "$SCRATCH/ow" +cd "$SCRATCH/nk" +python3 tools/security-case-types/security_case_validator.py validate-type security-case-type-revisions/1.3/oidc-browser-relying-party +NET_KINGDOM_ROOT="$SCRATCH/nk" python3 -m pytest -q -p no:cacheprovider security-case-type-revisions/1.3/oidc-browser-relying-party/tests +cd sso-mfa/k8s/keycape +PYTHONPATH="$SCRATCH/ow/src" ~/ops-warden/.venv/bin/python -m pytest -q -p no:cacheprovider \ + test_*adapter*.py test_registration_original_intent_reconcile.py test_compose_1_2_descriptors.py \ + test_admit_1_2_adapter_descriptors.py test_admit_1_3_type.py test_adapter_source_closure.py +``` + +The authors report: validator OK, 22 package tests, 127 passed with 111 subtests. +Run the 1.2 and 1.3 package tests separately (identical module names collide when +collected together). + +## What to check + +1. **Version selection:** 1.3 is reachable only through an explicit version root, + and 1.1 stays the default. deliver-consumer-secret accepts exactly 1.2 and 1.3. + hand-over's consumer-owner rule applies to 1.3 too. +2. **Composer:** `--version 1.2` output is unchanged except for the three moved + adapter digests, and `--version 1.3` loads only from + `security-case-type-revisions/1.3`. Both artifacts equal a fresh regeneration. +3. **1.3 type:** it differs from 1.2 only in version, status `proposed` and the + `execution_descriptors` map. Diff the two `type.yaml` files yourself. The map + equals the composed 1.3 set exactly. +4. **Admission test:** confirm that it proves what its docstring claims. The proposed + type is refused; an acknowledged copy is refused only by Warden's missing 1.3 + parameter pin; with exactly that pin added in memory all seven are admitted; a + descriptor outside the map is refused. Check also that the 1.2 type carries no map. +5. **Checks 1–8 from the r1 request**, applied to the three changed adapters. + +The three open questions in the 1.3 README (the ops-warden 1.3 pin, mint-secret +`warden_executes` versus actor `human`, and execution descriptors for owner-run and +attended steps) are for owner review. Comment on them only if you find a source +fact that bears on them. + +## Expected output + +Write `coordinator-review-r4.json` in this directory, shaped like r3, with a +per-file verdict for every row above. Review every changed or new file before +stopping, record every rejection and fix nothing. + +Hard limits: no live or native action, no kubectl, SSH or secret access, and no +edits to net-kingdom or ops-warden. This review grants no owner admission, pin, +acknowledgment or native authority.