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

Name the third state SCOPE had no vocabulary for

Browse source 
Folds in two points from the custody owner and a peer session that arrived after
the reassessment landed.

Implemented and unproven is a distinct state from both missing and done, and
SCOPE had no words for it. verify-client's predecessor rejection is written and
unit-tested and has never run against a genuinely distinct predecessor, so this
repository holds a receipt that reads like rotation evidence and is not. Both
owners state that limit independently, which is why it belongs in SCOPE rather
than only in a workplan. "There is a test" and "it has been exercised against the
real thing" now read as separate claims wherever SCOPE makes one.

Also records that the two approval clients' live verification was independently
confirmed by the custody owner, and corrects a conflation this repository made:
client-side retrieval of those secrets is unadmitted and stays so, but the
attended operator path is not a client-side read and never required one. That
conflation is what left T02 recorded as waiting on a run that had already
happened.

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 20:09:01 +02:00
parent 06f39906e9
commit 66ca76cb9c
2 changed files with 27 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

18
SCOPE.md
View file

@ -104,9 +104,21 @@ Keycloak interchangeability are not established.
this was a real fix), and both approval service clients were verified live in an
attended owner process, showing JWKS signature verification, exact claims,
excess-scope and wrong-secret denial at a 900s lifetime
(`2026-09-09-keycape-verifier-admission.json`). Those receipts also decline what
they did not test: no real predecessor rotation and no observed wall-clock
expiry. The deployed image is older than this revision, so the
(`2026-09-09-keycape-verifier-admission.json`), independently confirmed by the
custody owner. That is live evidence for those two clients specifically —
more than a source claim, less than a general one. On the custody boundary:
client-side retrieval of those secrets is unadmitted and stays so, but the
attended operator path is not a client-side read and never required one;
conflating the two is what left this work recorded as waiting on a run that had
already happened. Those receipts also decline what they did not test: no real
predecessor rotation and no observed wall-clock expiry. Those name a **third
state** this document otherwise has no words for — *implemented and unproven*,
distinct from both missing and done. `verify-client`'s predecessor rejection is
written and unit-tested but has never run against a genuinely distinct
predecessor, so this repository holds a receipt that reads like rotation
evidence and is not. Both owners state that limit independently. Read "there is
a test" and "it has been exercised against the real thing" as separate claims
wherever this document makes one. The deployed image is older than this revision, so the
authorization-code bindings, upstream verification, readiness, graceful
shutdown and the two tenant-related changes are **not yet running anywhere** —
see [operations](docs/operations.md), "Unreleased fail-closed startup changes".