mesh: a grant is spent only by its issuer, at the steward it names, and its spend survives a restart #301

Merged

dcharlot merged 1 commit from feat/mesh-caller-auth-durable-spend into main 2026-10-18 00:42:18 -04:00

Conversation 0 Commits 1 Files changed 12 +757 -104

dcharlot commented 2026-10-17 11:07:18 -04:00

Owner

Copy link

Stacked on #294 and #300. Merge those first; this branch contains both exact commits, so it merges cleanly after them. Its own change is the last commit, mesh: a grant is spent only by its issuer….

What was left open after #294

Mesh decided a grant with JCP's runtime but honoured it as a bearer token: whoever presented it was taken to be its subject. The steward's spend lived in memory. So:

• anyone who obtained a grant could spend it and receive the output;
• the same grant spent its full budget again at every steward it was shown to;
• a restart gave every grant its budget back.

Caller authentication (SPEC §2.1)

A grant is presented as a Presentation:

• the delegation chain, root first, leaf last
• a caller
• a nonce
• an Ed25519 signature over the request id, the leaf's id, the caller and the nonce

The steward refuses a presentation:

• whose caller is not the leaf's issuer;
• whose signature is not for the request being served;
• that it has already spent (keyed by leaf + nonce), so a captured presentation cannot be replayed.

The steward holds the grant (SPEC §2.1)

The steward decides the chain as its holder, under the identity of its sealing key, so the leaf's subject must be this steward. A grant shown to another steward is refused NotThisSteward.

One budget over several stewards is sharded with jcp_grant::shard (JCP §4.5): one shard held by each steward, summing to no more than the parent, so the total stays bounded without coordination. Chains are decided with authorize_chained / charge_chained from #300, which check and debit every link.

Durable spend (SPEC §2.2, JCP §4.11)

The steward keeps a decision journal:

• Before the engine runs, each decision is recorded as an Authorised entry. A decision that cannot be recorded is refused.
• After the debit, a Debited entry is recorded.
• On restart, Mesh::with_journal replays the journal through the gate: each authorisation is verified and decided again at its recorded time, and each debit is applied to its serve.
• Inconsistent journals fail with JournalInconsistent: a replay the gate refuses, a debit with no authorisation, or a presentation spent twice.
• In-flight serves (authorised, never debited) stay debited at their request's ceiling, are listed in unresolved() with the caller and the backend that held them, and are never retried.
• FileJournal is append-only JSON lines, synced per append. A torn final line is dropped and cut from the file.

API

Mesh::serve and mesh-openai's complete_chat / complete_responses now take Option<&Presentation>. The demo and the falcon binary present their grants. The HTTP server presents none, as before. SPEC §2, §2.1, §2.2, §7 and §8 and the README describe all of it.

Checked

On the build host:

• mesh-rs: 73 tests pass, eight of them new. They cover a grant held elsewhere, a wrong or misdirected caller, replay, shards across two stewards, restart resumption, an in-flight serve, a forged journal, and a torn file line.
• Vectors: every regenerated mesh/1 vector is byte-identical.
• Builds: the lockfile is current (--locked), the gguf and openai server features build, and the demo runs.
• Clippy: clean on mesh-core and mesh-openai.
• Mutations: each fails tests:
  • no caller check
  • no replay check
  • deciding as the grant's subject (bearer)
  • replay dropping debits
  • an in-flight serve not debited
  • replay trusting the journal

Not covered

• Money ceilings on chains: chained decisions take no money cost, so budget_funds is not enforced on the chained path. Mesh charges no money, so it is unaffected.
• Journal truncation: a journal is only as durable as its storage. A truncated journal (entries removed from the end) cannot be told apart from one that never had them.

🤖 Generated with Claude Code

> **Stacked on #294 and #300.** Merge those first; this branch contains both exact commits, so it merges cleanly after them. Its own change is the last commit, `mesh: a grant is spent only by its issuer…`. ## What was left open after #294 Mesh decided a grant with JCP's runtime but honoured it as a **bearer token**: whoever presented it was taken to be its subject. The steward's spend lived **in memory**. So: - anyone who obtained a grant could spend it and receive the output; - the same grant spent its full budget again at every steward it was shown to; - a restart gave every grant its budget back. ## Caller authentication (SPEC §2.1) A grant is presented as a `Presentation`: - the delegation chain, root first, leaf last - a caller - a nonce - an Ed25519 signature over the request id, the leaf's id, the caller and the nonce The steward refuses a presentation: - whose caller is not the leaf's issuer; - whose signature is not for the request being served; - that it has already spent (keyed by leaf + nonce), so a captured presentation cannot be replayed. ## The steward holds the grant (SPEC §2.1) The steward decides the chain **as its holder**, under the identity of its sealing key, so the leaf's subject must be this steward. A grant shown to another steward is refused `NotThisSteward`. One budget over several stewards is **sharded** with `jcp_grant::shard` (JCP §4.5): one shard held by each steward, summing to no more than the parent, so the total stays bounded without coordination. Chains are decided with `authorize_chained` / `charge_chained` from #300, which check and debit every link. ## Durable spend (SPEC §2.2, JCP §4.11) The steward keeps a decision journal: - **Before the engine runs,** each decision is recorded as an `Authorised` entry. A decision that cannot be recorded is refused. - **After the debit,** a `Debited` entry is recorded. - **On restart,** `Mesh::with_journal` replays the journal **through the gate**: each authorisation is verified and decided again at its recorded time, and each debit is applied to its serve. - **Inconsistent journals** fail with `JournalInconsistent`: a replay the gate refuses, a debit with no authorisation, or a presentation spent twice. - **In-flight serves** (authorised, never debited) stay debited at their request's ceiling, are listed in `unresolved()` with the caller and the backend that held them, and are never retried. - **`FileJournal`** is append-only JSON lines, synced per append. A torn final line is dropped and cut from the file. ## API `Mesh::serve` and mesh-openai's `complete_chat` / `complete_responses` now take `Option<&Presentation>`. The demo and the falcon binary present their grants. The HTTP server presents none, as before. SPEC §2, §2.1, §2.2, §7 and §8 and the README describe all of it. ## Checked On the build host: - **mesh-rs:** 73 tests pass, eight of them new. They cover a grant held elsewhere, a wrong or misdirected caller, replay, shards across two stewards, restart resumption, an in-flight serve, a forged journal, and a torn file line. - **Vectors:** every regenerated `mesh/1` vector is byte-identical. - **Builds:** the lockfile is current (`--locked`), the gguf and openai server features build, and the demo runs. - **Clippy:** clean on mesh-core and mesh-openai. - **Mutations:** each fails tests: - no caller check - no replay check - deciding as the grant's subject (bearer) - replay dropping debits - an in-flight serve not debited - replay trusting the journal ## Not covered - **Money ceilings on chains:** chained decisions take no money cost, so `budget_funds` is not enforced on the chained path. Mesh charges no money, so it is unaffected. - **Journal truncation:** a journal is only as durable as its storage. A truncated journal (entries removed from the end) cannot be told apart from one that never had them. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 2 commits 2026-10-17 11:07:19 -04:00

mesh: a grant is decided by JCP's runtime, so expiry, caveats, the model and spend bind ... afde4f18ec

Mesh honoured a JCP grant by checking three things: the issuer signature,
that the capability permits `infer` on the request, and that the budget
covered the request's ceiling. Nothing else was checked:
- An expired grant was served.
- No caveat was evaluated, so `NotAfter`, `NotBefore`, `PayloadIs`,
  `MaxCostUj` and `ModelIn` were ignored.
- Nothing was ever debited, so one grant paid for any number of serves.
mesh-core had no unit test of the grant path.

The steward now holds a jcp-runtime `Runtime` and decides every grant in
JCP's two-phase metered path:
- **Route.** With a grant, a backend whose model the grant's `ModelIn`
  does not permit is inadmissible, and so is one that names no model. The
  route is the cheapest permitted backend, and the candidates record why
  the others were refused (`Router::route_where`).
- **Authorise,** before any work. The frame names `infer` on the request,
  the prompt hash as payload, and the chosen backend's weights as `model`.
  Signature, expiry, revocation and every cost-independent caveat apply,
  and what the grant has left must cover the request's ceiling.
- **Debit,** after metering. The metered joules are charged whatever
  happens next. A per-call cost caveat binds here, and a breach is sealed on
  the receipt as `grant_breach`.
- **Model check.** An engine that runs other weights than the ones it named
  before serving is refused a receipt.

Engines name their weights before serving through a new
`ServingEngine::weights_digest()`, which defaults to `None`.

