Retain verified tenant provenance and reconcile production blockers

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1046e-fdbf-7b93-a267-5f72b9b24526
This commit is contained in:
tegwick 2026-10-04 11:26:32 +02:00
parent 931e0b3249
commit c9ad5c2dd7
12 changed files with 274 additions and 25 deletions

View file

@ -28,9 +28,12 @@ Consequences this engine accepts deliberately:
platform zone" is a fact about the person, and this claim cannot carry it.
No such doctrine exists today; if `gate-house` issues one, it needs a
directory-sourced claim and this check does not become that claim by matching.
- When key-cape emits provenance alongside the tenant, this engine records it on
the approver entry the way schema v4 records `principal_type` — an evidence
reader should not have to infer provenance from a string that cannot carry it.
- Schema v6 records verified `tenant_source` on approver entries and issuance/use
threshold evidence. KeyCape publishes `directory`, `registration`, or `default`.
An absent claim remains null; an explicit malformed or unknown value is refused.
Legacy entries remain null, never inferred from their subject or tenant.
Provenance does not change store isolation or establish zone membership.
The deployed schema-v5 image does not yet record this field.
| Route | Required scope |
|---|---|
@ -44,8 +47,8 @@ Consequences this engine accepts deliberately:
| explicit heartbeat | `approval:emit` |
Create additionally requires `binding.actor == sub`. Approval-entry subject,
assurance, evidence reference, and **principal type** are derived from the
verified JWT, never the request body.
assurance, evidence reference, **principal type**, and **tenant source** derive
from the verified JWT, never the request body.
`principal_type` is recorded from verified identity (since schema v4). Schema v5
implements GH-DEC-2026-016: when an approval declares `human_control: true`,