coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
key-cape/workplans/KEY-WP-0013-approval-engine-resource-audience.md
tegwick 139b6ff351
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 37s
Details
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

5 KiB
Raw Blame History

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

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.