diff --git a/SCOPE.md b/SCOPE.md index f98def3..6ea05e7 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -103,8 +103,14 @@ Keycloak interchangeability are not established. (KEY-WP-0026). Production deployment and custody are external; a source implementation or example client fragment does not prove live registration or consumer cutover. -- Approval-client provisioning, coordinated Qonto rotation, native consumer - handoffs and notification receipt closure remain open in KEY-WP-0009/0013/0014. +- Notification receipt closure is done: KEY-WP-0009 is finished, its four handoffs + delivered with receipts readable via `GET /messages/?from_agent=key-cape`. + Approval-client provisioning (KEY-WP-0013-T02) and coordinated Qonto rotation + plus the login-proxy consumer split (KEY-WP-0014-T04) remain open. Both requests + are now delivered and both wait on owners outside this repository — + railiance-platform for custody admission, approval-engine for the exact human + callback, ops-warden for the route contract and a rotation execution/rollback + authority. No client is materialized in the deployed image and no route changed. ## Deliberate exclusions diff --git a/src/internal/server/telemetry/events.go b/src/internal/server/telemetry/events.go index ba264db..c7032c1 100644 --- a/src/internal/server/telemetry/events.go +++ b/src/internal/server/telemetry/events.go @@ -25,7 +25,7 @@ type Event struct { ClientID string `json:"client_id"` Endpoint string `json:"endpoint"` Feature string `json:"feature,omitempty"` - Result string `json:"result"` // "success" | "failure" + Result string `json:"result"` // "success" | "failure" ErrorType string `json:"error_type,omitempty"` Scopes []string `json:"scopes,omitempty"` GrantType string `json:"grant_type,omitempty"` diff --git a/src/tests/migration/scenario_c_test.go b/src/tests/migration/scenario_c_test.go index 37921d0..bf0a61a 100644 --- a/src/tests/migration/scenario_c_test.go +++ b/src/tests/migration/scenario_c_test.go @@ -8,8 +8,8 @@ import ( "strings" "testing" - "keycape/internal/migration/toldap" "keycape/internal/migration/tokeycloak" + "keycape/internal/migration/toldap" "keycape/internal/server/telemetry" ) diff --git a/workplans/KEY-WP-0009-provider-capabilities-and-service-identities.md b/workplans/KEY-WP-0009-provider-capabilities-and-service-identities.md index d88422c..27fb467 100644 --- a/workplans/KEY-WP-0009-provider-capabilities-and-service-identities.md +++ b/workplans/KEY-WP-0009-provider-capabilities-and-service-identities.md @@ -4,11 +4,11 @@ type: workplan title: "Provider capability declarations and bounded service identities" domain: infotech repo: key-cape -status: blocked +status: finished owner: codex topic_slug: netkingdom created: "2026-08-23" -updated: "2026-08-23" +updated: "2026-09-08" depends_on: - NK-WP-0030 - KEY-WP-0006 @@ -85,7 +85,7 @@ custody and platform owners and are not implied by this source registration. ```task id: KEY-WP-0009-T04 -status: wait +status: done priority: high state_hub_task_id: "6945c0c0-bbb6-552b-8d62-d806d3fd0018" ``` @@ -97,8 +97,32 @@ railiance-platform with revision-independent paths and exact ownership status. Both declarations pass NetKingdom's canonical validator. The full Go suite, vet, build, `gofmt`, YAML parsing, and `git diff --check` pass using an explicit Go 1.23 toolchain and writable local cache; the workstation's default Go cache -is read-only and was not used. The earlier statement that State Hub handoffs were delivered was not supported -by receipt IDs. The 2026-09-05 audit found no matching handoff receipts in the -current Hub response; local implementation and validation were complete, but -notification delivery is unverified. KEY-WP-0014 records the correction and -remaining consumer handoff. Do not use this task as proof of message delivery. +is read-only and was not used. + +2026-09-05 correction: the earlier statement that State Hub handoffs were +delivered was not supported by receipt IDs. The audit found no matching handoff +receipts in the Hub response. KEY-WP-0014-T02 records the correction. + +2026-09-08 closure. Verification re-run on `main` with `GOTOOLCHAIN=go1.23.0` and +a writable `GOCACHE`: `make contract-test` PASS, `go build ./...`, `go vet ./...` +and `go test ./...` all pass, `git diff --check` clean. `gofmt` had drifted on +`src/internal/server/telemetry/events.go` and `src/tests/migration/scenario_c_test.go` +(comment alignment only, no semantic change); both were reformatted so the +formatting claim now holds. + +The four handoffs were then actually sent, and each receipt is readable back via +`GET /messages/?from_agent=key-cape`: + +| Recipient | Receipt id | +| --- | --- | +| netkingdom | `692ed0d7-e21b-48e7-8600-5b32b551c627` | +| secrets-engine | `479a1698-87dc-4ee2-a732-c2dc18bc4e84` | +| ops-warden | `5bc58847-eed5-4164-bb0f-a0d8455e75b8` | +| railiance-platform | `9c6a4e70-6bc0-4ad6-8293-35a56e507dfc` | + +Each names revision-independent paths, the 2026-09-08 verification result, and +the same ownership split: KeyCape owns issuance, static registrations, client +disablement and the claim set; secret custody, OpenBao roles/policies and token +enforcement, privacyIDEA factor and token lifecycle, resource authorization and +deployment remain with their named owners. C2a is not claimed. This closes the +notification gap; it is still not evidence of live deployment or provider cutover. diff --git a/workplans/KEY-WP-0013-approval-engine-resource-audience.md b/workplans/KEY-WP-0013-approval-engine-resource-audience.md index 9a70ee7..3b163b1 100644 --- a/workplans/KEY-WP-0013-approval-engine-resource-audience.md +++ b/workplans/KEY-WP-0013-approval-engine-resource-audience.md @@ -8,7 +8,7 @@ status: blocked owner: codex topic_slug: approval-engine-resource-audience created: "2026-09-05" -updated: "2026-09-06" +updated: "2026-09-08" state_hub_workstream_id: "6e815d88-b0e3-5ce0-be5d-13ab15917f7f" --- @@ -57,6 +57,34 @@ returned founder_required but matched an unrelated generic database lane; that mismatch is not authority to provision. Human callback clarification is pending. No secrets were read or production resources changed. +2026-09-08: the two blocking requests were sent and their receipts are readable +back via `GET /messages/?from_agent=key-cape`. + +- `278a3ebe-b529-49f6-bd1a-e3ebcf318260` -> railiance-platform. Custody admission + for both clients, quoting `docs/approval-engine-provisioning-request.yaml` + verbatim: exact OpenBao paths and `client_secret` field, the two Kubernetes + delivery references, the two `KEYCAPE_*_CLIENT_SECRET` environment names, + `tenant:platform` per decision `5ed3fb35-eca9-413a-82b9-95171ba85bf6`, and the + 15m lifetime. It asks for four things explicitly: confirm/correct the paths and + fields, confirm the delivery references, name the authority for the attended + first provision, and agree a rollout window in which registrations and the + KeyCape version that reads them deploy together. It restates that the + `warden plan` `founder_required` result matched an unrelated generic database + lane and is not being treated as authorization. +- `43fbd997-6e22-4859-8433-58b784c2df6c` -> approval-engine. Requests the two + missing human-registration inputs — the exact `client_id` and the full callback + URI — noting redirects are matched exactly and a near-miss fails closed at + `/authorize`. Restates the human client shape (public, S256 PKCE, + `audience: approval-engine`, `allowedScopes: [openid, approval:approve]`, + `mfaRequired: true`, no consume grant) and asks approval-engine to confirm it + validates the access token, not the ID token, against the deployed `/jwks`. + +Deployment state is unchanged from the 2026-09-05 observation: neither approval +client is materialized. Task remains `wait` — the two admissions are owned by +railiance-platform and approval-engine respectively, and live provisioning proof +cannot begin until both land. Still no secret read and no production resource +changed. + ## Reconcile tenant vocabularies across approval layers ```task diff --git a/workplans/KEY-WP-0014-native-credential-lane-handoff.md b/workplans/KEY-WP-0014-native-credential-lane-handoff.md index bfcac66..cad1c16 100644 --- a/workplans/KEY-WP-0014-native-credential-lane-handoff.md +++ b/workplans/KEY-WP-0014-native-credential-lane-handoff.md @@ -8,7 +8,7 @@ status: blocked owner: codex topic_slug: native-credential-lane-handoff created: "2026-09-05" -updated: "2026-09-05" +updated: "2026-09-08" state_hub_workstream_id: "0d003df3-f7d3-5063-8ca0-e1e33f7df74a" --- @@ -81,4 +81,27 @@ with the platform owner and ops-warden before route changes. No route was change 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. -No replacement outbound messages were sent. +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).