From f9812ab3b2bfe8f0817185f44071e612264ec3ee Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 10 Sep 2026 13:44:02 +0200 Subject: [PATCH] Carry approval-engine's store-isolation limit into the tenant contract 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 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 --- docs/tenant-claim-contract.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/docs/tenant-claim-contract.md b/docs/tenant-claim-contract.md index 0c917c7..1c013e0 100644 --- a/docs/tenant-claim-contract.md +++ b/docs/tenant-claim-contract.md @@ -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.