coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Register the approver client now its callback exists
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 47s
Details

Browse source 
informed-decision submitted client_id informed-decision-approver and redirect
https://decisions.coulomb.social/auth/callback, with the origin already live and
verified by them rather than reported: both / and /auth/callback return 200 on a
Let's Encrypt certificate valid to 2026-12-09. The host is decisions, not the
decide of an earlier draft. Its path serves a placeholder for now, which does not
matter -- the redirect is matched as an exact string and never fetched.

Published as a public authorization_code client with S256 PKCE, audience
approval-engine, scopes openid/approval:read/approval:approve, mfaRequired true
and a declared tenant:platform. No secretRef, since PKCE is the whole proof.

TestApproverRegistrationShapeIsExact pins every field, so widening a scope or
relaxing MFA fails the build rather than reading as an edit, and asserts the
registration passes startup validation -- proving the KEY-WP-0028 tenant
exemption holds for the registration that actually depends on it.

Two existing guards fired on the way in and neither was loosened. The tenant pin
refused an unreviewed client carrying a tenant, which is its purpose, so the
approver was added to its reviewed set deliberately. And the audience test
panicked slicing secretRef[4:], an assumption that held while the fixture had
only confidential clients; the approver is the first public one, so the loop now
guards on the env: prefix.

The declared tenant reaches the token by the GH-DEC-2026-013 gap route by
construction, and tenant_source says so: registration, never directory.

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
This commit is contained in:
tegwick 2026-09-10 22:50:13 +02:00
parent f9812ab3b2
commit c9bb7fac58
5 changed files with 226 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

40
docs/approval-engine-auth-contract.md
View file

@ -13,12 +13,32 @@ gets lifecycle/observation scopes without consume. Service tokens contain
audience, issue time and expiry; the lifetime is 15 minutes. The issuer signs
with RS256 and publishes its public key through `/jwks`.
Human approvers need a separate authorization-code/PKCE registration with an
exact deployment-owned callback, `audience: approval-engine`,
`allowedScopes: [openid, approval:read, approval:approve]`, and
`mfaRequired: true`. Do not add consume or other approval grants to that client.
No callback is invented here. The ID token is for the login client; present the
access token to approval-engine.
Human approvers use the `informed-decision-approver` registration, submitted by
informed-decision on 2026-09-10 (INFD-WP-0001-T07) and published in
`config/service-clients.example.yaml`:
| Field | Value |
| --- | --- |
| `clientId` | `informed-decision-approver` |
| `redirectUris` | `https://decisions.coulomb.social/auth/callback` (exact, sole) |
| `clientType` | `public` — PKCE is the whole proof; no secret |
| `grantTypes` | `authorization_code` with S256 PKCE |
| `audience` | `approval-engine` |
| `allowedScopes` | `openid`, `approval:read`, `approval:approve` |
| `mfaRequired` | `true` |
| `tenant` | `tenant:platform`, declared |
The host is `decisions.coulomb.social`, not the `decide.coulomb.social` an
earlier draft proposed; the origin was verified live before submission. The path
currently serves a placeholder while the surface is gated on
APPROVAL-WP-0002-T01, which does not affect the registration — the redirect is
matched as an exact string at `/authorize` and never fetched.
Do not add consume or other approval grants to that client. The ID token is for
the login client; present the access token to approval-engine.
`TestApproverRegistrationShapeIsExact` pins every field above, so widening a
scope or relaxing the MFA requirement fails the build rather than passing as an
edit.
That client must also declare `tenant: tenant:platform`. A human token's tenant
comes from the directory record, which assigns none today, so without the
@ -63,10 +83,10 @@ These fragments are not live registrations. The two service registrations requir
custody-managed values for the named environment references and a reviewed
rollout of this version, including the upstream issuer precondition. Platform's
CCR-2026-0017/0018 use OpenBao field `CLIENT_SECRET`; their approval remains open.
The separate human registration needs its actual UI-owned callback. A bearer-only
approval resource server has no such callback; its absence does not prevent
service-client issuance or service startup, and service credentials cannot be
counted as human approval evidence. Never log the token or secret. Verify the resulting
The human registration now carries its real UI-owned callback (above); a
bearer-only approval resource server never owned that string, which is why it
came from informed-decision. Service credentials still cannot be counted as human
approval evidence. Never log the token or secret. Verify the resulting
access token against the deployed issuer's `/jwks`, checking issuer, audience,
expiry, subject, principal type, tenant, roles, scope and assurance. Verify that
operator consume and human consume requests are rejected. Local tests verify