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

Carry approval-engine's store-isolation limit into the tenant contract

Browse source 
approval-engine chose the registration-bound shape for the consuming side and
asked that the limit making it admissible be carried into the contract rather
than left in a message.

Their check is store isolation -- does this caller belong to the store this
engine serves -- not membership. A registration-supplied tenant is admissible for
that question. It is not admissible for any doctrine turning on the approver's own
membership, which is a fact about the person that this claim cannot carry, and an
exact-match check does not become that claim merely by matching.

That is GH-DEC-2026-013 section 1 reached independently from the consuming side,
and it is the practical reason tenant_source exists: a consumer whose check means
store isolation can accept registration, one whose check means membership must
require directory. Recorded next to the provenance table so the two are read
together.

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-10 13:44:02 +02:00
parent 324b5e056d
commit f9812ab3b2
1 changed files with 23 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/tenant-claim-contract.md
View file

@ -202,6 +202,29 @@ from that is the consumer's call — gate-house explicitly did **not** rule on
whether approval-engine's exact-match admission is the right gate. Carrying
provenance makes that question answerable; it does not answer it.
**What approval-engine's check actually asks, in their words.** Asked which
resolution they wanted, approval-engine chose the registration-bound shape and
stated the limit that makes it admissible for them, which they asked to be
carried here so it cannot be over-read later:
> Their tenant comparison is **store isolation**. It answers *does this caller
> belong to the store this engine serves*, not *is this human a member of the
> platform zone*. For that question a registration-supplied tenant is admissible:
> admission means arriving through a channel the platform registered, and the
> approver client is static and deployment-owned.
>
> **A registration-supplied tenant is not admissible for any doctrine that turns
> on the approver's own membership.** "An approver must be a member of the
> platform zone" is a fact about the person, and this claim cannot carry it. No
> such doctrine exists today. If one is issued, it needs a directory-sourced
> claim — and an exact-match check does not become that claim merely by matching.
That is the same conclusion as GH-DEC-2026-013 §1 reached independently from the
consuming side, and it is the practical reason `tenant_source` exists: a consumer
whose check means *store isolation* can accept `registration`, and a consumer
whose check means *membership* must require `directory`. The claim does not know
which question is being asked; the consumer does.
`tenant_source` is advertised in `claims_supported`, and
`TestIssuedTokensCarryTenantProvenance` asserts it reaches issued tokens on both
grants, including the unasserted-default case.