Re-Commerce Trust Profile (RCTP) — Draft 0.5

Editor's draft, 10 November 2026: the implementation baseline

#Abstract

RCTP is a profile of existing commerce standards that lets AI agents buy and sell second-hand goods for people. A person delegates the whole trade to their agent, with their consent. Every seller and every unique item has a profile both sides can check. The marketplace's gateway enforces the seller's limits on every call and keeps a signed record. RCTP reuses the Universal Commerce Protocol (UCP) and the Agent Payments Protocol (AP2) wherever they already define a verb or noun, and defines only five things of its own: offers, Listing Terms, the enforcement decision, signed proof of who did what, and portable credentials about people and items.

#Status of this document

This is the editor's draft of 10 November 2026. It incorporates the Draft 0.5 proposal (#91), which the editor accepted as the implementation baseline on that day: new implementations build on this draft, not on Draft 0.4. Lazy consensus under GOVERNANCE runs until 17 November 2026; anything it changes is applied here before release v0.3.0-draft.5 is tagged. It is still a draft, not a standard: names, fields and numbers may change in a later draft.

It supersedes Draft 0.4. Draft 0.5 changes no mechanism that protects a trade. It removes rules that were stricter than UCP (authentication, 4.1), moves tier policy to the marketplace (8.4), and lets a seller state Listing Terms in plain language (6). The open questions raised for this draft and their resolutions are in Appendix B. Every decision since Draft 0.3, and the history of earlier drafts, is in Appendix C.

Placeholder domains use .example. Capability and extension names use dev.rctp.*, backed by the domain rctp.dev, which the project controls.

#1. Introduction

#1.1 Scope

RCTP covers person-to-person trade in used goods where one or both sides act through an AI agent. It defines how a seller authorises an agent, how the seller's limits are set and enforced, how agents negotiate, how each step of a deal is proven, and how facts about people and items travel between platforms.

Out of scope: booking, quoting and tracking shipments; moving money; negotiation strategy and pricing; identity-proofing methods; transports. RCTP composes with the standards that cover them (1.4).

#1.2 What RCTP gives each party

The profile defines verbs, scopes and invariants, and records facts. Marketplaces and platforms set policy: which authentication mechanisms they accept (4.1) and which tiers they allow (8.4).

#1.3 Design principles

Simplicity is the ultimate complexity. RCTP defines the minimum a marketplace must implement and operate. Categories and logistics chains extend it through open values, not new protocol. Where UCP or AP2 defines a verb or noun, RCTP uses it.

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

#1.4 Relationship to UCP and AP2

Pinned to UCP release v2026-08-25 and AP2 v0.2. UCP Ask is not yet in a UCP release; RCTP follows it at UCP commit f2626c2 (20 October 2026) until it is.

#1.5 Conventions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL are to be read as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals. Numbered rules are normative; tables define fields and values; examples and notes are informative. Values in code are registered (16) unless marked as examples.

#2. Terminology

#3. Roles

RCTP names roles, never companies. One organisation MAY play several roles; each role's duties apply in full.

#4. Common rules

#4.1 Agent identity and authentication

