coulomb/approval-engine
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record the approval-engine coordination follow-up.

Browse source 
Reconfirm that approval-engine-operator has no presenter and accept the amended CCR-2026-0018 removal. Name the separate create-only informed-decision requester. Keep the Access claim and fractional-time tasks waiting on consumer evidence, and refresh the repository-rename intake check.

Assistant: grok
Assistant-Session: 01a16889-9224-7ec0-bee0-2a46dd3819c4
This commit is contained in:
tegwick 2026-10-23 15:43:26 +02:00
parent a3564edc25
commit a8397abdc7
4 changed files with 29 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

13
docs/keycape-service-registrations.md
View file

@ -137,7 +137,7 @@ Scope by scope, the bundle we originally requested does not describe one actor:
| Scope | Who would present it |
| --- | --- |
| `approval:create` | whoever *requests* an approval. Not named anywhere in the estate today; `gate-house` doctrine says which acts need one, but no requester identity has been settled |
| `approval:create` | `informed-decision-sitting-requester` (create-only, `sub=informed-decision`). It is not `approval-engine-operator`. A human still binds at `/entries` |
| `approval:approve` | `informed-decision`'s **human** client, per its own registration. A service principal holding this is exactly the question `gate-house` has not ruled on — see the `principal_type` note below |
| `approval:read` | anything rendering or inspecting an approval |
| `approval:revoke`, `approval:supersede` | attended lifecycle operations |
@ -179,13 +179,22 @@ Standing capability with no counterparty is a worse resting state than either
extreme: it serves no one, and it is the shape found later by someone other
than its owner.
**Decision, as requesting owner: disable the registration, keep the custody.**
**Decision, as requesting owner (2026-09-10): disable the registration, keep the custody.**
Not delete. `CCR-2026-0018` verifier custody stands, so the client remains
authenticable and restorable the moment a presenter is named; the re-request
constraint above still applies — narrowed to that presenter, and
`approval:approve` must not travel with the operational scopes. key-cape
executes the disablement with railiance-platform as the deployment change.
**Amended 2026-10-23:** still no presenter. `informed-decision-sitting-requester`
does not present this client. approval-engine accepts the joint removal in
key-cape message `ffe5aff4` as amended by railiance-platform `RPF-WP-0035-T10`:
remove the registration, prove `invalid_client`, remove the KeyCape env and the
operator-client ExternalSecret, then metadata-delete
`platform/workloads/approval-engine/operator-client`. A later presenter gets a
new narrowed registration and a fresh secret. `approval:approve` still does not
travel with operational scopes. approval-engine does not run that window.
The middle option — leaving it standing with a recorded expiry — was rejected
deliberately. An expiry is a promise to act later on a capability that is
dangerous now, and the thing it protects against is precisely the case where