Request r4 source review and the four 1.3 owner reviews for NK-WP-0048-T16
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
codex
parent
bffeee9611
commit
f06f6144a8
6 changed files with 265 additions and 0 deletions
|
|
@ -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:<owner>` 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-<owner>.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.
|
||||
|
|
@ -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`.
|
||||
|
|
@ -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`.
|
||||
|
|
@ -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`.
|
||||
|
|
@ -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/<client_id>` and the ESO delivery to
|
||||
`sso/keycape-<client_id>-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`.
|
||||
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue