tegwick
da7bc31d45
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 32s
Answers the GLAS-WP-0015 tenant-alignment request. The JWT tenant is tenant:coulomb for all four reviewed service registrations; the approval store tenant and the policy tenant belong to other owners and KeyCape does no normalization between them. No mapping is invented and no live registration changes. Adds regression tests proving the tenant claim is bound at registration and is not influenced by request parameters, that distinct registrations never carry each other's tenant, and that human tokens fall back to the platform tenant rather than an empty claim. 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
83 lines
3.5 KiB
Markdown
83 lines
3.5 KiB
Markdown
---
|
|
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"
|
|
updated: "2026-09-06"
|
|
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 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.
|
|
|
|
## Reconcile tenant vocabularies across approval layers
|
|
|
|
```task
|
|
id: KEY-WP-0013-T03
|
|
status: done
|
|
priority: high
|
|
```
|
|
|
|
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.
|