Open NK-WP-0048-T16 owner review request for the seven-step 1.2 descriptor set

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-10-17 11:19:54 +02:00
parent fd07eaa7d4
commit bffeee9611

View file

@ -0,0 +1,120 @@
# Owner review request: NK-WP-0048-T16 (seven-step 1.2 descriptor set)
Requested 2026-10-17 by the founder. This opens T16, the owner review, after the
coordinator source review closed with r3 (`../nk48-adapters-1.2-review/coordinator-review-r3.json`:
all nine files approved, no open findings). T16's dependencies T24–T30 are done.
The coordinator review checked that the code does what it claims. It did not
decide whether the owners accept it, whether Warden may run these steps, or
whether the type should change. Those are the decisions here. This packet starts
the review. It decides nothing, and it grants no admission, pin or native
authority.
## Frozen input
- net-kingdom `ff8f597d5f2f32ce8e82e370c0ad43aa98dc31b7`, `sso-mfa/k8s/keycape/`
(hashes in coordinator-review-r3.json `hashes_verified`).
- Candidate artifact `descriptor-composition-1.2.candidate.json`,
sha256 `745bb053e6776e8b96224563188405920227e4a17d7783ffa6b36c122be41b09`
(`status: not_an_admission`, `owner_review: false`, `dispatch_permitted: false`).
It supersedes Custodian `netkingdom-target-2026-10-17/native-registration-r1/descriptor-composition.json`
as T16's exact composition for the seven steps. T16's text still names the r1 file,
so the owner should update that pointer.
- Type `security-case-type-revisions/1.2/oidc-browser-relying-party/type.yaml`,
`status: acknowledged` (source-only founder acknowledgment), with no
`execution_descriptors`. Canonical 1.1 stays the default.
- Kernel ops-warden `a45cf47`. Checker artifact
`sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5` (T17/T18).
## The central question: Warden execution changes the type
In type 1.2 only `mint-secret` has `warden_executes: true`. The other six steps
in the set (`ensure-groups`, `deliver-secret`, `bind-env`, `register-client`,
`deliver-consumer-secret`, `hand-over`) say `warden_executes: false`. Three of
them (`ensure-groups`, `bind-env`, `register-client`) are also `attended: true`;
the others run under owner credentials (Platform ESO, Apps consumer). The
candidate gives all seven an execution descriptor.
Pinning descriptors that let Warden dispatch those six steps moves execution
from the owner (or an attended operator) to Warden. Under canon
`security-case-types_v0.1` section 6 that is a changed trust transition, which
makes it a **major** change: a new informed-decision for the founder, and a new
type revision rather than an edit of the acknowledged 1.2.
The NetKingdom owner proposes one of the following, and the founder decides:
- **A. Successor revision.** Publish the type as 1.3 (or the next revision),
with `execution_descriptors` for the seven steps and `warden_executes: true`
where Warden will dispatch. This needs a Decision Memo and informed-decision
acknowledgment. 1.1 stays the default.
- **B. Mint only.** Pin only the `mint-secret` descriptor, the one step 1.2
already lets Warden execute. The six other adapters stay as reviewed owner
seams that the owners run themselves. This is not a major change, but it
leaves a partial descriptor map, which T16 forbids for admission. In that case
the owner must record `complete_executable_descriptor_set` as not applicable.
- **C. Descriptors as owner tooling.** Pin none. The adapters stay owner-run,
and Warden verifies receipts but does not dispatch. T06's follow-through runs
through the owner entry points.
Under any option, keep the attended registration (`register-client`,
`key-cape-oidc-login`) attended unless the memo says otherwise.
## Per-owner review
Each owner reviews only what it owns and writes its result as a file in its own
repo or here (see Expected output). Assent from one owner does not stand in for
another's.
| Owner | Reviews | Must state |
|---|---|---|
| **net-kingdom** (T16 owner) | Descriptor bytes and the composer for all seven steps; the type successor or descriptor-pin change (option A/B/C); the checker artifact and config pins; the r2 observations listed below | Accept or reject each descriptor as a successor candidate; the chosen option and its Decision Memo, if A; the updated T16 composition pointer |
| **railiance-platform** | `mint-secret` (lane `keycape-client-secret-generate`, actor `human` per the founder's decision of 2026-10-17, scopes `parent-session` + `broker-grant`) and `deliver-secret` (lane `platform-secret-delivery`); the injected capability contracts: custody mint/destroy, ESO deliver/remove, evidence publish/authenticate, session and broker-grant revocation | Whether the receipt schemas (`railiance-platform.custody-mint.v1`, `netkingdom.deliver-secret.v1`) and the created-only rollback contract are what Platform will implement; which real implementations bind to the capabilities, and who owns their custody |
| **railiance-apps** | `deliver-consumer-secret` and `hand-over`; the consumer verifier and consumer apply/remove contracts | Whether Apps will implement those contracts, and how actual consumer login and group enforcement are verified (not inferred from registry CAS) |
| **ops-warden** | Global provenance and admission: `Executor.admit` of the real type with pinned descriptors (fixture trust is all that has been shown); native publisher/authenticator; WARDEN-WP-0044-T03 receipt verifier | Whether a45cf47 admits the chosen option without a kernel change, and what native evidence trust root it requires |
| **key-cape** | Checker artifact identity and native executable storage/custody (T17/T18 left this to T16) | Where the pinned checker binary lives and how its custody is proved |
## Carried into this review (from coordinator r2/r3)
1. The composer computes `complete_executable_descriptor_set` from
`Descriptor.decode`. Kernel admission is proved only by a fixture test
(r3 checked the three changed source pins against the modules directly).
2. Import-time versus build-time drift: registration and bind-env execute helper
modules loaded at import, but re-read digests at build and per attempt.
3. mint-secret, deliver-secret, bind-env and registration select no type version
themselves. They rely on the kernel's case/type pin.
4. The closure test covers import-time Python loads only.
5. Every owner capability is an injected stand-in. No real implementation has
been reviewed. Only the registration adapter has kernel run/rollback tests.
6. If a mint succeeds and a revocation then fails, the version is left for owner
reconciliation (UNCERTAIN).
The owner either accepts each of these as a known limit or turns it into a task.
## Not in T16
- T14 (group provenance, `progress`) and T15 (durable restart/recovery, `wait`)
are prerequisites of T06, not of T16. They must not be marked done here.
- Quiet-window restart and readiness after registry CAS (`restart_required`),
and attended consumer verification, are reviewed separately.
- No case acceptance, materialization, native mint, delivery or registration.
The 1.2 reference case stays `proposed`.
## Expected output
- net-kingdom: a T16 owner-review record (for example
`docs/evidence/nk48-t16-owner-review/owner-review-netkingdom.json`) and T16's
status moved by the owner session, not by the coordinator. If option A is
chosen, also the Decision Memo for informed-decision.
- railiance-platform, railiance-apps, ops-warden and key-cape: one assent,
rejection or "needs change" record each, naming the files and hashes reviewed.
- The founder: the option decision and, for A, the informed-decision acknowledgment.
The coordinator collects these into `owner-review-status.json` here. It does not
author any owner's verdict.
## Hard limits
No live or native action, no kubectl, SSH or secret access, no
`--allow-unimplemented` admission, no change to canonical 1.1 or its accepted
case. Do not edit net-kingdom from a Custodian session. Owner review grants
nothing until the founder and each owner record it.