key-cape/workplans/KEY-WP-0009-provider-capabilities-and-service-identities.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	depends_on	state_hub_workstream_id
KEY-WP-0009	workplan	Provider capability declarations and bounded service identities	infotech	key-cape	finished	codex	netkingdom	2026-08-23	2026-09-08	NK-WP-0030 KEY-WP-0006	c1a9b1cc-2ff0-566a-b544-1a2ef967fc0d

KEY-WP-0009 — Provider capabilities and bounded service identities

Publish KeyCape-owned security-scenario interfaces and make the existing service-token issuer precise enough for OpenBao machine-login consumers. This work accepts identity issuance ownership without taking over OpenBao roles, policies, secret custody, or privacyIDEA token lifecycle.

Publish C1 and C2b provider declarations

id: KEY-WP-0009-T01
status: done
priority: high
state_hub_task_id: "eaf7af48-b3d6-5f85-b0ce-ff2b640f9cc3"

Publish Playbook Capability Contract v0.1 declarations for the KeyCape C1 runtime and its privacyIDEA-backed C2b integration. Name exact entry points, parameter authority, resource ownership, trust requirements, and readiness evidence. Do not claim C2a or privacyIDEA-owned token lifecycle.

Published capabilities/playbooks/key-cape.lightweight-sso.yaml and capabilities/playbooks/key-cape.privacyidea-token-authority.yaml. The latter claims the KeyCape integration for C2b while leaving factor enrollment, token state, custody keys, validation decisions, and lifecycle with privacyIDEA.

Define bounded service-auth contracts

id: KEY-WP-0009-T02
status: done
priority: high
state_hub_task_id: "212eb75c-a36c-5cb8-bf67-7d524f00f9ef"

Define the KeyCape service-auth claims, renewal/expiry, failure, custody, and owner boundaries required by secrets-engine and OpenBao JWT roles. Add per-client access-token lifetimes so a bounded client contract does not depend on an unrelated global default.

Added a validated 1m-1h per-client tokenLifetime override, applied it to JWT exp and expires_in, and documented claims, renewal, expiry, residual JWT validity, explicit OpenBao cleanup, and no-fallback failure semantics in docs/openbao-service-auth-contract.md.

Accept coding-agent issuance ownership

id: KEY-WP-0009-T03
status: done
priority: high
state_hub_task_id: "c41e0144-8169-57cf-8c34-eb52e65d6d76"

Publish the non-secret static registration for codex-railiance-platform with the exact audience, subject, tenant, role, scope, and 15-minute lifetime already accepted by railiance-platform. KeyCape owns JWT issuance and client disablement; railiance-platform owns the exact-bound OpenBao role and policy; OpenBao owns resulting token enforcement; secret values remain outside this repository.

Accepted ownership through the exact non-secret registration in config/service-clients.example.yaml. Added the parallel reviewed secrets-engine-openbao contract. Live value generation/materialization, deployment merge, and OpenBao role/policy application remain with their named custody and platform owners and are not implied by this source registration.

Validate and hand off

id: KEY-WP-0009-T04
status: done
priority: high
state_hub_task_id: "6945c0c0-bbb6-552b-8d62-d806d3fd0018"

Run the canonical declaration validator, Go formatting/build/vet/tests, and repository checks. Reply to NetKingdom, secrets-engine, ops-warden, and 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.

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.