[Kishore-2572]

Draft. Do not merge until the working group confirms the disposition of #24.

What this changes

A commitment now names the proposal and version it was priced against (proposal_id, version, § 5.6.1). The seller rejects a new commitment attempt on a stale version, past valid_until, or past the price_valid_until of the pricing[] entry it is priced against, and returns the current version so the buyer can fetch it again. These checks depend only on the stored proposal and the time the seller receives the attempt. A replay of an attempt already processed (same idempotency_key, same body) returns the stored result, acceptance or rejection, without re-running those checks, and the same key with a different body is an explicit conflict, as @aleksUIX suggested on #24. idempotency_key values are opaque and scoped to one buyer and seller pair, in line with iab-agentic-primitives FD-12. § 4.1 states that each revision of the proposal increments version.

Related issue

Refs #24. #23 (draft PR #70) relies on these version rules for "same proposal and version".

Type

• Editorial — no normative effect
• Normative — changes what the spec requires
• Breaking — would break an implementation already built to this draft
• Examples / schema / docs only

Checklist

• The body section is updated
• Appendix A (field index) matches the body — no new rows, as the new keys sit inside commitment; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — counts unchanged
• Any affected example in examples/ is updated and still parses — the display, CTV and audio commitments carry proposal_id and version; § 6.3 points to the CTV example
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — no new selectable or settable fields
• No confidential or commercially sensitive content

Knock-on effects

• Breaking: a commitment without proposal_id and version is rejected.
• Revision on another line item: as written, any revision increments version, so a revision to one line item rejects a commitment on an unchanged one (Postindustria on [Change] § 4.1, § 5.6.1 — Commitments must carry proposal_id and version; stale versions are rejected #24). Not resolved here, for the working group:
  • commitment.offer_digest, which depends on the binding record in [Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63;
  • per-line-item staleness ([Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65);
  • which changes create a new version ([Change] § 4.1 — Freeze a version's offered terms; changes create version n+1 and a revised entry #64).
• Not included, for the working group:
  • how long a seller keeps idempotency_key values (Postindustria suggests at least until valid_until);
  • moving idempotency_key from commitment to the request (Postindustria on [Change] § 4.1, § 5.6.1 — Commitments must carry proposal_id and version; stale versions are rejected #24);
  • the related proposals that a commitment is an offer until the seller accepts it ([Change] § 3, § 5.6.1, Appendix B — A resolved commitment is an offer until the seller accepts #67), whose status gates the freeze ([Change] § 3, § 2.2, § 5.6.1 — Name whose status gates seller-set revisions #60), and proposal_id on every line item ([Change] § 2, § 4.1, § 5.1 — Name the line-item container (line_items[]) and carry proposal_id and seller_id on every line item representation #31).
• Authentication: @aleksUIX's wording said "an authenticated replay". The specification does not define authentication yet (WS1; see [Change] § 5.8 — required_credentials[].scheme is an eligibility credential, not agent authentication #62), so the rule applies to a replay from the same buyer.
• Review changes (Postindustria on this PR): the replay rule matches on the body (every value the buyer sent except idempotency_key); a retry against a new version uses a new key; version increments on every revision, including a counter while under_review, leaving which changes count as a revision to [Change] § 4.1 — Freeze a version's offered terms; changes create version n+1 and a revised entry #64; "deterministic" is defined; the price check names the pricing[] entry the commitment is priced against.
• Not included, for the working group: how a commitment identifies that pricing[] entry ([Change] § 5.6 — Give cost_method an extensible vocabulary, and say what several pricing[] entries mean #94 proposes commitment.pricing_id).
• Examples: the commitments use version: 1, matching examples/proposal.yaml.

---

By opening this pull request I agree my contribution may be published under this
repository's licence, as set out in CONTRIBUTING.md.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Kishore-2572, thanks for folding in @aleksUIX's replay wording. Four points:

• "Same commitment terms" has no definition. Your reply on #24 and the replay rule in IAB's agentic primitives (FD-12) compare the body. Suggested: "the same body: every value the buyer sent with the attempt except idempotency_key". A rejection is stored too, so a retry on a new version needs a new key.
• version row. "While status is published" leaves out a seller counter during under_review, so a buyer could commit at an unchanged number to changed terms. "Each revision increments it" covers that and leaves what counts as a revision to #64.
• "As for idempotency_key" points to nothing: no idempotency text says "deterministic". Suggested: "These checks depend only on the stored proposal and the time the seller receives the attempt."
• pricing[].price_valid_until names no entry. Suggested: "the committed pricing[] entry's price_valid_until". #94 names that entry with commitment.pricing_id.

Analyzed and generated with the help of Claude, fully reviewed by me.

[Kishore-2572]

Thank you, @KonstantinMirin. All four are in the latest commit: the replay rule now matches on the body (every value except idempotency_key) and replays a stored rejection too, so a retry on a new version uses a new key; version increments on each revision, leaving what counts as one to #64; the checks are defined as depending only on the stored proposal and the receive time; and the price check names the pricing[] entry the commitment is priced against. How a commitment identifies that entry is left to #94, listed under knock-on effects.

[KonstantinMirin]

Thank you, @Kishore-2572. Postindustria (IAB Tech Lab member) checked 0b90fd4, and all four points are in. They are the replay body and stored rejection, the version row, "deterministic" defined, and the pricing[] entry named. As in #63's binding record, the body leaves out idempotency_key.

Analyzed and generated with the help of Claude, fully reviewed by me.

[Kishore-2572]

Thanks for checking, @KonstantinMirin.