[Extension Proposal]: A202 commercial extension: delegated authority, negotiation state, and conformance for agent-led B2B transactions

## Abstract

This proposes an experimental A2A extension for the commercial layer of agent-led transactions between independent organisations: typed delegated authority (which principal permitted which agent to commit to what, under which constraints, with which approval), a two-level transaction and per-counterparty session state machine (which signed event moves which state), disclosure rules for competitive multi-supplier negotiation, and an executable conformance suite that turns each of those into a check an implementation passes or fails.

The extension is the A2A carrier binding of A202, an open specification (Apache-2.0, `v0.1.0` tagged) at https://github.com/a202-protocol/a202. The binding is already published and in use with an independent URI:

- Extension URI: `https://schemas.a202.org/a2a-ext/commercial/0.1`
- Binding specification: https://a202.org/bindings/a2a-binding-v0.1/ (source: [bindings/a2a-binding-v0.1.md](https://github.com/a202-protocol/a202/blob/main/bindings/a2a-binding-v0.1.md))

The proposal is to bring that binding into the experimental tier under `a2aproject` as `experimental-ext-a202-commercial` (or a name the sponsor prefers), per the [Extension and Protocol Binding Governance](https://a2a-protocol.org/latest/topics/extension-and-binding-governance/) process.

## Motivation

A2A defines how agents discover each other, exchange messages and parts, and run tasks to completion. AP2 defines, over A2A, how a payment is authorised and settled. Between them sits the part of a commercial transaction that neither addresses and that B2B deployments (procurement, freight, sourcing events, supplier negotiation) hit first:

1. **Authority to commit.** A signed message proves key possession. It does not prove that the signing agent was permitted, by an identifiable principal of an identifiable organisation, to make this offer at this amount to this counterparty, nor that a delegation chain from that principal to this agent narrowed rather than widened at every step. AP2 mandates cover the consumer payment case (a user authorising a purchase); the B2B case is delegated organisational authority with typed constraints, per-axis delegation narrowing, approval bound to the exact action, and revocation that reaches the relying party.
2. **Commercial state distinct from task state.** A2A task lifecycle is a carrier concept. A failed or cancelled task retracts no offer and terminates no agreement; a completed task completes nothing commercially. Without a stated rule, implementations either let network conditions retract commitments or treat task completion as agreement. The binding states the rule (section 6) and the state machine states which signed event moves which commercial state.
3. **Concurrent multi-supplier negotiation.** A buyer negotiating with several suppliers at once needs per-counterparty sessions with independent sequences, so that no supplier observes activity, or a sequence conflict, caused by a rival; an award that is a transition distinct from acceptance so that only one can happen; and rules that freeze at a named event so bids cannot be re-scored under changed rules.
4. **Verifiability after the fact.** A counterparty, auditor, or arbiter must be able to reconstruct what was authorised, offered, agreed, and disclosed by replaying signed records and recomputing hashes, without privileged access to any operator.
5. **Conformance.** Schema validity is necessary and not sufficient. Every invariant above that JSON Schema cannot express is a fixture with a declared reason code, so "conformant" is a suite result rather than a claim.

Several open proposals in this repository address adjacent authorisation concerns (#2133, #2079, #2098, #1829, #1786, and the question in #1769). This proposal is deliberately not another signing or authorisation envelope. It is the commercial semantics that ride on whichever of those the ecosystem settles on: an A202 mandate names an authority chain and an approval; how the underlying key is attested is left to the identity layer.

## Technical approach

Everything below is published; links go to the specification text.

**Binding (this extension).** [bindings/a2a-binding-v0.1.md](https://github.com/a202-protocol/a202/blob/main/bindings/a2a-binding-v0.1.md)

- Declared as one entry in `AgentCard.capabilities.extensions` with the URI above; `params` carries a version declaration (read versions, write version). Activated per request via `A2A-Extensions`; an absent echo is non-activation (sections 2, 4).
- A party may mark the extension `required`; the capability check runs at negotiation, before the first commercial act, and fails closed with a single refusal code on any of absent, unparseable, unsupported, or incompatible (section 3).
- One A202 object per message part. The canonical bytes (RFC 8785, SHA-256) are the object. Signatures cover the object and never the framing; carrier metadata stays outside the signed bytes (section 5).
- Many tasks may serve one transaction. Task state does not determine transaction state. Correlation is by `transaction_id` in the payload, never by task or context identifier (section 6).
- A plain HTTPS binding for a counterparty that does not run A2A, in the same document, so a first-contact supplier can participate without agent infrastructure (section 7).

**Objects the extension carries.**

- [Canonical commercial model v0.1](https://a202.org/schemas/canonical-commercial-model-v0.1/): common envelope, canonicalisation and signature rules, object inventory, money and quantity, event stream rules, and the invariants schema validation cannot express.
- [Commercial mandate v0.1](https://a202.org/authority/commercial-mandate-v0.1/): delegated authority with a closed, typed constraint vocabulary evaluated deterministically (unregistered constraint type denies at runtime and fails schema, tested separately); delegation that narrows on every axis; approval bound to the hash of the exact action; custody rules for operator-held keys; suspension and revocation through a status endpoint with bounded caching where unreachable status is a refusal.
- [Transaction and session state machine v0.1](https://a202.org/negotiation/pilot-transaction-state-machine-v0.1/): aggregate and bilateral session streams, guarded transitions, per-stream optimistic concurrency, replay, error codes; and auction event semantics: authority on every bid, award distinct from acceptance, rule freezing, isolation with a stated verification approach.
- Evidence and dispute objects for post-hoc reconstruction, and a conformance grade object.

**Conformance.** [conformance/](https://github.com/a202-protocol/a202/tree/main/conformance): manifest, 148 fixtures (32 positive, 116 negative, each negative tied to the reason code it must be refused for), and a normative runner. Includes fixtures for the extension declaration itself (valid declaration; missing extension entry; version mismatch), so the binding is tested rather than described. Runs in CI on every change.

**Reference implementation.** [reference/](https://github.com/a202-protocol/a202/tree/main/reference): a Python package (`a202_reference`) implementing canonicalisation, schema validation with fail-closed profile resolution, object emission, ES256 signatures, the evidence verification procedure, and the extension declaration handling for this binding; plus an MCP server (`a202_mcp`) exposing the bilateral role scope (issue mandate, check authority, approve, agree, exchange obligations, verify, read record). Both are covered by CI. A production-quality implementation is a stated graduation criterion and is not claimed for these.

**Design principles the binding inherits** (from the [charter](https://github.com/a202-protocol/a202/blob/main/CHARTER.md)): fail closed; explicit typed state; assurance is reported, never inferred; disclosure minimalism; deterministic verification; carrier neutrality. The last is why the binding is small: it defines how objects travel, not what they mean.

## What is asked

- Community review of the binding, in particular section 6 (task and transaction correlation) and section 5.4 (which carrier metadata may sit outside the signed bytes).
- A maintainer willing to sponsor the extension into the experimental tier. On acceptance the binding text moves to the experimental repository under Apache-2.0 with the contribution grant the governance document requires; the object specifications it references remain in the A202 repository, carrier-neutral, so that the same objects can be carried by other transports.

Related discussions where this seam has come up: #1737 (who verifies both agents had authority to commit), #1714 (cross-org first-contact accountability), #1832 (procurement profile), #1725 (agreement layer).

I maintain A202 and will maintain the extension.