net-kingdom/security-case-type-revisions/1.3/oidc-browser-relying-party
tegwick 2a9d946524
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
NK-WP-0048-T34: integrate the corrected F3 owner configuration inverse text into 1.3
Applies the Custodian nk48-r5-f3-implementation-r2 type candidate (addresses
RAPPS-F3-SESSION-1). Descriptors unchanged; validator and suites pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 696317@bnt-lap001
Assistant-Session: bab9e511-0915-45b3-926a-2fab552edff6
2026-10-23 07:08:41 +02:00
..
examples NK-WP-0048-T16: propose 1.3 successor type with the execution_descriptors map 2026-10-17 11:25:35 +02:00
tests NK-WP-0048-T16: propose 1.3 successor type with the execution_descriptors map 2026-10-17 11:25:35 +02:00
README.md NK-WP-0048-T16: propose 1.3 successor type with the execution_descriptors map 2026-10-17 11:25:35 +02:00
type.yaml NK-WP-0048-T34: integrate the corrected F3 owner configuration inverse text into 1.3 2026-10-23 07:08:41 +02:00

Proposed OIDC browser relying-party 1.3 successor candidate

Status: proposed. This is a source candidate for NK-WP-0048-T16. It is not acknowledged, not implemented, and grants no execution or native authority. The acknowledged 1.2 package (../../1.2/oidc-browser-relying-party/) and canonical 1.1 stay unchanged, and 1.2's acknowledgment is not inherited.

Purpose

The purpose of the type is 1.2's: register exact-redirect browser OIDC relying parties through KeyCape, with groups enforced by the consumer. 1.3 changes only two things:

  1. version: '1.3' and status: proposed, with the examples pinned to @1.3.
  2. A new execution_descriptors map naming the reviewed machine descriptor digest for each of the seven follow-through steps. Warden's Executor.admit refuses any step whose descriptor digest is not in the type's map, so this map is what would let Warden admit the steps at all. It is generated by sso-mfa/k8s/keycape/compose-1.2-descriptors.py --version 1.3, and test_admit_1_3_type.py checks that it equals the composed set.

Every other byte of the type (parameters, composition, materialization, follow-through, verification, rollback, acceptance) is 1.2's. The parameter set is identical, so its fingerprint equals 1.2's.

Canon security-case-types_v0.1.md section 6 treats a changed trust transition as major. Allowing Warden to admit these steps is one, so 1.3 needs its own Decision Memo and informed-decision acknowledgment by the founder, the same as a new type.

Threat model

1.2's threat model applies unchanged. 1.3 adds one transition: Warden may admit a step and dispatch its owner-supplied adapter, which runs injected owner capabilities. Each descriptor pins its adapter's exact source closure, lane, actor, effect, allowed created objects and revocation scopes, and admission still requires authenticated case acceptance, ops-mason materialization, owner descriptor acceptance, type machine-seam acceptance, catalog routing acceptance and the caller's session. A mint is admitted only for a human caller. The adapters record value-free evidence and roll back only objects they created. None of that removes the need for owners to verify native bindings.

Alternatives considered

  • Keep 1.2 as plan-only, with no execution_descriptors. Every step stays manual, and the reviewed adapters are never admitted.
  • List only a subset of steps in the map, for example only the Warden-executed and attended ones. That is open question 3 below.
  • Change the kernel to read descriptors from outside the type. This is rejected: the kernel binds the map to the acknowledged type bytes on purpose.

Known limits

  • The adapter set was independently reviewed at net-kingdom ff8f597 (the-custodian docs/changes/netkingdom-target-2026-10-17/nk48-adapters-1.2-review/, r1–r3, all nine files approved in r3). Making ensure-groups, hand-over, deliver-consumer-secret and the composer accept 1.3 changed their source digests, so those descriptors need a further source review (r4) before this map can be relied on.
  • test_admit_1_3_type.py runs Warden's real Executor.admit (ops-warden a45cf47) with fixture-only trust. The proposed type is refused. An acknowledged copy is still refused, because Warden pins parameter fingerprints only for 1.1 and 1.2. With only a 1.3 pin added in memory, all seven descriptors are admitted, and a descriptor outside the map is refused.
  • All owner capabilities in the tests are stand-ins, and no native binding is proven.

Open questions for owner review:

  1. ops-warden: add "1.3" to warden/case_inputs.py PARAMETER_PINS with 1.2's fingerprint. Without it, no 1.3 case is admitted.
  2. mint-secret semantics: the type says warden_executes: true, attended: false, while the descriptor actor is human (founder decision 2026-10-17), and the kernel refuses a non-human mint. Owners decide whether these are consistent (a human caller starts an unattended Warden-executed mint) or whether the step should become attended: true, warden_executes: false in this revision.
  3. Owner-run steps with descriptors: deliver-secret, deliver-consumer-secret and hand-over are warden_executes: false, attended: false (owner path), and register-client, ensure-groups and bind-env are attended, yet all carry execution descriptors. The kernel never reads warden_executes; only the plan does. Owners decide whether Warden should admit these steps or whether the map should list only a subset.

Verification

python3 tools/security-case-types/security_case_validator.py validate-type security-case-type-revisions/1.3/oidc-browser-relying-party
NET_KINGDOM_ROOT=$PWD python3 -m pytest security-case-type-revisions/1.3/oidc-browser-relying-party/tests
cd sso-mfa/k8s/keycape && PYTHONPATH=$HOME/ops-warden/src ~/ops-warden/.venv/bin/python -m pytest -q test_admit_1_3_type.py