key-cape/workplans/KEY-WP-0013-approval-engine-resource-audience.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
KEY-WP-0013	workplan	Approval-engine resource audience and client registrations	infotech	key-cape	blocked	codex	approval-engine-resource-audience	2026-09-05	2026-09-08	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

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

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 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-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.

Reconcile tenant vocabularies across approval layers

id: KEY-WP-0013-T03
status: done
priority: high
state_hub_task_id: "e98da2eb-1f05-5c7f-bc84-711fa38b8c4a"

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 tenant:platform

id: KEY-WP-0013-T04
status: done
priority: high
state_hub_task_id: "d93e21cc-a422-5e78-981f-9c00f3161375"

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.