From ee94c189385271194f22a53998b2c6e12e961ea9 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 28 Aug 2026 22:00:09 +0200 Subject: [PATCH] =?UTF-8?q?WARDEN-WP-0033=20finished=20=E2=80=94=20key-cap?= =?UTF-8?q?e=20accepted=20the=20issuance=20question=20five=20days=20ago?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit T04 was the last open task, waiting on key-cape to accept or refuse ownership of the coding-agent OpenBao issuance identity. They accepted, in KEY-WP-0009-T03, on 2026-08-23: codex-railiance-platform is published in their config/service-clients.example.yaml with subject service:codex:railiance-platform, role coding-agent, scope openbao:login, 15m lifetime, and the service-auth semantics in docs/openbao-service-auth-contract.md. The split is the one we routed for — KeyCape issues, railiance-platform binds the OpenBao role, OpenBao enforces, no secret value in either repo. We found it by reading their repository. KEY-WP-0009-T04 records replying to ops-warden; the inbox has zero messages from key-cape, read or unread. The task sat `wait` on an answer that already existed. That is T05's own lesson arriving on T04: a blocker is a claim about the world at a date. So the same pass re-verified the two lanes pointing at key-cape against their source instead of bumping dates: - rapp-qonto-keycape-client -> verified: source-read. KEY-WP-0009-T02 did add bounded service-auth, but that is client_credentials JWT issuance for OpenBao machine login and does not front this client_secret_basic exchange or its rotation. Blocker stands, now with evidence rather than memory. - key-cape-oidc-login -> asked of key-cape today, which the entry had recorded as still outstanding since 2026-08-21. Also cleared the inbox that hid this: 9 stale unread, all superseded by shipped work, with late closes sent to secrets-engine and llm-connect on the two threads that had asked ops-warden something and never got an answer. 391 tests pass, ruff clean, boundary coverage 0 uncovered. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01YWBMovyFoy9RRrfL7zKvPJ Assistant: claude-code Assistant-Model: opus Assistant-Process: 4014535@bnt-lap001 Assistant-Session: d0036016-73e8-4da1-8e47-563e3ab39a3c --- registry/generated/high-risk-data-paths.yaml | 4 +-- registry/routing/catalog.yaml | 10 +++--- .../WARDEN-WP-0033-native-lane-handoff.md | 33 +++++++++++++++++-- 3 files changed, 37 insertions(+), 10 deletions(-) diff --git a/registry/generated/high-risk-data-paths.yaml b/registry/generated/high-risk-data-paths.yaml index a0b7ea0..35d494b 100644 --- a/registry/generated/high-risk-data-paths.yaml +++ b/registry/generated/high-risk-data-paths.yaml @@ -10,11 +10,11 @@ # declares it, and is null where the field set has not been established -- # null means unknown, never 'one field'. -generated_at: "2026-08-28T19:54:29Z" +generated_at: "2026-08-28T19:58:57Z" source: ops-warden/registry/routing/catalog.yaml catalog_revision: "c374d41a4925720ae7706dfda020537b60a07eb9" catalog_revision_date: "2026-08-23T21:43:12+02:00" -catalog_dirty: false +catalog_dirty: true high_risk_lane_count: 23 concrete_path_count: 14 diff --git a/registry/routing/catalog.yaml b/registry/routing/catalog.yaml index 0ab246b..09f690e 100644 --- a/registry/routing/catalog.yaml +++ b/registry/routing/catalog.yaml @@ -281,8 +281,8 @@ entries: delegation: mode: interim intended_owner: key-cape - blocked_on: "REFUSED by secrets-engine 2026-08-21: login, MFA and identity-token issuance are key-cape/Keycloak's; secrets-engine may consume OIDC for OpenBao auth but does not own the login capability. ops-warden agrees — intended_owner corrected from secrets-engine to key-cape. Not yet asked of key-cape." - reviewed: "2026-08-21" + blocked_on: "REFUSED by secrets-engine 2026-08-21: login, MFA and identity-token issuance are key-cape/Keycloak's; secrets-engine may consume OIDC for OpenBao auth but does not own the login capability. ops-warden agrees — intended_owner corrected from secrets-engine to key-cape. Asked of key-cape 2026-08-28; KEY-WP-0009 accepting issuance ownership for machine identities is the precedent that makes it answerable." + reviewed: "2026-08-28" verified: asked-and-waiting # Login lane (WP-0014 T4) — interactive auth bootstrap, not a secret read. No # secret-read gate (you have no identity yet) and no caller-auth precheck (the @@ -710,9 +710,9 @@ entries: delegation: mode: interim intended_owner: key-cape - blocked_on: "client_secret_basic exchange is a key-cape protocol procedure, not a KV read; KEY-WP-0008 finished 2026-08-15 without a key-cape-native exchange/rotation command, and the workplan that would add one is not yet opened (key-cape acked interim 2026-08-15)" - reviewed: "2026-08-17" - verified: unverified + blocked_on: "client_secret_basic exchange is a key-cape protocol procedure, not a KV read; still no key-cape-native exchange/rotation command. Re-checked against key-cape source 2026-08-28: KEY-WP-0009 finished 2026-08-23 and did add bounded service-auth (per-client tokenLifetime, docs/openbao-service-auth-contract.md), but that is client_credentials JWT issuance for OpenBao machine login — it does not front this client_secret_basic exchange or its rotation. The server advertises client_secret_basic (src/internal/server/oidc/discovery.go) without exposing an owner command for it. Blocker stands." + reviewed: "2026-08-28" + verified: source-read risk: high workload_ref: applicability: applicable diff --git a/workplans/WARDEN-WP-0033-native-lane-handoff.md b/workplans/WARDEN-WP-0033-native-lane-handoff.md index 1e20015..55cd015 100644 --- a/workplans/WARDEN-WP-0033-native-lane-handoff.md +++ b/workplans/WARDEN-WP-0033-native-lane-handoff.md @@ -4,14 +4,14 @@ type: workplan title: "Native lane handoff — review secrets-engine's catalog admission, and fix what it exposed" domain: infotech repo: ops-warden -status: active +status: finished owner: ops-warden topic_slug: netkingdom planning_priority: P1 depends_on_workplans: - WARDEN-WP-0030 created: "2026-08-21" -updated: "2026-08-23" +updated: "2026-08-28" state_hub_workstream_id: "4627d89b-4b00-562a-81e9-76e96f90fa7e" --- @@ -160,7 +160,7 @@ railiance-platform may deny more, deny less, or dispute a grade (`ADR-0002`). ```task id: WARDEN-WP-0033-T04 -status: wait +status: done priority: medium state_hub_task_id: "5acac140-a586-5db3-b231-bbf236710786" ``` @@ -212,6 +212,33 @@ accept that target identity with an authoritative workplan/interface, or refuse and name the actual owner. T04 remains `wait` until one of those two answers is recorded; the live AppRole is operational evidence, not an ownership answer. +**Answered — accepted. Closed 2026-08-28.** `key-cape` accepted issuance +ownership in `KEY-WP-0009-T03` (`status: done`, 2026-08-23): the non-secret static +registration `codex-railiance-platform` is published in +`key-cape/config/service-clients.example.yaml` — subject +`service:codex:railiance-platform`, tenant `tenant:coulomb`, role `coding-agent`, +scope `openbao:login`, `client_credentials`, 15-minute lifetime — with the +service-auth claims, renewal, expiry and failure semantics in +`key-cape/docs/openbao-service-auth-contract.md` (`T02`). The split is exactly the +one the routing asked for: KeyCape owns JWT issuance and client disablement, +railiance-platform owns the exact-bound OpenBao role and policy, OpenBao owns +enforcement, and no secret value enters either repository. + +**The answer was found by reading their repo, not by receiving it.** +`KEY-WP-0009-T04` records replying to ops-warden; no such message exists in the +ops-warden inbox — 0 messages from `key-cape`, read or unread. The acceptance had +been sitting done for five days while this task sat `wait` on it. + +That is the T05 lesson landing on T04: a blocker is a claim about the world at a +date, and this one had stopped being true. `verified: source-read` is doing real +work here — it is the difference between "we asked" and "we checked". The +mechanism is right; what it needs is for someone to run it, which is why the +lanes below were re-verified in the same pass rather than date-bumped. + +Consequence for `ADR-0004`: the honour-system `WARDEN_AGENT_ID` marker now has a +real issuance identity behind it on the OpenBao side. ops-warden remains a +consumer of that identity and does not own it. + ```task id: WARDEN-WP-0033-T05 status: done