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

Record the operator withdrawal and the gate-house tenant conditions

Browse source 
approval-engine answered the presenting-actor question we put to them and the
answer withdrew the client: nobody presents approval-engine-operator. Nothing in
their repository obtains an OAuth token, and scope by scope the bundle never
described a single actor -- approve belongs to the human client, emit is
redundant, and no requester identity was ever settled for create. Annotated as
withdrawn in the example config and the packet rather than deleted, because they
asked for it to stay authenticable under CCR-2026-0018 if a presenter appears.
The separation-of-duties observation is kept because it constrains the
re-request: approve must not travel with the operational scopes.

Raised rather than filed: "do not provision" cannot undo a provision. The client
went live in the 2026-09-09 attended rollout, so the estate now holds a
confidential credential that can create and approve approvals, that nobody
presents, and that no consumer awaits. Standing capability with no counterparty
is a worse resting state than either provisioning it for a named presenter or
disabling it. Disablement is KeyCape's to execute and not KeyCape's to decide
alone, so it goes to the owners rather than into a commit.

Also records GH-DEC-2026-013 conditions (a) and (b) in the tenant contract, both
of which strengthen what we had written about ourselves. Row four is normative,
and in the direction we would not have guessed: a future change preferring the
DIRECTORY is also void, because "the directory won" is still a winner and picking
any winner turns a refusal into a silent cross-tenant assertion. And lifting the
dynamic-registration exclusion now VOIDS the registration-bound shape that day
rather than reopening it for review -- our "must be revisited" was too weak.
The shape is recorded as a declared bounded gap, not the terminal state.

Verification note: the Go suite could not be run green for this commit because a
peer session is mid-edit on token.go and human_tenant_test.go for the §5
provenance work. Every file in this commit is YAML or Markdown; both YAML files
were parsed and the example config's scope set and tenant were asserted unchanged.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad
This commit is contained in:
tegwick 2026-09-09 23:30:09 +02:00
parent 5f516a0fbb
commit d29032d6c4
4 changed files with 90 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -311,6 +311,39 @@ separation-of-duties question about who may hold the credential, not a defect in
the token: KeyCape issues the grants approval-engine requested. The decision is
approval-engine's and the doctrine question is gate-house's.
**Answered 2026-09-09, and the answer withdrew the client.** approval-engine
checked and the presenter is nobody (`056aef0d`). Nothing in their repository
obtains an OAuth token — the engine only verifies them, there is no
client-credentials grant in the package, and the one outbound credential is a
mounted audit-token, not an OAuth client. Scope by scope the bundle never
described a single actor: `approval:approve` now belongs to the informed-decision
human client, `approval:emit` is redundant because the running server emits its
own heartbeat with no token, and no requester identity was ever settled for
`approval:create`. It was a convenience bundle written when a lifecycle operator
was assumed to exist.
They asked railiance-platform to cancel the client-side reader CCR-2026-0020 as
an owner decision. Verifier custody CCR-2026-0018 stands, so the client remains
authenticable if a presenter appears, and they asked for it to be kept on that
basis rather than removed. Annotated as withdrawn in
`config/service-clients.example.yaml` and the provisioning packet; not deleted.
The separation-of-duties observation above is retained because it constrains the
re-request: when a presenter is named the registration comes back **narrowed**,
and `approval:approve` must not travel with the operational scopes.
**One thing "do not provision" cannot undo, raised rather than filed.** This
client is already live — provisioned in the 2026-09-09 attended rollout and
verified in `docs/evidence/2026-09-09-keycape-verifier-admission.json`. So the
estate now holds a confidential credential that can create *and* approve
approvals, that nobody presents, and that no consumer is waiting on. That is
standing capability with no counterparty, which is a worse resting state than
either provisioning it for a named presenter or disabling it. KeyCape owns client
disablement, so the action is ours to take and not ours to decide alone; raised
with approval-engine and railiance-platform rather than exercised, since removing
a live registration is a deployment change. Recorded here so it is not lost:
**an unpresented create+approve credential should not be left standing
indefinitely.**
## Assign and register the human approver browser client
```task