---
id: KEY-WP-0009
type: workplan
title: "Provider capability declarations and bounded service identities"
domain: infotech
repo: key-cape
status: finished
owner: codex
topic_slug: netkingdom
created: "2026-08-23"
updated: "2026-09-08"
depends_on:
  - NK-WP-0030
  - KEY-WP-0006
state_hub_workstream_id: "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

```task
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

```task
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

```task
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

```task
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.