1. Every agent request to an enforcement point MUST authenticate by a mechanism UCP allows: HTTP Message Signatures per UCP Message Signatures (RFC 9421, ES256 baseline), which are RECOMMENDED; an OAuth 2.0 access token; an API key; or mTLS. The marketplace chooses which mechanisms it accepts. The request carries UCP-Agent naming the operator's UCP profile; a signed request MUST. When a call authenticated by OAuth carries no UCP-Agent, the enforcement point MAY use the profile it registered for the OAuth client; when it carries one, the two MUST match. Either way, the enforcement point MUST confirm that the authenticated principal may act for that profile (UCP identity binding).
2. The operator's profile MUST publish its signing keys in keys[] when its agents sign, and MUST add a dev.rctp.operator entry with legal_entity, jurisdiction, incident_contact and incident_sla_hours. It MAY add certifications, data_residency and key_custody.
3. An enforcement point MUST refuse a call whose profile cannot be resolved, whose operator it has not onboarded, or whose UCP-Agent does not match the profile registered for its authenticated client, with operator_unknown.
4. An operator whose agents act for sellers MUST NOT export buyer data, contact buyers outside the marketplace, or use RCTP data for advertising.
5. An agent without a UCP profile of its own, such as a plugin on an agent host, uses the profile its developer publishes as operator. A marketplace MAY instead host a profile for each OAuth client it registers. Either way, the profile names an operator accountable under rule 2. An operator without a profile of its own accepts the duties of rules 2 and 4 in its OAuth client registration with the marketplace. The agent host that runs a plugin, such as its model provider or IDE, sees the conversation, buyer data included, and is not bound by rule 4. That is the real difference from an operator whose agents sign; a marketplace weighs it when it sets tiers for OAuth clients (8.4).
6. Every deal record entry the enforcement point writes for an agent call, decisions and refusals included, MUST carry authenticated_by, the mechanism the call used, and agent_profile, the profile the call acted for (10.1). An entry for an OAuth or API-key call MUST also carry client_id, the client that authenticated. Whether a token was key-bound follows from the mechanism (5.3).
7. What each mechanism may do is the marketplace's policy (8.4). Without a signature, the record proves which client acted for which profile, not the content of each request; a marketplace weighs that when it sets tiers. The controls for bearer tokens are short-lived access tokens, refresh-token rotation and the live grant check on every call (5.3(2)). DPoP (RFC 9449) is a possible middle step for clients that can hold a key but cannot sign every request; it waits for a pinned library (INV-8).

#4.2 Portable credentials

1. Party Credentials, identity facts, Item Passport attestations and deal records are SD-JWT VCs (RFC 9901, draft-ietf-oauth-sd-jwt-vc) with typ dc+sd-jwt, carrying vct, iss, iat, exp, cnf and status.
2. Every credential MUST be bound to a holder key through cnf. A presentation MUST include a key-binding JWT whose aud is the verifier and whose nonce the verifier supplied.
3. Holder keys SHOULD be hardware-backed and not exportable.

#4.3 Status lists

1. Credential revocation MUST use the Token Status List. Each list MUST be shared by many credentials; a list per holder or per credential is forbidden.
2. Verifiers SHOULD fetch whole lists and cache them for their stated lifetime.
3. Agent Grants do not use status lists; they are checked live (5.4).

#4.4 Bands

Numeric facts about people MUST be expressed as registered bands, never raw numbers.

#4.5 Names, versions and open values

1. Capability names use dev.rctp.<name>. Credential types end in a version number; a breaking change increments it.
2. Method types, event types, adjustment types, attestation types and term names are open values. A party MAY add a value under its own reverse domain; parties that do not recognise it MUST treat it as informative and MUST NOT let it change a decision.
3. The capability version of this draft is 2026-11-draft5. A deployment MAY keep serving 2026-11-draft4 beside it for at most 90 days after it starts serving 2026-11-draft5.

#5. Agent Grant

An Agent Grant is a UCP Identity Linking grant, issued by the marketplace, with RCTP scopes. It is bound to one agent key when the agent signs (5.3). It carries no prices and no listings.

#5.1 Grant record

#5.2 Issuance

1. The marketplace MUST issue a grant through UCP Identity Linking (OAuth 2.0 authorization code with PKCE) only after the seller confirms, on a Trusted Surface, the agent, its operator, each verb with its tier, and the expiry.

2. The marketplace's profile declares each RCTP scope (8.4), as UCP declares every scope, in the config.scopes of its dev.ucp.common.identity_linking entry, with default_tier and allowed_tiers in the scope's policy. The seller's chosen tiers travel as RFC 9396 authorization details of type dev.rctp.agent_grant.

3. The consent screen MUST NOT ask for prices. Prices belong to Listing Terms.

4. A grant MUST expire at most 90 days after it is issued; the agent renews it by refresh-token rotation. A marketplace MAY expire a grant earlier when it is unused.

#5.3 Use on every call

1. The agent sends the grant's access token in Authorization. When the request is signed, the token MUST be sender-constrained with cnf.jkt (RFC 7800), and the request signature MUST cover authorization. When it is not signed, the token is the request's OAuth credential.
2. The enforcement point MUST look the grant up on every call, whatever the authentication mechanism and bearer tokens included, and check that the grant is active and unexpired and that the verb's scope is granted. When the token is bound, it MUST also check that the signing key's thumbprint equals cnf.jkt.

