All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 39s
KEY-WP-0009-T04 is done. Re-ran verification on main with an explicit Go 1.23.0 toolchain and a writable build cache: contract validator PASS, build, vet and the full test suite pass, git diff --check clean. gofmt had drifted on internal/server/telemetry/events.go and tests/migration/scenario_c_test.go (comment alignment only, no semantic change); both reformatted so the task's formatting claim holds. The four handoffs to netkingdom, secrets-engine, ops-warden and railiance-platform were then actually sent -- the 2026-09-05 audit had shown the earlier claimed delivery had no receipts -- and each receipt id is recorded in the workplan and readable back from the hub. KEY-WP-0013-T02 and KEY-WP-0014-T04 stay in wait. Their remaining work is not ours to do, so what was owed was the request, and it is now delivered: custody admission for the two approval clients to railiance-platform, the exact human client id and callback URI to approval-engine, and the OpenBao-token vs issuer-JWT split plus Qonto rotation execution authority to ops-warden. Each message quotes the existing non-secret packet or reviewed sequence and states what is explicitly not being treated as authorization. No secret was read, no production resource changed, no route retired. SCOPE.md updated to match. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uV8zoCKpA1WRAxsKRYbdH Assistant: claude-code Assistant-Model: opus Assistant-Process: 1182213@bnt-lap001 Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad
107 lines
4.4 KiB
Markdown
107 lines
4.4 KiB
Markdown
---
|
|
id: KEY-WP-0014
|
|
type: workplan
|
|
title: "Review native login and client credential lane handoffs"
|
|
domain: infotech
|
|
repo: key-cape
|
|
status: blocked
|
|
owner: codex
|
|
topic_slug: native-credential-lane-handoff
|
|
created: "2026-09-05"
|
|
updated: "2026-09-08"
|
|
state_hub_workstream_id: "0d003df3-f7d3-5063-8ca0-e1e33f7df74a"
|
|
---
|
|
|
|
Source: ops-warden inbox message 0dd9c7bd-0ecd-42d1-806f-7cc4ba9730ed.
|
|
The native service exchange and public PKCE login commands are now implemented.
|
|
Cross-owner rotation and consumer-specific route cutover remain outstanding.
|
|
|
|
## Design owner command and custody boundaries
|
|
|
|
```task
|
|
id: KEY-WP-0014-T01
|
|
status: done
|
|
priority: medium
|
|
state_hub_task_id: "0c0a0b61-c19e-5631-9cda-8b2dc0f47d8f"
|
|
```
|
|
|
|
Review ops-warden's existing key-cape-oidc-login proxy and
|
|
rapp-qonto-keycape-client route contracts. Specify the native interactive login
|
|
and bounded exchange commands, token delivery, renewal and custody-mediated
|
|
rotation before implementation. Keep secret custody with OpenBao and avoid
|
|
retiring the proxy until replacement commands have equivalent verification.
|
|
|
|
## Verify handoff delivery evidence
|
|
|
|
```task
|
|
id: KEY-WP-0014-T02
|
|
status: done
|
|
priority: low
|
|
state_hub_task_id: "d9a5de97-b7d5-5599-98c2-eaab32f51495"
|
|
```
|
|
|
|
Ops-warden reports KEY-WP-0009-T04's claimed reply did not arrive. Verify prior
|
|
receipts for all four named recipients before claiming successful notification.
|
|
No outbound coordination messages were sent during the 2026-09-05 repo review.
|
|
|
|
|
|
## Implement and verify native caller commands
|
|
|
|
```task
|
|
id: KEY-WP-0014-T03
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "4e46f474-a15e-594f-ae07-ad37a9667d89"
|
|
```
|
|
|
|
Implemented keycape service-token and login with HTTPS discovery, RS256/JWKS
|
|
verification, exact audience bindings, PKCE/state/nonce, private out-of-Git file
|
|
delivery and redacted errors. Service Basic authentication now form-decodes
|
|
credentials. Integration tests exercise the real token/JWKS handlers and browser
|
|
callback, including forged state, tampering, excess scope and unsafe output.
|
|
See docs/native-authentication.md for invocation and ownership boundaries.
|
|
|
|
## Admit rotation and verify consumer handoff
|
|
|
|
```task
|
|
id: KEY-WP-0014-T04
|
|
status: wait
|
|
priority: high
|
|
state_hub_task_id: "e7632c71-9676-5837-a925-7f905e3015c5"
|
|
```
|
|
|
|
Qonto rotation requires admitted custody/provider transaction and rollback
|
|
semantics; see the exact review sequence in docs/native-authentication.md.
|
|
The current login proxy yields an OpenBao token, so it cannot be replaced by a
|
|
JWT-writing command without adapting its consumer contract. Verify that split
|
|
with the platform owner and ops-warden before route changes. No route was changed.
|
|
|
|
2026-09-05 receipt audit: GET /messages/?from_agent=key-cape returned one
|
|
2026-03 image-publication message and no KEY-WP-0009 handoff receipts for
|
|
NetKingdom, secrets-engine, ops-warden or railiance-platform. Corrected the
|
|
unsupported statement in KEY-WP-0009-T04. This proves only that no receipts
|
|
are present in the current Hub response, not that no message ever existed.
|
|
The 2026-09-05 audit's finding stands as recorded; the replacement outbound
|
|
messages were sent on 2026-09-08 (below).
|
|
|
|
2026-09-08: `0a6c9d88-cf50-45d8-acdc-99a40747683e` -> ops-warden, readable back
|
|
via `GET /messages/?from_agent=key-cape`. It puts both open questions to the
|
|
route and custody owner in one place:
|
|
|
|
1. The `key-cape-oidc-login` proxy yields an OpenBao token and `keycape login`
|
|
yields an issuer JWT — different credential types, different verifiers,
|
|
different enforcement owners, so not interchangeable. Two admissible options
|
|
are offered: keep the proxy and run `keycape login` alongside it for JWT
|
|
consumers, or adapt the route's consumer contract to a JWT and then cut over.
|
|
Option (a) is recommended until every consumer of the route is enumerated.
|
|
2. Qonto rotation for `rapp-qonto-keycape-client`, quoting the five-step reviewed
|
|
sequence from `docs/native-authentication.md` and asking who executes the
|
|
successor generation and CAS update, in which transport, under what authority.
|
|
It records that `warden route`/`warden plan` returned no exact admitted lane
|
|
and that a generic match is not being treated as authorization.
|
|
|
|
The KEY-WP-0009 handoff ops-warden reported missing has also now been delivered
|
|
(`5bc58847-eed5-4164-bb0f-a0d8455e75b8`), closing the KEY-WP-0014-T02 correction.
|
|
|
|
Task remains `wait` — no route was changed and no rotation command ships until
|
|
ops-warden answers (1) and an execution/rollback authority is admitted for (2).
|