Mandate Lifecycle Extensions for Agentic Payment Credentials

E-1 · §7 — the nullifier domain separator. Correction, with a residual stated. Published here 21 October 2026; carried in the reference implementation since 12 September 2026.

Published text (§7): “Nullifier derivation is domain-separated over issuer, mandate family, version, patch sequence, checkout, rail, and purpose, and verifiers resolve Merkle roots, epoch heads, and configuration from the authoritative context rather than accepting them as prover-supplied inputs.”

Correction: the nullifier is domain-separated over issuer, mandate family, version, patch sequence, checkout, and purpose. rail is removed from the nullifier domain.

Reason: the consume authority of §5.3 keys exactly-once consumption on the nullifier. A rail-scoped derivation yields distinct nullifiers for the same patch presented on different rails, so one human-signed patch could be consumed once per rail, defeating the cross-rail guarantee §5.3 exists to give. rail remains, correctly, in the §6.2 response-transcript domain separator, where it prevents cross-rail transplantation of signed step-up responses. The reference circuit's domain-input nullifier derivation takes the domain vector as inputs; instantiations use the rail-independent vocabulary above.

What remains open: removing rail from the nullifier closes the double derivation; it does not bind the patch to a rail at signing. The MandatePatch structure of §4.2 carries no rail member, so the rail is bound only through the §6.2 transcript separator, whose inputs the artefact itself does not carry, and §5.3 assigns the consume authority the nullifier check without saying that it checks the §6.2 separation. That residual is stated here because §8 of the specification promises that nothing is claimed fixed that is only mitigated.

Implemented: schemas/supersession-record.schema.json, description of voided_patch_nullifiers, merged in pull request #3 at commit 6297a8a, 12 September 2026.

E-2 · §4.3 — a per-attempt distinguisher in the canonical commitment. Correction. Published here 21 October 2026; carried in the reference implementation since release v0.1.2, 28 August 2026.

Published text (§4.3): “… seller identity, line items with SKU and variant identifiers, quantities, unit and total amounts, currency, tax, shipping, fulfillment source, recurrence terms, and post-authorization substitution policy.”

Correction: the field list ends “… recurrence terms, post-authorization substitution policy, and a per-attempt distinguisher — a value unique to each checkout attempt (for example a 128-bit random nonce).” In §6.2, the per-checkout distinguisher displayed in the challenge is the same value committed in §4.3.

Reason: without it, two byte-identical carts produce identical commitments, defeating duplicate detection and leaving §6.1's voiding of superseded authorisations unenforceable against re-presentation of a stale attempt.

Implemented: schemas/canonical-commitment.schema.json, attempt_nonce required, pattern ^[A-Za-z0-9_-]{22,}$; profile v1 uses 16 random bytes, base64url without padding. The vector commitment-attempt-nonce-distinguishes is byte-identical to commitment-canonical-order in every other field, so a matching digest between the two means the erratum has been reverted. The parity digest moved from 563962e9… to b9b75ff3… with this change; the CHANGELOG records the supersession.

E-3 · §3.1 and §4.3 — what the semantic score is computed over, and what the challenge may display. Correction, on one sentence that two defects share. Published here 21 October 2026. Nothing to implement: the reference implementation does not implement a scorer.

The defect: §3.1 requires the evaluator to compute E₁ “over the canonical authorization transaction commitment defined in Section 4.3 — the same serialization whose hash binds the checkout,” and §4.3 says that serialization is “the sole input to Section 3 scoring.” “Over” admits two readings — over the serialized byte string, or over the fields of the commitment object — and two conforming implementations could score the same cart differently. E-2 makes the difference load-bearing: with a random value inside the commitment, the string reading scores two attempts at an identical cart differently. The same §4.3 sentence also calls the serialization “the sole permissible display source for Section 6 challenges,” which is contradicted by §6.1 and §6.2: the challenge is required to display the divergence record, the proposed MandatePatch tuple set, the mandate's own signed instruction text and the patch sequence number, none of which is in §4.3's schema.

Published text (§4.3, closing sentence): “This same serialization is the sole input to Section 3 scoring and the sole permissible display source for Section 6 challenges.”

