47 lines
2.8 KiB
Markdown
47 lines
2.8 KiB
Markdown
# HelixForge approval consumer — 2026-09-09
|
|
|
|
The consumer implementation now removes manual approval-token renewal from the
|
|
intended factory path. Secrets Engine exchanges its own client secret immediately
|
|
before claim and consume, requests only the relevant scope, and holds the access
|
|
token in memory. Live credential delivery remains separately gated.
|
|
|
|
The pinned KeyCape image exposed a consumer incompatibility missed by its old
|
|
fixtures: `assurance.aal/method` was assumed; the issuer emits
|
|
`assurance.level/methods`. The shared consumer now validates the actual shape.
|
|
OpenBao and approval client identities retain their distinct audiences, tenants
|
|
and scopes. Mixed providers, fallback identities and credential redirects are
|
|
refused.
|
|
|
|
Validation: **350 tests passed**. A repeatable disposable exercise also passed
|
|
**nine checks** using the pinned KeyCape image and real Approval Engine source,
|
|
JWT/JWKS verifier and SQLite store. It proved operator create/approve, consumer
|
|
claim/check/consume, idempotent retry and the specified action/claim/secret/scope
|
|
refusals. Temporary resources were removed; exact consumer module hashes are
|
|
recorded in the [evidence](2026-09-09-helixforge-approval-consumer.json).
|
|
|
|
The PDP was a sequencing double. This proves the identity/consumer integration,
|
|
not a production authorization path, native OpenBao delivery or factory
|
|
throughput. No live credential was retrieved and no paid model ran.
|
|
|
|
Work coordination now reflects the actual scope:
|
|
|
|
- **RPF-WP-0035-T05 is done** against the completed verifier-only acceptance.
|
|
**RPF-WP-0035-T06** is its live client-side admission residual. The already
|
|
completed CCR reviews must not recur as blockers.
|
|
- **SECRETS-WP-0008-T02 is progress** for the returned FLEX-DEC-2026-012 contract.
|
|
The consumer must use `submitted_request_digest` for its exact request and
|
|
compare the approval digest between evaluator outputs. This is actionable
|
|
local implementation, with no outstanding interpretation question.
|
|
- **SECRETS-WP-0009-T03 remains wait** for that replay correction plus separate
|
|
client-side admission, audit custody, live approval deployment and native
|
|
credential authority/delivery. The identity exercise does not close these.
|
|
|
|
The next implementation is the submitted-request replay and approval-digest join,
|
|
tested against independently published owner fixtures. Then complete the two
|
|
consumer admissions and audit sender/receiver custody, deploy Approval Engine,
|
|
and prove native delivery before admitting a bounded Railiance worker run.
|
|
|
|
The first internal capability remains reuse-surface; Railiance Fabric remains a
|
|
candidate for broader reuse. vergabe-teilnahme remains the primary customer
|
|
product repository. Progress toward that goal is reduced manual integration and
|
|
fewer misleading waits; sustained factory throughput has not yet been measured.
|