Draft 0.4 proposal: Listing Terms and Agent Grants

Status: adopted for v0.2 on 27 October 2026 (#21); superseded by Draft 0.4, which is the normative text. Where this proposal and the draft differ, the draft wins. This proposal keeps the reasoning. · Proposed 20 October 2026 · Replaces Draft 0.3 section 4 (Seller Mandate) if adopted · Resolves A-1 to A-14 in ../AMBIGUITIES.md · Revised 21 October: section 13 aligns the proposal with UCP and AP2 and overrides earlier sections where they differ · Incorporated into the Draft 0.4 editor's draft, which is the text to review; this proposal keeps the reasoning

Section numbers in brackets, such as [4.1], refer to Draft 0.3. Key words follow BCP 14 and apply to the proposed text only.

#Summary

• Two objects replace the Seller Mandate. An Agent Grant says which agent may act for which seller and with which verbs. Listing Terms say what the seller will accept for one item.
• The seller sets terms once per item, when they ask their agent to list it. The platform holds the terms privately and enforces them on every call. No agent, buyer or seller, ever receives the floor.
• Buyers get a deterministic answer. Below the floor: refused, with the seller's counter if they set one. At or above: delivered to the seller agent, which negotiates.
• Terms adapt per category through term sets: a floor everywhere, plus deposits, inspections or delivery windows where the category needs them.
• The grant is local to the platform. It is an OAuth 2.0 grant bound to the agent's key, not a verifiable credential. Revocation takes effect on the next call, with no status list. Portable credentials remain for facts that travel: identity [5] and items [6].
• All fourteen v0.1 ambiguities close. Five disappear with the mandate, nine get a firm rule (section 9).
• Minimum core on UCP and AP2 (section 13). RCTP reuses every verb and noun UCP or AP2 already defines, and keeps five things of its own: offers, Listing Terms, the decision, signed proof of who did what, and portable credentials.

#1. Why change

Peer review found the mandate confusing, and the v0.1 build shows why. The mandate is signed once, at connect time, but it keys price_floor by listing ID [4.1]. A listing the agent creates later has no floor: buyer offers on it bypass the agent and reach the seller as ordinary marketplace offers, and the agent's own counters and accepts are refused not_in_scope (A-7). The v0.1 seller-agent sample lists an item and then cannot negotiate on it. The only fix in Draft 0.3 is a fresh consent on the issuer's page for every new listing, after the seller has already approved the listing itself.

The mandate also bundles three things with different lifecycles:

Three questions put to the editors on 18 October settled the direction:

1. Will a seller's permission ever be enforced by a party other than the platform that issued it? Not likely. A verifiable credential buys nothing here; a platform-local grant is enough.
2. May the seller agent accept within the terms without asking the seller each time? Maybe. It stays a per-seller choice, with ask as the default.
3. Is a floor enough, or do terms also need an auto-accept price? A floor is enough, but terms must vary by category.

This narrows repository decision 4 (multi-issuer) in ../README.md: it keeps applying to portable credentials [5, 6], and no longer to the seller's permission for an agent.

#2. The model

sequenceDiagram
    autonumber
    actor S as Seller
    participant SA as Seller agent
    participant P as Platform (enforcement point)
    participant BA as Buyer agent
    S->>P: Connect agent once (consent page)
    P-->>SA: Agent Grant, bound to the agent's key
    S->>SA: "List my camera"
    SA->>P: listing.create (item, list price)
    P-->>SA: 202 ask
    S->>P: Hosted page: confirm item, set terms (floor 300), passkey
    P-->>SA: Listing live (terms stay with the platform)
    BA->>P: offer.create 250
    P-->>BA: 403 below_floor, counter 340
    BA->>P: offer.create 320
    P-->>SA: Offer delivered
    SA->>P: offer.counter 335
    P-->>BA: Counter 335
    BA->>P: offer.create 335
    SA->>P: offer.accept
    P-->>BA: Single-use checkout

The seller touches the system twice: once to connect the agent, once per item to approve the listing with its terms. Draft 0.3 already makes listing.create an ask in every category [15.2], so the second touch adds no step.

#3. Agent Grant (replaces [4])

#3.1 What it is

An Agent Grant is the seller's permission for one agent to act for them on one marketplace. It is a record held by the marketplace, issued through OAuth 2.0, and presented as an access token bound to the agent's key. It carries no prices and no listings.

#3.2 Issuance

1. The marketplace's authorization server MUST issue a grant only after the seller confirms it on a Trusted Surface that names the agent, its operator, every verb with its tier, and the expiry, in plain language.
2. Issuance uses the authorization code flow with PKCE (RFC 7636) and RFC 9396 authorization details of type dev.rctp.agent_grant carrying verbs and tiers.
3. The consent screen MUST NOT ask for prices. Prices belong to Listing Terms (section 4).

#3.3 Use on every call

1. The agent sends the grant's access token in Authorization: Bearer <token>. The token format is the marketplace's choice: opaque, or a JWT access token (RFC 9068).
2. The token MUST be sender-constrained with cnf.jkt (RFC 7800). The enforcement point MUST check that the RFC 9421 keyid equals cnf.jkt and that the request signature covers authorization. No separate DPoP proof is needed: every request is already signed with the bound key.
3. The enforcement point MUST look the grant up on every call and refuse a grant that is unknown, revoked, expired or bound to another key (section 7).

#3.4 Revocation

1. The seller can revoke a grant at any time in the marketplace app. Operators can revoke their own tokens (RFC 7009).
2. A revoked or expired grant MUST fail the next signed call (INV-7). Because the enforcement point reads the grant's live status, no status list and no cache lifetime are involved.

#3.5 Where each mandate claim goes

#4. Listing Terms (new)

#4.1 What they are

Listing Terms are the seller's private negotiating envelope for one listing. The seller sets them once, on a Trusted Surface, when they approve the listing their agent proposed. The platform stores them, enforces them on every call, and never discloses the private ones to any agent or counterparty.

#4.2 Setting terms

1. The seller agent calls listing.create with the item and its public list price. It sends no terms.
2. listing.create is always ask (section 5.3). The 202 response carries the approval request [9.4]; its display text names the item and list price only.
3. The hosted approval page shows the listing and a terms form built from the category's term set (section 4.3). The seller fills in the terms and approves with their passkey.
4. The approval challenge MUST bind the listing hash and terms_commitment (section 4.5). The platform MUST store exactly the terms the seller signed.
5. The listing goes live. The seller agent learns the outcome, the term set ID and terms_commitment, never the values.

Listings a seller creates by hand in the marketplace app follow the same rule: the app shows the same terms form.

#4.3 Term sets per category

A term set defines which terms a category takes, their types and limits, and which check enforces each one. Term sets live in a new registry, term-sets, and are versioned (goods.small/1). A listing records the term set version it was approved under.

Every term set MUST include floor. Everything else is per category.

Each term carries constraints from a closed set, so every platform checks them the same way:

A sketch of one entry:

{
  "id": "goods.small/1",
  "categories": ["mobile-phones", "cameras", "consoles", "small-electronics"],
  "terms": [
    { "name": "floor", "type": "money", "visibility": "private", "required": true,
      "constraints": { "lte_list_price": true, "min_ratio_of_list_price": 0.2 } },
    { "name": "counter", "type": "money", "visibility": "private", "required": false,
      "constraints": { "gt_term": "floor", "lte_list_price": true } },
    { "name": "protected_payment_only", "type": "boolean", "visibility": "public", "default": true },
    { "name": "deliver_within_days", "type": "integer", "visibility": "public", "default": 7,
      "constraints": { "min": 1, "max": 30 } }
  ]
}

Rules:

1. A platform MUST advertise the term sets it enforces, with versions, in its UCP profile under dev.rctp.terms.
2. A platform MUST refuse terms that break a constraint, with 422 terms_invalid, before the seller can approve them.
3. A term named x-… is an extension. It MUST NOT change a decision unless the platform advertises it.
4. Adding a term set, or a term to a new version of a set, needs no change to the protocol.

#4.4 Changing terms

1. listing.set_terms changes a listing's terms. Its only allowed tier is ask: the seller sets the new values on the hosted page, as in section 4.2.
2. listing.reprice changes the public list price. A new price below the floor MUST be refused with below_floor.
3. Offers already open are re-evaluated against the new terms the next time any party acts on them.

#4.5 Keeping private terms private

1. Private terms MUST NOT appear in listing data, offers, decisions, approval request bodies, webhooks, logs a partner can read, or attestation entries (INV-1).
2. Attestation entries record terms_commitment instead: SHA-256 over the RFC 8785 canonical JSON of {salt, terms}, where salt is 128 random bits kept by the platform. A bare hash of a small number can be reversed by trying every price; the salt prevents that.
3. The platform discloses terms only to the seller, in the marketplace app, and to an arbiter in a dispute the seller is party to.

#4.6 Listings without terms

A listing with no approved terms is not open to agent negotiation. Offers on it reach the seller as ordinary marketplace offers, outside RCTP. A seller agent acting on it is refused not_in_scope.

#5. Decisions (replaces the check order in [9])

#5.1 Check order

Buyer calls skip step 2: the buyer's permission comes from its own AP2 mandate [9.3].

#5.2 Offers

A buyer who agrees to a seller's counter sends offer.create at that amount. Acceptance always runs offer.accept on the seller side, so an auto counter can never bypass an ask on accept.

#5.3 Verbs and tiers

The registry gives each verb a default tier and the tiers a seller may choose. A grant may only pick from the allowed set.

Category defaults for later verbs (handover.book_slot, deal.accept_deposit, passport.disclose_full_report) carry over from [15.2] unchanged.

#5.4 Offer budget

1. The platform MUST count below-floor offers per buyer agent per listing, and MUST also apply a ceiling per buyer operator per listing of N times the per-agent budget. The platform publishes both numbers in discovery.
2. Past either limit, every offer from that agent, or from that operator, on that listing gets 429 offer_budget_exhausted until the window frees a slot. Above-floor offers are included, so 201-versus-429 cannot reveal the floor.
3. An operator that rotates agent keys to dodge the per-agent budget still meets the operator ceiling, and breaches its partner terms [8].

#6. Starter checkpoints and refunds (amends [7.3] and [16.2])

The Starter set becomes funds_held, accepted, rejected, return_received, released, refunded.

1. released requires funds_held and then accepted.
2. rejected carries a reason: not_as_described or not_received.
3. After rejected with not_as_described, refunded requires return_received, written by the seller or a custodian.
4. not_received is allowed only once deliver_within_days (from the term set) has passed since funds_held. After it, refunded needs no return.
5. Any other order fails with 409 release_condition_unmet.
6. In Starter, not_received rests on the buyer's word. Categories where that is too weak use the verified custody lane [6.4], where a courier signs delivered.

#7. Reason codes (amends [12])

All other Draft 0.3 reasons are unchanged.

#8. Invariants

INV-1 moves from a promise about what the platform says to a property of who knows what: the seller agent cannot leak a floor it never received.

#9. Resolution of the v0.1 ambiguities

Dissolved means the question no longer exists under this proposal. Resolved means the proposal states the answer as a rule.

#10. Conformance

#11. Impact on the reference implementation

Net effect: less code. The credential, status-list and per-call mandate paths go; a terms store and one form come in.

#12. Open questions for review

1. Agent-suggested terms. May the seller agent propose a floor that pre-fills the form? It helps sellers price, but the agent would then know the suggested value, and sellers may anchor on it. Proposed: not in Draft 0.4.
2. Default tier for offer.accept. ask is proposed. Is auto within terms a sensible default for low-value categories?
3. First term sets. goods.small/1 and vehicles/1 are proposed for Draft 0.4; property later.
4. Grant lifetime. At most 90 days with refresh is proposed. Should the platform also expire grants after a period of no use?
5. Disclosure to the seller's own agent. Should a seller be able to opt in to their agent seeing the floor? Proposed: no. Negotiating blind costs the agent little, and it removes the leak path.

#13. Revision: minimum core on UCP and AP2

Principle: simplicity is the ultimate complexity. RCTP defines the minimum a marketplace must implement and run. Categories and logistics chains extend it through open values, not new protocol. Where UCP or AP2 already defines a verb or noun, RCTP reuses it. Checked against UCP at commit f2626c2 (20 October 2026) and AP2 v0.2.

#13.1 Reused, not redefined

#13.2 RCTP's core

Nothing in UCP or AP2 covers these:

1. Offers. dev.rctp.offer, a UCP checkout extension: create, counter, accept, decline. UCP has no negotiation; discussion #502 is open and invites vendor-namespaced prototypes. RCTP's offer is one.
2. Listing Terms (section 4).
3. The decision: auto, ask or forbid, with one registered reason.
4. Signed proof. UCP order events are asserted by the business alone. RCTP attests who did what (first_hand by the carrier, holder or buyer agent; relayed by the marketplace) and which proofs release money.
5. Portable credentials: party bands, identity facts, item passport [5, 6]. UCP and AP2 do not describe the person or the item.

#13.3 Fixed rules

Only these are fixed. Everything else is an open value named by reverse domain, as in UCP.

1. The platform enforces the seller's terms, not the agent.
2. No answer means no.
3. Private terms never reach any agent.
4. Money moves only on signed proof.
5. Facts about people, never identities.
6. No custom cryptography.

#13.4 Review decisions

#13.5 Changes to this proposal

• Deal Terms. An offer carries a price plus a fulfillment option (UCP Fulfillment) and a payment term (UCP Payment Terms) chosen from those the listing allows. The platform enforces the choice like the floor. The checkout binds all of it.
• Listing end date. Every term set gains available_until.
• Operator record, key directory, RCTP-Operator: replaced by the UCP profile and UCP-Agent.
• Agent Grant (section 3): a UCP Identity Linking grant with RCTP scopes; section 3.3 binding unchanged.
• Webhooks: UCP signed webhooks replace the RCTP format.
• Checkpoints (section 6): shipping, delivery, returns and refunds are UCP fulfillment events and adjustments, attested by RCTP. RCTP keeps only funds_held, accepted, rejected and released. A refund after not_as_described needs an attested, completed return adjustment.
• UCP version is pinned in the binding.
• Sections 3, 6, 7, 10 and 11 are rewritten to match once the review adopts this section.

#13.6 Open for review

1. Draft 0.3 [9.2(4)] forbids refusing a buyer for having no trading history when the deal uses the verified custody lane. A fixed rule (13.3) or a recommended default?
2. RCTP scope names, for example dev.rctp.listing:create, dev.rctp.offer:counter, dev.rctp.offer:accept.
3. The UCP version to pin.
4. When to propose dev.rctp.offer to UCP discussion #502: after this review, or after v0.2 ships.

Source: spec/proposals/draft-0.4-listing-terms-and-agent-grants.md