Skip to content

Promote develop to main — ADR T-057, the two signing identities - #138

Merged
beyondnetPeru merged 2 commits into
mainfrom
develop
Aug 3, 2026
Merged

Promote develop to main — ADR T-057, the two signing identities#138
beyondnetPeru merged 2 commits into
mainfrom
develop

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

Promotes the two commits on develop: ADR T-057, recording the owner's decision on GT-588 key custody.

  • Issuer key → the tenant's, in tenant configuration, alongside the gate matrix and the artifact overlay. Per-tenant keys make custody harder, and that cost is accepted because it is what makes each tenant independent.
  • Transparency Service key → the platform's. A tenant signing its own receipt could rewrite its history and re-sign it; RFC 9943 puts that authority in a separate entity, and the code already said so.
  • Neither key makes the trail immutable — the append-only audit table does. The signature adds attributable provenance, not immutability.

Registered in DECISIONS.md/.es.md, which is where the doc inventory derives its count from — an ADR file alone is invisible to it.

🤖 Generated with Claude Code

beyondnetPeru and others added 2 commits August 3, 2026 16:58
…ests it

Records the owner's decision on GT-588 key custody, adopting their proposal for
one of the two signing identities and refusing it for the other.

The proposal was that each tenant own its signing mechanism, in tenant
configuration. That is coherent with T-056 and it is adopted for the ISSUER key:
"this tenant approved this gate" is the tenant's own claim, so it is the tenant's
key, alongside the gate matrix and the artifact overlay. Per-tenant keys make
custody HARDER, not easier -- N keys to store and rotate -- and that cost is
accepted deliberately, because it is what makes each tenant independent.

It is refused for the TRANSPARENCY SERVICE key. RFC 9943 puts that authority in a
separate entity, and `MerkleTransparencyService` already carries both as distinct
fields with a comment saying why: a statement and a receipt produced with the
same key are "a self-assertion with added ceremony". A tenant signing its own
receipt could rewrite its history and re-sign it -- the signature would still
catch an accident and would stop proving anything to a third party, which is the
case the owner said matters.

Third point, written down because both mistakes are easy: NEITHER key is what
makes the trail immutable. That is the append-only audit table
(`MakeAuditEntriesAppendOnly`). The signature adds attributable provenance, not
immutability -- so unsigned-but-append-only is not untrustworthy, and
signed-but-mutable is not proof.

Today's state is stated rather than left implicit: until per-tenant issuer keys
exist, the platform signs for everyone, which is weaker than this decision.

Registered in DECISIONS.md/.es.md -- the inventory derives the count from that
registry, not from the ADR files, so an ADR that is not registered there is
invisible to it. The generated blocks were regenerated (57 decisions).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…tities

docs(adr): T-057 — the tenant signs what it asserts, the platform attests it
@beyondnetPeru
beyondnetPeru merged commit 3566154 into main Aug 3, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant