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

Let a human token carry the zone it is issued into, without relabelling anyone
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 46s
Details

Browse source 
KEY-WP-0013-T05's tenant blocker did not need the decision it was waiting on. The
two proposed resolutions differ in where a human's tenant comes from -- the
directory record, or the client registration -- and an implementation exists that
is correct under either, so the choice can be made later without another
migration.

A client registration may now declare a tenant. humanTenant() resolves it by four
rules: no declaration keeps the directory answer unchanged; a declared zone
applies where the directory has placed the user nowhere; agreement passes; and a
declared zone conflicting with a directory assignment refuses issuance rather
than relabelling the user.

The refusal is the design, not an edge case. A registration can bind a zone for
unplaced users and can never move a placed one, so this gets the approval chain
its tenant:platform without writing a general cross-tenant override into the
issuer. It fails closed rather than picking a winner, because either answer would
be a silent cross-tenant assertion, and it reports 403 with
error_type: tenant_binding so an operator can tell a misconfigured registration
from a rejected login. If the owners later populate directory tenants, the same
code stops supplying the zone and starts enforcing agreement with it.

Safe only because client registrations are static and deployment-owned. The
tenant contract records that this rule must be revisited if dynamic client
registration is ever admitted.

Tests cover all four rules; neutering the conflict check fails the relabel test
rather than passing silently.

T05 now waits on one thing only: the client_id and callback URI from
informed-decision once it has a deployed origin.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad
This commit is contained in:
tegwick 2026-09-09 14:40:36 +02:00
parent a73da29093
commit 329e48f64a
13 changed files with 310 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -20,6 +20,12 @@ exact deployment-owned callback, `audience: approval-engine`,
No callback is invented here. The ID token is for the login client; present the
access token to approval-engine.
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
declaration the token would carry `tenant:coulomb` and be refused here. See
[the tenant contract](tenant-claim-contract.md) for the four resolution rules and
for why a declared zone can never relabel a user the directory has placed.
`approval:read` is present because approval-engine showed the surface cannot
render a decision without it: `GET /v1/approvals/{id}` and `/claim` both require
it, so the earlier `[openid, approval:approve]` would have let an approver submit