Correction, §3.1, fifth residual, added after “never over agent-relayed prose”: “E₁ is computed over the commitment's semantic fields as a structured object — seller identity, line items with their SKU and variant identifiers, quantities, unit and total amounts, currency, tax, shipping, fulfillment source, recurrence terms, and post-authorization substitution policy — not over the serialized byte string. Fields that exist to identify, order or distinguish the attempt rather than to describe the purchase — the binding-profile identifier, the checkout identifier, the time the commitment was fixed, and the per-attempt distinguisher of Section 4.3 — enter the commitment's hash and are excluded from the scoring input, so that two attempts at an identical cart yield identical scores under a pinned stack. Excluding the time the commitment was fixed from the semantic distance does not remove time from the gate: freshness is a predicate, not a dimension of the distance, and is evaluated where the predicates are — in the Section 4.2 de novo evaluation, which reads the commitment's own fields, and in the Section 5.2 epoch-freshness check at the consume authority and in the proof relation — not by the Section 3 scorer.”

Correction, §4.3, closing sentence replaced: “This same commitment is the sole source of the Section 3 scoring input, under the field projection Section 3.1 defines, and the sole permissible source for the transaction terms displayed in Section 6 challenges; the further objects Section 6 requires displayed — the divergence record, the proposed MandatePatch tuple set, the mandate's own signed instruction text, and the patch sequence number — are permitted non-transaction adjuncts.”

Reading of §6.2 under this entry: §6.2's closing clause, “the displayed object and the signed object derive from one canonical commitment,” governs the signed transaction terms; the adjuncts are displayed beside them and are not signed as terms.

E-4 · §5.1 and §5.2 — the Δ tolerance and the voiding of unconsumed patches. Open. Recorded here 21 October 2026; a resolution will be published as a further entry.

Published text (§5.2): “for amendments, activity within Δ against the prior version is tolerated by design.”

Published text (§5.1, fourth residual): “supersession voids unconsumed patches against superseded versions, with the deployment required to disclose its nullifier-to-epoch update ordering and the resulting atomicity window, if any.”

The conflict: for an unconsumed patch against a version superseded less than Δ ago, the first sentence tolerates it and the second voids it. Two conforming implementations will disagree about whether a human's signed authorisation is spendable. The resolution is a design decision and is not proposed here.

E-5 · §4.4 — the pending lock and settlement-time budget accounting. Recorded here as open 21 October 2026; one of two candidate resolutions to be adopted in a further entry. Resolved by E-6 below, 21 October 2026.

Published text (§4.4): the base mandate is locked against new authorisation requests “while any patch is pending — the pending state beginning at challenge issuance and ending at patch consumption, challenge expiry, or decline”; and “cumulative budgets count settled patch-derived spend.”

The conflict: the lock lifts at consumption and the cumulative budget learns at settlement. Sibling transactions authorised in the interval between them evaluate against an under-counted budget, which is the bypass §4.4 names. Two candidate resolutions, either a prose change: count authorised-but-unsettled spend against the cumulative budget, or hold the lock until settlement.

E-6 · §4.4 — resolution of E-5: the cumulative budget counts from authorisation. Correction, published here 21 October 2026. Candidate A of E-5 taken; nothing to implement.

Published text (§4.4): “cumulative budgets count settled patch-derived spend.”

Correction: “cumulative budgets count patch-derived spend from authorisation, where an authorised amount is replaced by the settled amount when settlement is reported, released to the extent reversed when the authorisation is reversed, and released on expiry only against a time-out the governing profile publishes; where no profile publishes one, the amount remains counted.”

The three cases are one rule about observation. The consume authority counts what it linearises itself — the authorisation — and what the rail reports to it — settlement and reversal — and applies a profile-published time-out to what it would otherwise never hear about. §4.4 already presumes the settlement channel, since “count settled patch-derived spend” cannot work without it, so this correction adds no channel; it changes which observed events the budget counts. A consume authority that released an amount on an expiry it never observed would have invented the time-out, which is the same rule the definitions apply to a reported expired.

A late report cannot be lost. Because settlement replaces rather than releases, a settlement reported after a profile time-out has released an amount re-enters the count at the settled figure. No interval counts both figures, and the time-out cannot lose a settlement.

Why the other candidate was not taken. The alternative was to hold the pending lock until settlement. That would redefine the pending state §4.4 enumerates — “beginning at challenge issuance and ending at patch consumption, challenge expiry, or decline” — rather than correct a sentence, and it would place the base mandate's availability on a clearing cycle the deployment does not control.

Implemented: nothing. The reference implementation does not enforce cumulative budgets; the README leaves that at the consume authority. Text only, as with E-3.