coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record live custody admission and re-verify the new rule against it

Browse source 
Read-only inspection shows KEY-WP-0013-T02's custody gate has moved since
yesterday: both approval clients are registered in sso/keycape-config, both
secrets exist in the namespace and are wired into the pod, and the image is
pinned to the digest T06 published. The live issuer passes every conformance
check that needs no credential.

That does not establish the claim contract. Subject, tenant, roles, scopes,
lifetime and excess-scope denial are what keycape verify-client proves, and it
needs the client secret in the environment. Reading either secret is client-side
retrieval, which the provisioning packet records as not admitted, so that run is
an attended operator action. T02 now waits on the run, not on custody.

Also re-verified the KEY-WP-0028 rule against the deployed config, after a peer
noted it fails closed at startup with a rollout imminent. The three browser
clients there carry neither serviceSubject nor roles; the three service clients
carry both legitimately. Kept as errors rather than warnings on that evidence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
This commit is contained in:
tegwick 2026-09-09 14:44:38 +02:00
parent 74b35b6107
commit 1dc11b8448
2 changed files with 39 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

26
workplans/KEY-WP-0013-approval-engine-resource-audience.md
View file

@ -223,6 +223,32 @@ client's tenant against the real fixture so a reintroduced alias fails the build
Full `go test ./...` and `go vet ./...` pass. Choice only — live provisioning and
the other admission gates remain with KEY-WP-0013-T02.
2026-09-09 observation, read-only. Custody has been admitted since the
2026-09-08 record and the deployment now carries the pieces T02 was waiting for:
`sso/keycape-config` registers `secrets-engine-approval` and
`approval-engine-operator` alongside the existing clients; the secrets
`keycape-secrets-engine-approval-client` and
`keycape-approval-engine-operator-client` exist in the namespace; both
`KEYCAPE_SECRETS_ENGINE_APPROVAL_CLIENT_SECRET` and
`KEYCAPE_APPROVAL_ENGINE_OPERATOR_CLIENT_SECRET` are wired into the pod; and the
image is pinned by digest to
`sha256:7ff54c54e63ee172ae9e6e7fd2da96e427352f712343d74626ee6fe0f6f82611`, the
candidate T06 published.
What that does and does not establish. The live issuer passes every conformance
check that needs no credential — it advertises itself, offers the profile
authorization surface, publishes usable RS256 keys and advertises no excluded
grant (`src/tests/conformance`, run against `https://kc.coulomb.social`). It does
**not** establish the claim contract: subject, tenant, roles, scopes, lifetime
and excess-scope denial per client are exactly what `keycape verify-client`
exists to prove, and that needs the client secret in the environment.
Deliberately not done here. Reading either secret to run the verifier is
client-side retrieval, which the provisioning packet records as **not admitted**
(`custody_return.scope`: verifier-side copies only). So the remaining proof is an
attended operator action, not something to take by reading the secret. T02 stays
`wait` on that run, not on custody.
## Assign and register the human approver browser client
```task

13
workplans/KEY-WP-0028-browser-client-field-validation.md
View file

@ -9,6 +9,7 @@ owner: claude
topic_slug: browser-client-field-validation
created: "2026-09-09"
updated: "2026-09-09"
state_hub_workstream_id: "6d0cb4fd-17da-5466-8011-5ade1ac46171"
---
`serviceSubject` and `roles` are read only on the `client_credentials` path. On a
@ -26,6 +27,7 @@ rule exists — it was just incomplete.
id: KEY-WP-0028-T01
status: done
priority: medium
state_hub_task_id: "e4bce8c7-0e60-55e8-ad32-a3a0c4e46044"
```
Config validation now rejects `serviceSubject` and `roles` on any client that
@ -34,6 +36,16 @@ Nothing in `config/dev-config.yaml`, the example fixture or the live deployment
sets either field on a browser client, so this breaks no existing configuration —
checked against all three rather than assumed.
Re-verified against `sso/keycape-config` on 2026-09-09, after a peer raised that
this validation fails closed at startup and a rollout is imminent, so a stray
field would surface as KeyCape failing to boot. The deployed config now holds six
clients: `demo-app`, `netkingdom-bootstrap-console` and `openbao-admin` are
browser clients carrying neither field, while `rapp-qonto-client`,
`secrets-engine-approval` and `approval-engine-operator` carry both legitimately
on the `client_credentials` path. The rule rejects none of them. Kept as errors
rather than downgraded to warnings on that evidence: a warning for a field that
does nothing is the state this change exists to end.
**`tenant` is deliberately excluded from the rule**, and a test pins that. A
browser client may declare a tenant; `humanTenant` resolves it against the
directory and refuses issuance when the two disagree (KEY-WP-0013-T05). An
@ -46,6 +58,7 @@ feature unusable.
id: KEY-WP-0028-T02
status: done
priority: medium
state_hub_task_id: "5ab951f8-2f9c-522c-b6ea-7f6d572cd618"
```
This work started from KEY-WP-0013-T05's blocker paragraph, which described a