2026-09-05 00:41:17 +02:00
|
|
|
---
|
|
|
|
|
id: KEY-WP-0013
|
|
|
|
|
type: workplan
|
|
|
|
|
title: "Approval-engine resource audience and client registrations"
|
|
|
|
|
domain: infotech
|
|
|
|
|
repo: key-cape
|
|
|
|
|
status: blocked
|
|
|
|
|
owner: codex
|
|
|
|
|
topic_slug: approval-engine-resource-audience
|
|
|
|
|
created: "2026-09-05"
|
Close the KEY-WP-0009 handoff gap and deliver the two blocked admissions
KEY-WP-0009-T04 is done. Re-ran verification on main with an explicit Go 1.23.0
toolchain and a writable build cache: contract validator PASS, build, vet and the
full test suite pass, git diff --check clean. gofmt had drifted on
internal/server/telemetry/events.go and tests/migration/scenario_c_test.go
(comment alignment only, no semantic change); both reformatted so the task's
formatting claim holds. The four handoffs to netkingdom, secrets-engine,
ops-warden and railiance-platform were then actually sent -- the 2026-09-05 audit
had shown the earlier claimed delivery had no receipts -- and each receipt id is
recorded in the workplan and readable back from the hub.
KEY-WP-0013-T02 and KEY-WP-0014-T04 stay in wait. Their remaining work is not
ours to do, so what was owed was the request, and it is now delivered: custody
admission for the two approval clients to railiance-platform, the exact human
client id and callback URI to approval-engine, and the OpenBao-token vs
issuer-JWT split plus Qonto rotation execution authority to ops-warden. Each
message quotes the existing non-secret packet or reviewed sequence and states
what is explicitly not being treated as authorization.
No secret was read, no production resource changed, no route retired.
SCOPE.md updated to match.
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
2026-09-08 10:22:52 +02:00
|
|
|
updated: "2026-09-08"
|
2026-09-05 00:41:17 +02:00
|
|
|
state_hub_workstream_id: "6e815d88-b0e3-5ce0-be5d-13ab15917f7f"
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
Source: approval-engine inbox request 5583e896-52f2-45bd-895f-02f227b7e836,
|
|
|
|
|
reviewed against its local registration and caller-authentication contracts.
|
|
|
|
|
|
|
|
|
|
## Implement static resource audiences
|
|
|
|
|
|
|
|
|
|
```task
|
|
|
|
|
id: KEY-WP-0013-T01
|
|
|
|
|
status: done
|
|
|
|
|
priority: high
|
|
|
|
|
state_hub_task_id: "a92432a2-4e92-5b90-be2b-d82b784bf8f0"
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Added optional static audience configuration for access tokens in both grants;
|
|
|
|
|
ID tokens retain the relying-party audience. Added human access-token scope.
|
|
|
|
|
Published bounded approval service fragments and the human registration contract.
|
|
|
|
|
Regression tests cover the default audience, request override resistance, JWKS
|
|
|
|
|
signature validation, ID-token separation and service registration scope isolation.
|
|
|
|
|
Browser requests and token exchanges now enforce the client scope allow-list,
|
|
|
|
|
including grants removed after authorization.
|
|
|
|
|
|
|
|
|
|
## Provision and prove live registrations
|
|
|
|
|
|
|
|
|
|
```task
|
|
|
|
|
id: KEY-WP-0013-T02
|
|
|
|
|
status: wait
|
|
|
|
|
priority: high
|
|
|
|
|
state_hub_task_id: "607897c5-bad9-55e5-86df-7802f592d6e8"
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Needs deployment-owned custody for both new secret references and an exact human
|
|
|
|
|
callback registration. Deploy the implementation and registrations together,
|
|
|
|
|
then prove live JWKS verification and denied excess scopes without logging values.
|
|
|
|
|
Local signature proof is not live rollout evidence. See docs/approval-engine-auth-contract.md.
|
2026-09-05 01:08:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-05 follow-up: read-only deployment metadata shows the current image is
|
|
|
|
|
forgejo.coulomb.social/coulomb/key-cape:main-153258b and only the Qonto service
|
|
|
|
|
secret environment reference is present. The two approval clients are not
|
|
|
|
|
materialized through deployment environment references. Published a concrete
|
|
|
|
|
non-secret admission packet at docs/approval-engine-provisioning-request.yaml.
|
|
|
|
|
Custody routing has no exact admitted lane for these two clients. `warden plan`
|
|
|
|
|
returned founder_required but matched an unrelated generic database lane; that
|
|
|
|
|
mismatch is not authority to provision. Human callback clarification is pending.
|
|
|
|
|
No secrets were read or production resources changed.
|
2026-09-06 20:33:06 +02:00
|
|
|
|
Close the KEY-WP-0009 handoff gap and deliver the two blocked admissions
KEY-WP-0009-T04 is done. Re-ran verification on main with an explicit Go 1.23.0
toolchain and a writable build cache: contract validator PASS, build, vet and the
full test suite pass, git diff --check clean. gofmt had drifted on
internal/server/telemetry/events.go and tests/migration/scenario_c_test.go
(comment alignment only, no semantic change); both reformatted so the task's
formatting claim holds. The four handoffs to netkingdom, secrets-engine,
ops-warden and railiance-platform were then actually sent -- the 2026-09-05 audit
had shown the earlier claimed delivery had no receipts -- and each receipt id is
recorded in the workplan and readable back from the hub.
KEY-WP-0013-T02 and KEY-WP-0014-T04 stay in wait. Their remaining work is not
ours to do, so what was owed was the request, and it is now delivered: custody
admission for the two approval clients to railiance-platform, the exact human
client id and callback URI to approval-engine, and the OpenBao-token vs
issuer-JWT split plus Qonto rotation execution authority to ops-warden. Each
message quotes the existing non-secret packet or reviewed sequence and states
what is explicitly not being treated as authorization.
No secret was read, no production resource changed, no route retired.
SCOPE.md updated to match.
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
2026-09-08 10:22:52 +02:00
|
|
|
2026-09-08: the two blocking requests were sent and their receipts are readable
|
|
|
|
|
back via `GET /messages/?from_agent=key-cape`.
|
|
|
|
|
|
|
|
|
|
- `278a3ebe-b529-49f6-bd1a-e3ebcf318260` -> railiance-platform. Custody admission
|
|
|
|
|
for both clients, quoting `docs/approval-engine-provisioning-request.yaml`
|
|
|
|
|
verbatim: exact OpenBao paths and `client_secret` field, the two Kubernetes
|
|
|
|
|
delivery references, the two `KEYCAPE_*_CLIENT_SECRET` environment names,
|
|
|
|
|
`tenant:platform` per decision `5ed3fb35-eca9-413a-82b9-95171ba85bf6`, and the
|
|
|
|
|
15m lifetime. It asks for four things explicitly: confirm/correct the paths and
|
|
|
|
|
fields, confirm the delivery references, name the authority for the attended
|
|
|
|
|
first provision, and agree a rollout window in which registrations and the
|
|
|
|
|
KeyCape version that reads them deploy together. It restates that the
|
|
|
|
|
`warden plan` `founder_required` result matched an unrelated generic database
|
|
|
|
|
lane and is not being treated as authorization.
|
|
|
|
|
- `43fbd997-6e22-4859-8433-58b784c2df6c` -> approval-engine. Requests the two
|
|
|
|
|
missing human-registration inputs — the exact `client_id` and the full callback
|
|
|
|
|
URI — noting redirects are matched exactly and a near-miss fails closed at
|
|
|
|
|
`/authorize`. Restates the human client shape (public, S256 PKCE,
|
|
|
|
|
`audience: approval-engine`, `allowedScopes: [openid, approval:approve]`,
|
|
|
|
|
`mfaRequired: true`, no consume grant) and asks approval-engine to confirm it
|
|
|
|
|
validates the access token, not the ID token, against the deployed `/jwks`.
|
|
|
|
|
|
|
|
|
|
Deployment state is unchanged from the 2026-09-05 observation: neither approval
|
|
|
|
|
client is materialized. Task remains `wait` — the two admissions are owned by
|
|
|
|
|
railiance-platform and approval-engine respectively, and live provisioning proof
|
|
|
|
|
cannot begin until both land. Still no secret read and no production resource
|
|
|
|
|
changed.
|
|
|
|
|
|
Ship the live-registration check both blocked tasks depend on
KEY-WP-0013-T02 and KEY-WP-0014-T04 stay blocked on custody and on ops-warden,
but each contains a KeyCape-owned piece that had been left as prose. T02 requires
proving "live JWKS verification and denied excess scopes without logging values";
T04 step 4 requires verifying a rotated secret, refusing its predecessor and
refusing excess scope. Both were describable and neither was runnable, so the
proof would have been improvised by hand against production at the moment custody
lands -- the worst possible time for it.
keycape verify-client does it in one command. Per registration it checks
discovery origin, the client_credentials exchange and its RS256 signature against
the deployed JWKS, exact sub/tenant/roles/principal_type, that every -deny-scope
is refused, and that the token carries no scope that was not requested. That last
check is a real gap: the caller commands prove every requested scope was granted,
never that nothing extra came back. -previous-secret-env additionally requires
the predecessor to be refused, and treats an unchanged secret as a rotation that
did not happen.
Nothing is written to disk and no value is printed. Failures name the claim, not
the observed value, so running this against production cannot turn a verification
into a disclosure. Every check runs before it reports, so one failure does not
hide the rest.
The exact invocation for each approval client is recorded in the verification
block of the provisioning packet, so custody admission hands back a command
rather than a description.
Tests cover the passing case, an over-broad registration, a live predecessor, an
identical rotation and output non-disclosure; neutering mustFail makes the suite
fail, so the checks have teeth.
Also recorded in KEY-WP-0014: read from ops-warden's catalog rather than waiting
for a reply, key-cape-oidc-login is asked-and-waiting on us since 2026-08-28 and
is a pointer lane with no programmatic consumers, and the rapp-qonto-keycape-client
blocker citing an absent native exchange command went stale when service-token
shipped on 2026-09-05.
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
2026-09-08 14:30:43 +02:00
|
|
|
2026-09-08, second pass. Custody and the human callback are still owed, but one
|
|
|
|
|
part of this task was ours all along and was not built: the task requires proving
|
|
|
|
|
"live JWKS verification and denied excess scopes without logging values", and
|
|
|
|
|
there was no way to do that except by hand, against production, at the moment
|
|
|
|
|
custody lands — which is the worst time to be improvising a check.
|
|
|
|
|
|
|
|
|
|
Shipped `keycape verify-client` (`src/internal/authclient/verify.go`, documented
|
|
|
|
|
in `docs/native-authentication.md`). Per registration it verifies discovery
|
|
|
|
|
origin, the `client_credentials` exchange and its RS256 signature against the
|
|
|
|
|
deployed JWKS, exact `sub`/`tenant`/`roles`/`principal_type`, that every
|
|
|
|
|
`-deny-scope` is refused, and that the token carries no scope that was not
|
|
|
|
|
requested — the last being a gap the caller commands do not cover, since they
|
|
|
|
|
prove requested scopes were granted and not that nothing extra came back.
|
|
|
|
|
Failures name the claim, never the observed value, and nothing is written to
|
|
|
|
|
disk, so it is safe to run against production. The exact invocation for each of
|
|
|
|
|
the two clients is now recorded in the `verification:` block of
|
|
|
|
|
`docs/approval-engine-provisioning-request.yaml`, so admission hands back a
|
|
|
|
|
command rather than a description.
|
|
|
|
|
|
|
|
|
|
Tests: `src/internal/authclient/verify_test.go` covers the passing case, an
|
|
|
|
|
over-broad registration, a live predecessor secret, an identical "rotation" and
|
|
|
|
|
output non-disclosure. Verified with teeth — neutering `mustFail` makes the suite
|
|
|
|
|
fail rather than pass silently.
|
|
|
|
|
|
|
|
|
|
Task stays `wait`. What is owed from elsewhere is unchanged and unreduced: the
|
|
|
|
|
two secret values through an admitted custody path, and the exact human
|
|
|
|
|
`client_id` and callback URI. Nothing here provisions anything.
|
|
|
|
|
|
2026-09-06 20:33:06 +02:00
|
|
|
## Reconcile tenant vocabularies across approval layers
|
|
|
|
|
|
|
|
|
|
```task
|
|
|
|
|
id: KEY-WP-0013-T03
|
|
|
|
|
status: done
|
|
|
|
|
priority: high
|
Align approval registrations to the tenant:platform decision
Operator decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 accepts tenant:platform
as the platform management tenant for the Glas approval chain, requiring exact
spelling across the approval store, the service-client JWT claim and the
lifecycle CheckRequest.
Changes the tenant field on secrets-engine-approval and approval-engine-operator
only, in the registration fixture and the provisioning packet. Unrelated clients
and the human directory default keep tenant:coulomb, and no audience, scope,
subject, role, lifetime or MFA grant changes.
Adds issuance evidence that the approval shape emits tenant:platform exactly and
never an alias the caller requests, that the OpenBao client gains no
cross-tenant reach, and a fixture guard pinning every reviewed client's tenant.
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
2026-09-06 22:30:32 +02:00
|
|
|
state_hub_task_id: "e98da2eb-1f05-5c7f-bc84-711fa38b8c4a"
|
2026-09-06 20:33:06 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Source: glas-harness inbox message 356f6977-d361-4e3b-83ab-b2c7f4759286
|
|
|
|
|
(GLAS-WP-0015), which asks for the exact store tenant, JWT tenant, CheckRequest
|
|
|
|
|
tenant, any permitted mapping and wrong-tenant denial evidence.
|
|
|
|
|
|
|
|
|
|
Published `docs/tenant-claim-contract.md`. The KeyCape-owned JWT tenant for all
|
|
|
|
|
four reviewed service registrations is `tenant:coulomb`, bound at registration
|
|
|
|
|
and required by config validation. Approval store `platform` and policy
|
|
|
|
|
`tenant:platform` are owned by approval-engine and flex-auth; KeyCape performs no
|
|
|
|
|
normalization or aliasing, so exact comparison does not match today. No mapping
|
|
|
|
|
was invented and no live registration or policy subject was changed — the two
|
|
|
|
|
admissible resolutions are recorded for the owning parties to decide.
|
|
|
|
|
|
|
|
|
|
Added `src/internal/server/oidc/tenant_test.go`: request-supplied `tenant` and
|
|
|
|
|
`tenant_hint` cannot alter the claim; two registrations never carry each other's
|
|
|
|
|
tenant (the wrong-tenant denial basis); human tokens default to `tenant:coulomb`
|
|
|
|
|
rather than an empty claim. Local issuance proof only, not live-rollout evidence.
|
Align approval registrations to the tenant:platform decision
Operator decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 accepts tenant:platform
as the platform management tenant for the Glas approval chain, requiring exact
spelling across the approval store, the service-client JWT claim and the
lifecycle CheckRequest.
Changes the tenant field on secrets-engine-approval and approval-engine-operator
only, in the registration fixture and the provisioning packet. Unrelated clients
and the human directory default keep tenant:coulomb, and no audience, scope,
subject, role, lifetime or MFA grant changes.
Adds issuance evidence that the approval shape emits tenant:platform exactly and
never an alias the caller requests, that the OpenBao client gains no
cross-tenant reach, and a fixture guard pinning every reviewed client's tenant.
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
2026-09-06 22:30:32 +02:00
|
|
|
|
|
|
|
|
## Align approval registrations to tenant:platform
|
|
|
|
|
|
|
|
|
|
```task
|
|
|
|
|
id: KEY-WP-0013-T04
|
|
|
|
|
status: done
|
|
|
|
|
priority: high
|
Harden the authorization-code grant and UserInfo verification
Closes the local protocol surface of gap G01 from the scope assessment
(KEY-WP-0016). The browser grant validated PKCE, client id and scopes but left
four bindings unenforced, and UserInfo verified less than the caller CLI does.
Authorization-code path: bind the exchange to the redirect URI the code was
issued for, refuse clients whose registration does not permit the grant, and
authenticate confidential clients with a digest-based constant-time comparison
over the same credential sources as the service grant. An empty grantTypes stays
an implicit authorization-code client, matching config validation.
Code consumption: SessionStore.Consume reads and deletes under one lock. The
previous Get/Delete pair spanned JWT signing, and the added test reproduces the
race against that version -- 9 of 16 concurrent exchanges succeeded, and a
failed exchange left the code replayable.
UserInfo: check the JOSE header algorithm before trusting the signature, require
the configured issuer, and require an access token rather than accepting an ID
token of the right shape. Purpose is decided on the scope claim so the issued
token contract, which consumers pin exactly, does not change.
SCOPE.md and the assessment record which bindings are now enforced and that the
Authelia upstream-trust assumption remains open, so G01 is not fully closed and
no profile-conformance claim is made.
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
2026-09-06 22:43:47 +02:00
|
|
|
state_hub_task_id: "d93e21cc-a422-5e78-981f-9c00f3161375"
|
Align approval registrations to the tenant:platform decision
Operator decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 accepts tenant:platform
as the platform management tenant for the Glas approval chain, requiring exact
spelling across the approval store, the service-client JWT claim and the
lifecycle CheckRequest.
Changes the tenant field on secrets-engine-approval and approval-engine-operator
only, in the registration fixture and the provisioning packet. Unrelated clients
and the human directory default keep tenant:coulomb, and no audience, scope,
subject, role, lifetime or MFA grant changes.
Adds issuance evidence that the approval shape emits tenant:platform exactly and
never an alias the caller requests, that the OpenBao client gains no
cross-tenant reach, and a fixture guard pinning every reviewed client's tenant.
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
2026-09-06 22:30:32 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Source: glas-harness inbox message f487c63a-dd7e-4ad8-9188-eec9fbea59c6,
|
|
|
|
|
operator decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 ("Use tenant:platform for
|
|
|
|
|
the Glas approval dependency chain", verified resolved in the hub). This closed
|
|
|
|
|
resolution 2 of the two options recorded in KEY-WP-0013-T03.
|
|
|
|
|
|
|
|
|
|
Changed the `tenant` field on exactly `secrets-engine-approval` and
|
|
|
|
|
`approval-engine-operator` in `config/service-clients.example.yaml` and the two
|
|
|
|
|
matching entries in `docs/approval-engine-provisioning-request.yaml` to
|
|
|
|
|
`tenant:platform`, each annotated with the decision id. `codex-railiance-platform`,
|
|
|
|
|
`secrets-engine-openbao` and the human directory default keep `tenant:coulomb`.
|
|
|
|
|
No audience, scope, subject, role, lifetime or MFA change; no cross-tenant grant.
|
|
|
|
|
|
|
|
|
|
Evidence: `TestApprovalClientIssuesExactPlatformTenantAndRejectsAliases` (exact
|
|
|
|
|
`tenant:platform` with `aud=approval-engine` even when the caller requests
|
|
|
|
|
`platform`, `tenant:coulomb` or `TENANT:PLATFORM`),
|
|
|
|
|
`TestUnrelatedServiceClientKeepsCoulombTenant`, and
|
|
|
|
|
`TestServiceRegistrationTenantsAreExactPerDecision`, which pins every reviewed
|
|
|
|
|
client's tenant against the real fixture so a reintroduced alias fails the build.
|
|
|
|
|
Full `go test ./...` and `go vet ./...` pass. Choice only — live provisioning and
|
|
|
|
|
the other admission gates remain with KEY-WP-0013-T02.
|