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	blocked	codex	netkingdom	2026-08-23	2026-08-23	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: wait
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. 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.