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

feat: exchange scoped approval service tokens per request
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-luna
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
This commit is contained in:
tegwick 2026-09-09 07:06:05 +02:00
parent 3a19069b4b
commit 7688445184
14 changed files with 859 additions and 35 deletions
Download patch file Download diff file Expand all files Collapse all files

35
workplans/SECRETS-WP-0009-glas-claude-native-delivery.md
View file

@ -7,7 +7,7 @@ repo: secrets-engine
status: blocked
owner: codex
created: "2026-09-05"
updated: "2026-09-05"
updated: "2026-09-09"
state_hub_workstream_id: "40ccc3b4-d046-5a58-8649-e7935f45c974"
---
@ -148,3 +148,36 @@ and negative access, register delivery-ready evidence, bind owner exec with
service authentication, and return verified pins/evidence to SAND-WP-0015 and
GLAS-WP-0012. Provider scope/budget and expiry remain explicit acceptance inputs.
Keep the catalog route inactive until real verification passes.
### 2026-09-09 consumer identity implementation and component proof
The "one external dependency" statement above concealed another local seam:
claim and consume could only read a manually supplied bearer-token file. The
OpenBao service-JWT provider cannot be reused with approval credentials because
its audience, tenant and scope are different.
Implemented the separate secrets-engine-approval provider and wired it into
both actual claim/consume call sites. It requests only read or consume for the
current request, keeps the token in memory, rejects mixed providers, and never
falls back on exchange failure. The exact service:secrets-engine / approval-engine /
tenant:platform identity and scope/time bounds are preflighted. Credential-bearing
redirects and unsupported approval endpoint shapes are refused.
The pinned real KeyCape image exposed a second defect: the shared consumer
expected assurance.aal/method but the issuer emits assurance.level/methods.
Corrected to the issuer's actual source contract, with regression coverage.
The real Approval Engine JWT verifier and SQLite store then accepted the actual
consumer's claim/check/consume chain in a disposable component exercise. Wrong
action/secret, spent claim, different digest and operator consume scope are
refused; same-digest consume retries are idempotent. Only the PDP was a test
double. The suite passed 350 tests; no production credential was read.
Contract and repeatable exercise: docs/approval-service-auth.md; receipt:
docs/evidence/2026-09-09-approval-identity-exercise.json.
T03 remains wait for RPF-WP-0035-T06's separately admitted client-side reader,
AUDIT-WP-0009-T09 audit custody, APPROVAL-WP-0002 live endpoint/claim/consume,
and the existing exact native OpenBao authority/delivery returns. The synthetic
proof does not grant these. KEY-WP-0013-T02 and verifier CCR-2026-0017/0018
are complete and must not be requested again. No new workplan duplicates T03.