The refusals that existed keep their errors (`GrantInvalid`,
`Unauthorized`, `BudgetTooLow`). `BudgetTooLow` now reports what the grant
has left. SPEC §2, §6.1, §7 and §8 and the README describe the new order.
§8 states that Mesh does not authenticate the caller, honouring a grant
as a bearer token of its subject, and that spend is per steward.

Checked on the build host:
- mesh-rs: 65 tests pass, six of them new, and every regenerated `mesh/1`
  vector is byte-identical.
- The gguf and openai server features build.
- clippy is clean on the changed crates.
- Mutations: no debit, a router that ignores the filter, ignoring other
  denials, and skipping the model check each fail tests.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

jcp: a chained decision enforces caveats, and a chain cannot drop one ... f0952309c1

`decide_chained` evaluated no caveat at all: not the leaf's, not any
ancestor's. It is the decision path behind jcp-wire's endpoint (§11),
jcp-channel, jouleclaw-jcp and joule-code-jcp. Those always present a
chain, even a one-link chain for an undelegated grant. So `PayloadIs`,
`NotBefore`, `NotAfter`, `CallerIs`, `ActionIn`, `MaxCostUj` and
`ModelIn` were enforced only on the single-grant `decide`/`authorize`
path, which the conformance suite exercises.

Separately, `verify_chain` checked capability, budget, expiry and depth
at each hop, but not that a child carries its parent's caveats or no
wider money ceiling. `attenuate` refuses both when it mints. A chain
minted by hand verified anyway and conveyed the authority the caveat
withheld.

- `verify_chain` refuses a hop that drops a parent caveat
  (`caveats_narrow`) or widens or drops its money ceiling
  (`funds_narrows`). Both are denied `attenuation-violation`.
- The chained decision's checks move into `check_chained`, which now
  evaluates every link's caveats. Cost-dependent ones are evaluated when
  the cost is known.
- `authorize_chained` / `charge_chained` add the two-phase metered path
  for a chain. Authorize debits nothing and reports the least any link
  has left. Charge debits every link, so siblings share their parent as
  in `decide_chained`, and a per-call breach is reported with the joules
  still debited.
- SPEC §4.2 states both rules and the chained metered path. C7's
  conformance check covers an inherited caveat and a dropped one.

Checked on the build host:
- jcp-rs: 501 tests pass, and the conformance suite passes all checks.
- Every vector gen-vectors writes is byte-identical.
- jouleclaw-jcp, joule-code-jcp and sandbox-jcp pass their tests.
- mesh, joule-ui, joulehook and jouledesk compile.
- Mutations each fail tests: chains ignoring caveats, `verify_chain`
  allowing a dropped caveat, and a charge debiting only the leaf.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot force-pushed feat/mesh-caller-auth-durable-spend from 18a3efda3b to 736548be93 2026-10-17 11:48:10 -04:00 Compare

dcharlot referenced this pull request from a commit 2026-10-17 11:57:19 -04:00

mesh: a cut journal is caught by the receipts the steward handed out, and the receipt chain survives a restart

dcharlot referenced this pull request 2026-10-17 11:57:22 -04:00

mesh: a cut journal is caught by the receipts the steward handed out, and the receipt chain survives a restart #306

dcharlot force-pushed feat/mesh-caller-auth-durable-spend from 736548be93 to f79fffd9fa 2026-10-17 17:14:49 -04:00 Compare

dcharlot referenced this pull request from a commit 2026-10-17 17:14:50 -04:00

mesh: a cut journal is caught by the receipts the steward handed out, and the receipt chain survives a restart

dcharlot merged commit d1bd2d2ac8 into main 2026-10-18 00:42:18 -04:00

dcharlot referenced this pull request from a commit 2026-10-18 00:42:20 -04:00

Merge pull request 'mesh: a grant is spent only by its issuer, at the steward it names, and its spend survives a restart' (#301) from feat/mesh-caller-auth-durable-spend into main

dcharlot referenced this pull request from a commit 2026-10-18 02:21:12 -04:00

mesh: a grant rides over the OpenAI-compatible HTTP binding, and a receipt can be shown back as a witness

dcharlot referenced this pull request 2026-10-18 02:21:14 -04:00

mesh: a grant rides over the OpenAI-compatible HTTP binding, and a receipt can be shown back as a witness #312

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!301

No description provided.