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

Write the key-cape client registration contract (T07 progress)

Browse source 
Everything except the host is now fixed: client_id informed-decision-approver,
callback path /auth/callback, authorization-code + S256 PKCE public client,
scopes [openid, approval:read, approval:approve], the expected token shape, and
the assurance shape cited from key-cape's contract rather than restated so it
cannot drift.

Section 5 declares the tenant provenance rather than assuming it. Nothing
populates domain.User.Tenant for approver users, so declaring tenant:platform
reaches the token by the gap route by construction rather than by accident.
GH-DEC-2026-013 was explicit that a tenant the directory does not carry must not
be declared unless we are prepared to say so in the record — so it is said,
with the two consequences: the claim is stored with its provenance, and it is
never used as the act-scope.

Deliberately NOT submitted. The origin needs a DNS A record, an Ingress manifest
and a certificate, which is work in railiance-apps rather than here.
decide.coulomb.social is proposed and consistent with the estate's existing
Traefik/TLS-per-host pattern, but proposing a plausible hostname is not the same
as owning one, and submitting a redirect for a host that does not resolve is the
exact failure approval-engine avoided by refusing to invent these strings.

T07 stays progress with the deployment dependency named and owned elsewhere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
This commit is contained in:
tegwick 2026-09-10 08:06:10 +02:00
parent 7e7ad0293c
commit 50367d0d78
2 changed files with 191 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

24
workplans/INFD-WP-0001-founding-specs-and-approver-ui-ownership.md
View file

@ -326,7 +326,7 @@ deployed.
```task
id: INFD-WP-0001-T07
status: todo
status: progress
priority: high
state_hub_task_id: "38a83a76-f152-55bf-8a9a-6132fd6d9642"
```
@ -366,6 +366,28 @@ The one remaining input is the **deployed origin**. Redirects match exactly, so
`client_id` and the callback URI must name a real origin — the reason not to
publish is now solely that, and no longer the tenant.
2026-09-10: `docs/keycape-client-registration.md` written and everything except
the host is fixed — `client_id` `informed-decision-approver`, callback path
`/auth/callback`, authorization-code + S256 PKCE public client, scopes
`[openid, approval:read, approval:approve]`, the expected token shape, and the
`assurance` shape cited from `key-cape` rather than restated so it cannot drift.
§5 declares the tenant provenance rather than assuming it. Nothing populates
`domain.User.Tenant` for approver users, so declaring `tenant:platform` reaches
the token by the **gap route by construction**, not by accident.
`GH-DEC-2026-013` was explicit that a tenant the directory does not carry must
not be declared unless we are prepared to say so in the record. We are, and it
is said there, along with the two consequences: the claim is stored with its
provenance, and it is never used as the act-scope.
**Not submitted, and the task stays `progress`.** The origin
(`decide.coulomb.social` proposed, consistent with the estate's existing
Traefik/TLS-per-host pattern) needs a DNS A record, an Ingress manifest and a
certificate — work in `railiance-apps`, not here. Submitting a redirect for a
host that does not resolve is the exact failure `approval-engine` avoided by
refusing to invent these strings in the first place, and choosing a plausible
hostname is not the same as owning one.
Superseded context: 2026-09-09: blocked on `INFD-IN-0002`. `key-cape` found that a human access
token cannot carry `tenant:platform` today — the tenant claim resolves from a
directory record no adapter populates, so every human token falls back to