[Change] § 4.1, § 5.6.1 — Commitments must carry proposal_id and version; stale versions are rejected #24

Activity

1. Kishore-2572

   added

   change-requestProposes specific normative wordingProposes specific normative wording

   normativeChanges what the spec requiresChanges what the spec requires

   section:4-proposal

   section:5.6-commercial

   on Oct 8, 2026
2. aleksUIX commented on Oct 14, 2026

   

   aleksUIX

   on Oct 14, 2026

   More actions

   Could the version and expiry checks explicitly exclude replay of an already processed commitment?

   Section 5.6.1 currently requires a previously seen idempotency_key to return the original result. Suppose the seller accepts a commitment immediately before price_valid_until, but the response is lost. The buyer retries the identical request after that time. The existing rule requires the accepted result; the proposed expiry rule requires rejection.

   Suggested addition:

   For an authenticated replay of the same previously processed commitment attempt, the seller MUST return the original result without creating another commitment. The current-version and expiry checks apply to a new attempt, not to returning a stored result. Reusing the same idempotency key with different commitment terms MUST produce an explicit conflict and MUST NOT create or modify a commitment.

   This preserves rejection of new stale commitments while allowing a buyer to recover the outcome of a timed-out request. The same distinction applies when the current published version changes between acceptance and retry.

   This is a source-review counterexample, not a defect reproduced in an implementation.

   Commenting in a personal capacity.
3. KonstantinMirin commented on Oct 22, 2026

   

   KonstantinMirin

   on Oct 22, 2026

   Last edited by KonstantinMirin

   More actions

   Postindustria (IAB Tech Lab member) supports pinning the version a commitment is made against, and @aleksUIX's replay distinction. Two gaps remain. #24 makes every seller-set revision (§ 3) increment version, so correcting one line item rejects commitments on another. And an equal version doesn't prove equal bytes (#35). Our coming PRs close both.

   Bind content, not the counter. The buyer's commitment entry in assent[] carries version and record_digest, the digest of the binding record of the line items it names (our binding-record filing). The seller recomputes it over those line items as it stores them, plus the buyer's writes. An equal value means the buyer read the same terms, so the seller MAY accept at the entry's version. Our PR on what is signed states this test, and our lifecycle PR defines staleness the same way.

   sequenceDiagram
       Seller->>Buyer: version 4, line items A and B
       Note over Seller: seller revises, version 5
       Buyer->>Seller: commit on A at version 4, with record_digest
       Note over Seller: recompute over stored A plus the writes
       alt equal
           Seller-->>Buyer: MAY accept at version 4
       else A changed
           Seller-->>Buyer: rejected (stale_version)
       else buyer read other bytes
           Seller-->>Buyer: rejected (record_mismatch)
       end
   

   Loading

   One replay rule. #73 states it in line with the replay rule in IAB's agentic primitives (FD-12), and our PR on what is signed keeps it. A replay under the same key gets the result as it stands, without re-running the checks. A changed Commit under that key gets idempotency_conflict, a code our errors and extensions PR defines.

   Take idempotency_key and the pin out of commitment. Both describe one commit, not terms. Our PR on what is signed puts them on the buyer's assent[] entry, outside the digest.

   Details: Commitment digest and replay: full rationale and examples

   Open questions:

   1. How long does a seller keep a stored rejection? An acceptance keeps its key in assent[], but a rejection writes no entry, so the seller keeps it apart. @EvgenyAndroid suggests on #128 a floor at valid_until (offer_window.end in our PRs). Our PRs leave replay beyond § 5.6.1 to the AAMP wire and lifecycle contract (§ 1.2). Should that contract set this floor?

   Revised 2026-11-03: Rewritten against our coming PRs: the seller's own recompute replaces offer_digest, and idempotency_key moves to the assent[] entry. We withdraw the valid_until floor our #128 reply quoted, pending open question 1.

   Analyzed and generated with the help of Claude, fully reviewed by me.
4. Kishore-2572 commented on Oct 22, 2026

   

   Kishore-2572

   on Oct 22, 2026

   Author

   More actions

   Thanks @aleksUIX. As the filer, I agree that the version and expiry checks should apply to a new commitment attempt, not to replaying the stored result of one already processed. Otherwise a buyer cannot recover the outcome of a timed-out request. I will include your suggested wording in the draft PR for this change request, including the explicit conflict when the same idempotency_key is reused with different terms, for the working group to consider at adjudication.
5. Kishore-2572 commented on Oct 22, 2026

   

   Kishore-2572

   on Oct 22, 2026

   Author

   More actions

   Thank you, @KonstantinMirin. Three points in reply, as the filer:

   • Replay: agreed on one rule. The draft PR will state it once, aligned with iab-agentic-primitives FD-12 and @aleksUIX's wording: keys are opaque and scoped per buyer/seller pair; the same attempt returns the stored result without re-running the version and expiry checks; the same key with a different body is rejected as a conflict.
   • Revision on another line item: agreed that, as filed, any revision increments version and so rejects a commitment on an unchanged line item. offer_digest is one fix, but it depends on the binding record in [Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63, and per-line-item staleness ([Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65) and what counts as a new version ([Change] § 4.1 — Freeze a version's offered terms; changes create version n+1 and a revised entry #64) bear on the same question. The draft PR will list these as knock-on effects for the working group rather than adopt one here.
   • idempotency_key on the request: outside this change request's scope. The draft PR will note it as a related proposal.
6. Kishore-2572

   added 2 commits that reference this issue on Oct 22, 2026

   Scope the replay rule to the same buyer

   ...

   74a2544

   Define the replay body and tighten the stale-version checks

   ...

   0b90fd4