WARDEN-WP-0044-T01: withdraw R4, agree per-case keycape-client entries with templated body
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 327285@bnt-lap001
Assistant-Session: d6532cd1-7cd5-417b-baac-b841c9103a6b
This commit is contained in:
tegwick 2026-10-09 00:14:28 +02:00
parent b6b9b95616
commit 98cb0bc24a
2 changed files with 37 additions and 0 deletions

View file

@ -73,3 +73,36 @@ client view) and `secret-delivered` (R5). Every item keeps
The justification is accepted: the live registry is a Kubernetes Secret.
ops-warden groups those steps into one `key-cape-oidc-login` session and does
not execute them. `hand-over` belongs to the consumer.
## Addendum 2026-10-09: R4 reconciled with ops-mason item 5
net-kingdom pointed out that R4 conflicts with MASON-WP-0010-T01 item 5
(per-case `{consuming_service}-keycape-client`). On reflection, R4 was wrong
as written. **R4 is withdrawn and replaced with R4′.**
A single parameterized entry would have to carry `workload_ref: not-applicable`,
as the generic `openbao-api-key` template does. That would drop the consumer's
workload reference, and `ADR-0009` needs that reference to select the zone and
PEP failure mode for this exact client. A per-case entry carries real
per-consumer data. It is not a second copy of a procedure, so `ADR-0001` is not
engaged.
**R4′:** keep one catalog entry per case, named
`{consuming_service}-keycape-client` (ops-mason's item 5). Template its
**body** in the type, as item 3 now requires for policies, so that cases add
values and never route design (WARDEN-WP-0044-T04). The body should contain:
- `owner_repo: key-cape`, `warden_executes: false`, `risk: high`,
`status: active` once verification passes
- `workload_ref: {applicability: applicable, name: {consuming_service},
declaration_ref: <consumer declaration>}`. If the consumer has not published
a declaration, the field takes the explicit unknown form, never an inferred one.
- `path_template: platform/workloads/keycape/{client_id}`, field `CLIENT_SECRET`
- `delegation: {mode: native, intended_owner: key-cape}`
- `rotation` steps referencing the type's mint-secret and verification, with
`automatable: false` until a run has been proven
Correction to R4: the existing `rapp-qonto-keycape-client` is a
client-credentials workload client at a different path. It is not a browser
relying party, so it would **not** become a case of this type. Only the naming
precedent carries over.

View file

@ -62,6 +62,10 @@ changes before T02: a per-step `lane`, a narrow `warden_executes`, and
`value_handling`. It also lists four refinements. This task is done when
net-kingdom acknowledges the review (NK-WP-0048-T05).
2026-10-09: R4 was withdrawn in favour of ops-mason's per-case
`{consuming_service}-keycape-client`, with the entry body templated in the type
(R4′, see the addendum in the review).
```task
id: WARDEN-WP-0044-T02
status: wait