#5.4 Revocation

1. The seller can revoke a grant at any time; operators can revoke their own tokens (RFC 7009).
2. A revoked or expired grant MUST fail the next call, whatever its authentication mechanism.

#6. Listing Terms

Listing Terms are the seller's negotiating envelope for one listing. The seller states them to their agent in plain language, such as "list it at 500, don't go below 400", and confirms them once on a Trusted Surface. The platform stores what the seller confirmed and enforces it on every call. Everything between the floor and the list price is the agents' to negotiate; the marketplace never sells below the floor, whatever anyone says to an agent.

#6.1 Setting terms

1. The seller agent calls listing.create with the item and its public list price. It MAY include proposed terms: the values the seller told it, the floor included.
2. Terms are confirmed on a Trusted Surface (the marketplace's hosted page or app). It shows the listing and a form built from the category's term set, pre-filled with the proposed terms and the marketplace's category defaults (6.2), all editable. The seller confirms with their passkey. This is the expected flow. A marketplace MAY ignore proposed terms and ask the seller for the floor directly; that is its policy.
3. The approval challenge MUST bind the listing hash and the terms_commitment (6.4). The platform MUST store exactly the terms the seller confirmed. Proposed terms are not terms: the enforcement point MUST NOT store or enforce them until the seller confirms them, and MUST discard them if the seller declines.
4. The seller agent learns the outcome, the term set ID and terms_commitment. The marketplace MUST NOT return the private values to any agent, including the seller agent that proposed them.
5. When the marketplace allows listing.create at auto (8.4), the listing is created without terms, and stays closed to agent negotiation until the seller confirms terms through listing.set_terms (6.5).
6. A listing a seller creates by hand in the marketplace app takes the same form.

#6.2 Term sets

A term set, such as goods.small/1, defines the terms a category takes. A listing records the term set version it was approved under. Platforms MUST advertise the term sets they enforce in the config of dev.rctp.listing in their UCP profile.

1. The minimum Listing Terms are two prices: the public list price, already on the listing, and the private floor. Every term set MUST include floor and available_until; every other term is optional.
2. required in a term set means the term has a value when the seller confirms, not that the seller types it. The marketplace fills each public term from its category defaults, available_until included, and the seller changes them only if they want to.

Constraints come from a closed set, so every platform checks them the same way: min, max, gt_term, lt_term, lte_list_price, min_ratio_of_list_price. Terms that break a constraint MUST be refused with terms_invalid before the seller can approve them. Which terms a term set includes is the marketplace's choice for that category.

#6.3 Changing terms

1. listing.set_terms changes terms. It has no tier choice: it always opens the seller's confirmation and is answered ask (8.4). It MAY carry proposed terms, which are handled as in 6.1.
2. listing.reprice changes the public price; a price below the floor MUST be refused with below_floor.
3. Open offers are re-evaluated against new terms the next time a party acts on them. Accepted offers are not (7.4).

#6.4 Keeping private terms private

1. Private terms, proposed or confirmed, MUST NOT appear in listing data, offers, decisions, approval request bodies, webhooks, partner-readable logs, deal records or any other response to an agent. They appear only on the seller's Trusted Surface.
2. Deal records carry terms_commitment: SHA-256 over the RFC 8785 canonical JSON of {salt, terms}, with a 128-bit salt kept by the platform.
3. The platform discloses private terms only to the seller, and to an arbiter in a dispute the seller is party to. No setting lets the marketplace send them to an agent.
4. A seller may tell their own agent the floor; that is the seller's choice, and it is how proposed terms work (6.1). An agent that knows the floor can still be talked into revealing it. The guarantee does not depend on the agent: no sale happens below the floor (8). A marketplace that wants the floor kept from every agent asks the seller for it directly (6.1(2)).

#6.5 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; a seller agent acting on it is refused not_in_scope.

#7. Offers and Deal Terms

#7.1 Offer capability

RCTP defines two UCP capabilities. Both are standalone, not extensions of dev.ucp.shopping.checkout.

A deal is a trade both parties agree to, not a promotion or a discount. An offer is its own resource, formed before any checkout exists; accepting one produces a UCP checkout (7.4). Payment, shipping and order events stay with UCP Checkout and Order; dev.rctp.deal adds who attests them (10). Offer operations: create, counter, accept, decline, get. An RCTP offer is not UCP's Offer extension, which is a merchant-proposed change to a cart.

#7.2 Deal Terms

1. An offer carries Deal Terms: a price, one UCP fulfillment option and one UCP payment term, each chosen from those the listing's terms allow.
2. A choice the listing does not allow MUST be refused with terms_invalid.
3. Booking, quotes, labels and tracking stay with UCP Fulfillment and the carrier.
4. Every offer and counter carries offer_id, negotiation_id and expires_at (7.3). The enforcement point assigns negotiation_id to a buyer agent's first offer on a listing; every later offer and counter between that buyer agent and that listing carries the same value. It is opaque and MUST NOT be derived from any identifier of the buyer.
5. An offer that answers a counter, or replaces the buyer agent's own open offer, MUST name it in supersedes. The enforcement point sets the named offer to superseded. A supersedes that names an offer outside the negotiation MUST be refused with terms_invalid.

#7.3 Offer states and who accepts

States: open → countered or awaiting_approval → accepted, declined, expired, superseded or refused. An offer is awaiting_approval while an ask on it waits for the seller.

1. Only the seller side accepts, under offer.accept. A counter is an invitation, not a commitment; a buyer agrees to it by offer.create at the counter's Deal Terms.
2. The party that creates an offer or counter sets its expires_at; if it is omitted, the enforcement point sets the default it publishes in the config of dev.rctp.deal. The enforcement point MUST cap expires_at at the listing's available_until and at the maximum it publishes.
3. At expires_at an offer that is not accepted becomes expired; acting on it MUST be refused with offer_expired.
4. An ask raised on an offer expires no later than the offer. When it times out, the offer becomes expired.
5. Seller counter-offers are the marketplace's option. A marketplace that does not support them leaves dev.rctp.deal:offer_counter out of its config.scopes, and agents learn that from discovery. Floor defence alone is complete: an offer below the floor is refused; at or above it, the offer goes to the seller or their agent to accept or decline.

#7.4 Acceptance, reservation and checkout binding

1. An accepted offer MUST become a business-signed checkout bound to the listing hash, offer ID, Deal Terms, buyer agent key thumbprint, expiry and a single-use nonce. A second use MUST fail with offer_replayed.
2. Accepting an offer reserves the listing for that checkout. While the reservation holds, the enforcement point MUST refuse every other offer.accept on the listing with listing_reserved, and MUST NOT create a second checkout for it. Buyer agents MAY still make offers; they stay open until they expire.
3. The reservation ends when the checkout is redeemed, which closes the listing, or when the checkout expires, which reopens the listing to offers that have not expired.
4. Once an offer is accepted, its Deal Terms are fixed. A later listing.set_terms or listing.reprice MUST NOT change them or end the checkout.
5. Only the seller, on a Trusted Surface, can withdraw a reserved listing. Redeeming its checkout then fails with not_in_scope, and the withdrawal is written to the deal record.

#7.5 Buyer authority and payment

1. An enforcement point MUST accept a valid AP2 Checkout Mandate as proof that a buyer agent may offer, and MUST refuse an offer outside its constraints with buyer_authority_exceeded.
2. The buyer's AP2 Payment Mandate SHOULD constrain the payee with payment.allowed_payees to the deal's holder of funds.
3. Agents MUST NOT pass payment links or payment instructions between the parties.

#8. Enforcement decisions

The enforcement point, not the agent, decides every action.

#8.1 Check order

An unauthenticated request is refused at step 1: signature_invalid where the marketplace requires signatures, otherwise grant_invalid for a seller verb and operator_unknown for a buyer verb. Every decision, including each refusal, appends a deal record entry (10) carrying authenticated_by and agent_profile (4.1(6)).

#8.2 Decision header

The decision travels in an RFC 9651 Structured Field: a Token (auto, ask, forbid) with parameters.

1. A refusal for a low offer MUST use below_floor and carries no private term: it MUST NOT state the floor or any value derived from it. An agent that wants a reference price reads the public list price on the listing.

2. No agent input, prompt or listing text can change a tier, a term or a grant.

3. The header is named RCTP-Decision.

#8.3 Decisions by verb

#8.4 Verbs, tiers and scopes

Every seller verb belongs to one of RCTP's two capabilities (7.1), and its scope is {capability}:{scope} as in UCP Identity Linking. A verb's prefix names its capability: listing.x is dev.rctp.listing:x, deal.x is dev.rctp.deal:x, and offer.x is dev.rctp.deal:offer_x. Fixed forbid verbs have no scope, so no grant can contain them.

1. The Default and Allowed columns are reference defaults, like the reference offer budget (8.5). A marketplace declares its own default_tier and allowed_tiers for each scope it offers, in the config.scopes of its dev.ucp.common.identity_linking entry (5.2). It MAY vary them by authentication mechanism (4.1). It leaves out a scope it does not offer.
2. The seller chooses a tier within what the marketplace allows, at consent and later.
3. Three things are fixed, because they are mechanics, not policy: listing.set_terms always opens the seller's confirmation (ask); only the seller confirms terms (INV-5), so a listing created at auto has no terms until the seller confirms them (6.1(5)); and deal.sign_contract and account.update are always forbid (INV-3).

offer.create is a buyer verb: it is checked against the terms and has no tier. Buyer verbs need nothing RCTP-specific beyond authentication (4.1): checkout and payment authority come from UCP and AP2, or another payment protocol, which carry their own proof.

#8.5 Offer budget

1. The enforcement point MUST count below-floor offers per buyer agent per listing, with a ceiling per buyer operator per listing. It publishes both numbers in the config of dev.rctp.deal.
2. Past either limit, every offer from that agent or operator on that listing gets 429 until the window frees a slot, so 201-versus-429 cannot reveal the floor.

#8.6 Buyer agent defaults

1. A buyer agent MUST, by default, pay for second-hand goods only into protected payment: the verified custody lane, or a holder of funds with a release condition.
2. A buyer agent MUST NOT pay a counterparty directly, or move a conversation to an outside channel, when a protected path exists, unless its principal approves an explicit ask stating the purchase is unprotected.
3. Before payment, a buyer agent MUST tell its principal which item facts are attested and by whom.
4. An enforcement point MUST NOT refuse a buyer only for insufficient-history or zero trades when the deal uses the verified custody lane.
5. A principal MAY change these defaults only on a Trusted Surface.

#9. Approvals

A partner's app can show an approval, but only a key the seller controls can sign it.

#9.1 Levels

#9.2 Request and response

1. The request travels in the 202 body: approval_id, action, listing hash, amount, counterparty bands, display, expires_at, a one-time challenge and the allowed levels. The challenge is SHA-256 over the RFC 8785 canonical JSON of RFC 9396 authorization details of type dev.rctp.approval.
2. display MUST NOT contain private terms. A listing approval shows the terms form, pre-filled as in 6.1, on the seller's Trusted Surface only, and its challenge binds terms_commitment.
3. The response carries approval_id, decision, the signature over the challenge (a WebAuthn assertion at the first two levels), the level, and the SHA-256 of the text shown.

#9.3 Rules

1. Before acting, the enforcement point MUST verify that the signature is the seller's registered key, answers this challenge, is within expires_at, is first used, and uses an allowed level; otherwise approval_invalid or approval_surface_not_allowed.
2. No reply by expires_at is a decline. A late response is refused approval_invalid; the approval is reported expired with approval_timeout.
3. Any amount above the certified cap MUST use marketplace_app or hosted_embedded.
4. The approval, its level and the displayed-text digest are written to the deal record.
5. The seller's approval key is their existing marketplace account passkey; how it is registered is the marketplace's concern.

#10. Deal record and proof

A deal record (vct = attestation.transaction.1) is the hash-chained list of signed entries for one deal. UCP Order events say what happened; the deal record says who attests it, and which proofs move money.

#10.1 Entries

#10.2 Events and who attests them

RCTP defines only the checkpoints UCP lacks. Shipping, delivery and money adjustments use UCP's open types.

Category events, such as picked_up_sealed or custody_inspected (11.4), are open values added by term sets.

#10.3 Money rules

1. released requires funds_held, then the deal's release condition (by default accepted).
2. After rejected with not_as_described, refund requires an attested, completed return.
3. rejected with not_received is allowed only after deliver_within_days since funds_held; a refund then needs no return.
4. Where a term set sets required_observation, the named events count only when signed with that observation.
5. Any other order fails with 409 release_condition_unmet.

#10.4 Rules

1. The enforcement point MUST write an entry for every decision, including refusals, and MUST NOT record a floor.
2. A relayed entry asserts that a named partner reported the event, not that it happened; partner terms carry the liability.
3. A refusal to countersign MUST NOT invalidate an entry.
4. Either party MAY submit the record to an arbiter in a dispute, for that case only. A holder MAY submit it to its own issuer to update its bands.
5. Entries MUST NOT contain addresses, phone numbers or names. Locations are city-level; evidence is referenced by digest.

#11. Portable credentials

Facts that should travel between platforms are SD-JWT VCs (4.2), presented by the holder's agent directly. The issuer is never contacted per presentation.

#11.1 Party Credential

vct = credential.counterparty.1 states what kind of trader a person is, as a seller and as a buyer, without saying who they are.

1. No sub or stable holder identifier. Issuers SHOULD issue in batches with fresh keys; agents SHOULD use each credential once.
2. Dispute and buyer bands MUST read insufficient-history below a published minimum.
3. The band methodology MUST be published, MUST exclude trades between linked accounts, and MUST be reviewed by an independent party yearly.
4. Holders MUST be able to view and contest their bands and inputs.
5. Buyer bands count only events the issuer was party to; complaints count only once upheld through a process the buyer could answer.
6. A verifier MUST request only the claims it needs and only the section that fits the holder's role, and MUST check signature, key binding, type and status locally.

#11.2 Identity facts

vct = credential.identity.1 carries facts a public e-ID service or licensed eKYC provider verified.

1. Names, identity numbers, dates of birth and addresses MUST NOT appear.
2. An identity issuer MUST sign only facts it verified, never reputation or trade history.
3. A marketplace that re-signs facts a public e-ID service confirmed MUST mark them relayed with source and time, keep the source response for audit, and never forward it.
4. Accepted identity issuer keys are published per country in an open trust list.

Illustrative sources, subject to each service's terms: Singpass Myinfo, VNeID, MyDigital ID, iAM Smart.

#11.3 Item Passport

Each attestation (vct = passport.item.1) is signed by the attester that checked the fact.

Registered types: registration_match, periodic_inspection, lien_free, inspection_report, title_verified, ownership_or_poa, owner_match, planning_zone, grade_certificate, custody_verified, handover_inspection, return_match, authenticity_check, device_clean.

1. Listing and passport facts MUST be structured; seller agents MUST answer from them, not from free text.
2. Attesters MUST be able to revoke an attestation through their status list.
3. An authenticity_check MUST state its method (human, lab, model) and examiner or model version. A model result alone MUST read screening_pass, screening_fail or inconclusive, never authentic, unless liability terms cover a wrong call.

#11.4 Verified custody

1. A Custodian MUST inspect the item at a checkpoint or at pickup, and sign custody_verified bound to the listing hash, item_ref and photo digests.
2. Seal and item identifier recorded at pickup MUST be compared at delivery and return; a mismatch blocks release or refund with seal_mismatch.
3. A Custodian's liability terms MUST state what it pays when its attestation is wrong, and it MUST revoke that attestation.

#11.5 Contact and delivery details

1. Delivery and contact details travel in UCP checkout and fulfillment objects to the marketplace; agents MUST NOT relay them between parties.

2. When an item ships, the buyer's address goes only to the carrier or Custodian.

3. For meetups, viewings and test drives, names and phone numbers are disclosed only after an accepted offer fixes a handover option and window.

4. Booking a viewing or test drive before a deal is out of scope for this draft; it is expected to use UCP Local Services once that exists.

#12. Transport bindings

One JSON Schema per operation is the source of truth; REST, MCP and A2A bindings follow UCP's bindings and are generated from it. Decision semantics are identical on every transport. On MCP, a marketplace exposes RCTP verbs as tools on UCP's MCP transport, unchanged; the tool result carries the decision, and a forbid is a JSON-RPC error -32000 with the registered reason in error.data.code. The binding names the tools.

#13. Reason codes

Every refusal carries exactly one registered reason.

#14. Security considerations

Marketplace APIs MUST honour grant scopes. A grant in front of an API that ignores scopes is a promise, not a control.

#15. Privacy considerations

An issuer learns only from events it is party to.

1. No credential lookup keyed by a person or account identifier.
2. No change to bands, fees or ranking because a holder traded elsewhere.
3. No RCTP data for advertising or targeting.
4. The platform discloses private terms only to the seller (6.4).
5. No RCTP object carries addresses, phone numbers, identity numbers or names.
6. Bands are automated profiling: holders need access, correction and objection under each market's data protection law, and issuers need legal advice on whether credentials are consumer reports.

#16. Registries

Registries are versioned files in the specification repository. Additions need editor review; removals need a new major version. Open values (4.5) need no registration.

#17. Conformance

#17.1 Levels

An implementation conforms to a role at a level only by passing that level's vectors. Each vector records the correct result and the plausible wrong answer.

#17.2 Invariants

#17.3 Test vectors

Vectors that assert a tier read the marketplace's published default_tier and allowed_tiers (8.4), not the reference table. Vectors that exercise offer.counter (the counter steps of V11, V28 and V29) run only where the marketplace offers dev.rctp.deal:offer_counter.

#17.4 Starter profile

A first deployment MAY claim the Starter profile: Core with goods.small/1; Approval at hosted_embedded; Proof with funds_held, accepted, rejected, released and UCP return and refund. Trust, Identity, Item and Custody are added when a verifier, partner or arbiter asks for them. A Starter deployment MAY offer floor defence only, without offer.counter (7.3(5)), and MAY accept any authentication mechanism UCP allows (4.1).

#17.5 Promotion to Draft 1.0

Draft 1.0 requires two independent implementations, built by teams that share no code, in different jurisdictions. Each passes every vector at its claimed levels, and the two complete an end-to-end trade with each other.

#18. References

Normative

• BCP 14: RFC 2119 and RFC 8174
• RFC 6749 and RFC 7636 (OAuth 2.0, PKCE); RFC 6750 (bearer tokens); RFC 8705 (mTLS); RFC 7009 (token revocation); RFC 7800 (proof-of-possession key semantics); RFC 9396 (Rich Authorization Requests)
• RFC 7638 (JWK thumbprint); RFC 8785 (JSON canonicalization)
• RFC 9421 (HTTP Message Signatures); RFC 9530 (Digest fields); RFC 9651 (Structured Field Values)
• RFC 9901 (SD-JWT); draft-ietf-oauth-sd-jwt-vc; draft-ietf-oauth-status-list
• W3C Web Authentication Level 3
• UCP specification: Signatures, Identity Linking, Ask, Checkout, Fulfillment, Payment Terms, Order, and the MCP transport. Release v2026-08-25; Ask at commit f2626c2 until released.
• AP2 v0.2: Checkout Mandate, Payment Mandate

Informative

• UCP discussion #502: buyer agents negotiating
• UCP issue #922: Local Services council
• RFC 9576–9578 (Privacy Pass); W3C Secure Payment Confirmation; OpenID CIBA; GS1 EPCIS 2.0
• Draft 0.5 proposal; Draft 0.4 proposal; Trusted Agents for Second-Hand Trade; White paper, Draft 0.2

#Appendix A. Examples

Illustrative only. Identifiers, amounts and URLs are invented.

#A.1 Agent Grant (introspection view, held by the marketplace)

{
  "grant_id": "grt_01KA3M7Q",
  "seller": "pp:7f2c",
  "operator": "https://agents.example/.well-known/ucp",
  "agent_id": "agt:seller:7c1f",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "scopes": ["dev.rctp.listing:create", "dev.rctp.listing:answer_buyer", "dev.rctp.deal:offer_counter", "dev.rctp.deal:offer_accept"],
  "tiers": { "dev.rctp.deal:offer_accept": "ask" },
  "iat": 1792540800, "exp": 1800316800, "status": "active"
}

#A.2 Listing Terms (stored by the platform; never sent to an agent)

{
  "listing_id": "lst_camera_x100",
  "term_set": "goods.small/1",
  "terms": {
    "floor": { "value": 300, "currency": "SGD" },
    "available_until": "2026-11-21T00:00:00Z",
    "fulfillment_options": ["shipping", "meetup"],
    "release_condition": "buyer_accepted",
    "deliver_within_days": 7
  },
  "terms_commitment": "sha-256:5b1e..."
}

#A.3 Offer with Deal Terms

{
  "offer_id": "ofr_01KB2R9T",
  "negotiation_id": "neg_01KB2Q4M",
  "supersedes": "ofr_01KB2Q8C",
  "expires_at": "2026-10-29T12:00:00Z",
  "listing_id": "lst_camera_x100",
  "price": { "value": 335, "currency": "SGD" },
  "fulfillment": { "method_type": "shipping", "selected_option_id": "std" },
  "payment": { "selected_term_id": "pay_now_held" }
}

#A.4 Decisions

HTTP/1.1 403 Forbidden
RCTP-Decision: forbid;action="offer.create";reason=below_floor

HTTP/1.1 202 Accepted
RCTP-Decision: ask;approval_id="apr_01K8ZB7";expires_in=900;on_timeout=deny

HTTP/1.1 429 Too Many Requests
RCTP-Decision: forbid;reason=offer_budget_exhausted;retry_after=3600

#A.5 Deal record entries

[
  { "seq": 1, "author": "ep:marketplace.example", "action": "offer.create", "tier": "forbid", "result": "below_floor", "offered": 250, "authenticated_by": "http_signature", "agent_profile": "https://buyer-agents.example/.well-known/ucp" },
  { "seq": 2, "author": "ep:marketplace.example", "action": "offer.accept", "tier": "auto", "result": "accepted", "terms_commitment": "sha-256:5b1e...", "authenticated_by": "oauth", "agent_profile": "https://agents.example/.well-known/ucp" },
  { "seq": 3, "author": "pay:holder.example", "event": "funds_held", "observation": "first_hand" },
  { "seq": 4, "author": "carrier.example", "event": "shipped", "observation": "first_hand", "evidence": { "tracking_ref": "sha-256:9a0c..." } },
  { "seq": 5, "author": "ep:marketplace.example", "event": "delivered", "observation": "relayed", "reported_by": "carrier.example", "source_event_id": "evt-55821", "location": "Singapore" },
  { "seq": 6, "author": "pp:buyer-3d1a", "event": "accepted" },
  { "seq": 7, "author": "pay:holder.example", "event": "released", "observation": "first_hand" }
]

#A.6 Party Credential presentation (a buyer's disclosed claims)

{
  "vct": "credential.counterparty.1",
  "disclosed": {
    "identity_assurance": { "level": "gov_eid", "source": "VNeID", "observation": "relayed" },
    "buyer.completed_purchases_band": "10-49",
    "buyer.adverse_findings_band": "0"
  },
  "kb_jwt": { "aud": "ep:marketplace.example", "nonce": "n-5f2c" }
}

#A.7 Proposed terms (the seller said "list at 400, not below 300")

{
  "title": "Camera X100, boxed",
  "category": "cameras",
  "condition": "like_new",
  "price": { "value": 400, "currency": "SGD" },
  "term_set": "goods.small/1",
  "proposed_terms": { "floor": { "value": 300, "currency": "SGD" } }
}

The marketplace answers ask (or creates the listing at auto, without terms) and shows the seller a form pre-filled with the floor and its category defaults. The agent learns terms_commitment once the seller confirms, never the value.

#Appendix B. Resolved open issues

#B.1 Draft 0.5

Raised in the Draft 0.5 proposal and decided by the editor on 10 November 2026, subject to lazy consensus until 17 November 2026.

#B.2 Draft 0.4

Raised and resolved in #21; every resolution is decision D-31. OI-1, OI-2 and OI-5 are superseded in Draft 0.5 by D-36, D-35 and D-36.

#Appendix C. Decisions and changes

#C.1 Decision log

Every decision was adopted by the editors; D-20 to D-31 were confirmed in #21.

#C.2 Resolved ambiguities from v0.1

#C.3 Change history

Source: spec/rctp-draft-0.5.md