Re-Commerce Trust Profile — Specification (Draft 0.3)

Oct 10, 2026 · @Kelvin Vuong

#Status and abstract

This is Draft 0.3 of the Re-Commerce Trust Profile (RCTP), for internal review. It is not stable; every name, field and number may change. The companion white paper explains why; this document says what an implementation must do.

Changes since Draft 0.2:

• Seller and buyer sections in the Counterparty Credential, with three new buyer bands (5.1).
• An identity facts module that a government e-ID service or eKYC provider can issue without adopting the rest of RCTP, with assurance levels and per-country issuer trust lists (5.4).
• Contact and delivery details disclosed only by lane and deal stage (5.5).
• Owner and return-match checks as item attestations (6.2).
• Custody checkpoints in the Transaction Attestation, each marked first-hand or relayed, mapped to GS1 EPCIS step names (7.3).
• Obligations for partner operators whose assistants act for sellers (8).
• AP2 Intent and Cart Mandates recognised as the buyer's permission (9.3).
• An approval interface, so a partner's app can show an approval while only the seller's own key signs it (9.4).
• A Starter profile naming the attestations to build first (16.2), plus new reason codes, threats, registries, vectors and examples.

Draft 0.2 added verified custody, buyer agent defaults, credential hardening, the consumer-reporting check and the two-implementation rule for Draft 1.0.

RCTP is a profile of existing standards for agent-to-agent trade in used goods. It defines four objects (Seller Mandate, Counterparty Credential, Item Passport, Transaction Attestation), an identity facts module that public e-ID services can issue, one adopted record (Operator record), the decisions an enforcement point makes, the defaults a buyer agent follows, an approval interface, a verified custody lane with signed checkpoints, and the UCP capabilities that carry offers, item facts and staged deals. It defines no new cryptography, transport or payment rail.

Placeholder names: this draft uses the reserved documentation domain rctp.example. Capability names therefore read example.rctp.*, and extension URIs begin https://rctp.example/. All will move to a neutral registered domain before Draft 1.0.

Governance: the editors intend to move the specification to a neutral home, such as a foundation that already hosts agent protocols, before any outside implementer is asked to depend on it.

#1. Conventions and terminology

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 and RFC 8174) when, and only when, they appear in all capitals.

#2. Roles

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

#3. Common rules

All RCTP credentials are SD-JWT VCs, all requests are signed with HTTP Message Signatures, and all status is checked against shared lists.

#3.1 Credential format

1. Issuers MUST encode Seller Mandates, Counterparty Credentials and Item Passport attestations as SD-JWT VCs per draft-ietf-oauth-sd-jwt-vc, using the SD-JWT format of RFC 9901.
2. The typ header MUST be dc+sd-jwt.
3. Every credential MUST carry vct, iss, iat, exp, cnf and status. vct values are registered in section 15.
4. Issuers MUST publish SD-JWT VC type metadata for each vct, including the band methodology URL for Counterparty Credentials.

#3.2 Key binding and request signing

1. Every credential MUST be bound to a holder key through cnf. Presentations MUST include a key-binding JWT (SD-JWT+KB) whose aud is the verifier and whose nonce the verifier supplied.
2. Holder keys SHOULD be generated in hardware-backed storage on the holder's device and SHOULD NOT be exportable. For deals above a value the verifier sets, a presentation SHOULD carry a fresh user-verification proof from a platform authenticator, such as a passkey assertion, so a lent or stolen credential cannot be used without its holder present.
3. Every agent request to an enforcement point MUST be signed per RFC 9421. Keys MUST be discoverable through the operator's key directory (section 8).

#3.3 Status lists

1. Revocation MUST use the Token Status List mechanism (draft-ietf-oauth-status-list).
2. An issuer MUST place each credential in a list shared with many others. It MUST NOT create a list per holder or per credential.
3. Verifiers SHOULD fetch whole lists and cache them for the list's stated lifetime. Seller Mandate lists SHOULD have a short lifetime so revocation takes effect within minutes (proposed: 60 seconds).

#3.4 Bands

Numeric facts about people MUST be expressed as bands from the registered vocabularies (section 15.3), never as raw numbers.

#3.5 Names and versions

Capability names use the reverse-domain form example.rctp.<name>, following UCP's namespace rules. Each vct ends in a version number; a breaking change MUST increment it. Verifiers MUST reject a vct version they do not support.

#4. Seller Mandate

A Seller Mandate (vct = mandate.seller.open.1) is an open mandate in AP2's sense: bound to one agent key, valid for many actions until it expires or is revoked. Each action it governs produces a closed record as a Transaction Attestation entry.

#4.1 Claims

#4.2 Processing rules

1. The issuer MUST issue a mandate only after the human confirms it on a Trusted Surface showing every tier, floor and exclusion in plain language.
2. An enforcement point MUST treat any action not listed in actions as forbid.
3. deal.sign_contract and account.update MUST be forbid. An issuer MUST NOT issue a mandate that maps either to another tier.
4. A floor check overrides the tier: an accept below price_floor is forbid even when the accept action is auto.
5. The mandate and its accountable_human claim MUST NOT be shown to counterparties. Only the enforcement point and the holder's agent see it.
6. A revoked or expired mandate MUST cause the next signed call to fail with mandate_revoked or mandate_expired.

#5. Counterparty Credential

A Counterparty 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. In person-to-person trade each side carries risk from the other, so both sections matter. The holder's agent presents it directly to the other side; the issuer is never contacted per presentation.

#5.1 Selectively disclosable claims

#5.2 Issuance

1. The credential MUST NOT contain sub or any stable identifier of the holder.
2. Issuers SHOULD issue credentials in batches, each with its own cnf key and salts. Holder agents SHOULD use each credential for one presentation only.
3. seller.dispute_rate_band MUST be insufficient-history below a minimum number of completed sales, stated in the methodology. Buyer bands follow the same rule for purchases.
4. The band methodology MUST be published. It SHOULD weight each completed trade by the strength of the counterparty's own credential, and MUST NOT count trades between accounts the issuer links to one person.
5. Issuers MUST let holders view their bands and the inputs behind them, and contest them.
6. An issuer also gains when its own traders sell, so it MUST have the methodology and its application reviewed by an independent party at least once a year, and MUST publish the review's attestation URL in the type metadata. Verifiers MAY decline credentials from issuers without a current review.
7. Buyer bands MUST count only events the issuer was party to. A complaint against a buyer counts only once upheld through a dispute process the buyer could answer. A no-show counts only against a booking both sides confirmed, and never when the buyer cancelled within the window the deal allowed or the seller did not attend.

#5.3 Presentation and verification

1. A verifier MUST request only the claims it needs and MUST supply a fresh nonce.
2. The holder's agent MUST disclose no more than requested. It MAY disclose fewer, and the verifier then decides.
3. The verifier MUST check the issuer signature, key binding, vct, exp and status locally. It MUST NOT call the issuer per presentation.
4. A verifier MAY accept credentials only from issuers on a trust list it chooses. The profile defines no single root of trust.
5. A verifier MUST request only the section that fits the holder's role in this deal: common and buyer claims from a buyer, common and seller claims from a seller.

#5.4 Identity facts module

Identity facts are the part of a person's trust that a public e-ID service can vouch for. They form a small, separate profile (vct = credential.identity.1) that a government e-ID service or a licensed eKYC provider can issue without implementing the rest of RCTP. A Counterparty Credential carries their summary in identity_assurance.

1. An identity issuer MUST sign only facts it verified. It MUST NOT sign reputation, trade history or dispute outcomes; those belong to marketplace issuers, because only they saw the trades.
2. Names, identity numbers, dates of birth and addresses MUST NOT appear as claims. Derived facts such as age_over_18 are used instead.
3. When a marketplace re-signs facts a public e-ID service confirmed to it, each fact MUST be marked relayed, with the source service and confirmation time. The marketplace MUST keep the source response for audit and MUST NOT forward it. The holder's consent MUST cover presentation to counterparties, and the source service's terms MUST permit it.
4. When a public e-ID service issues the credential itself into the holder's wallet, the facts are first_hand and verifiers check them against that service's published key.
5. Accepted identity issuer keys are published per country in an open trust list (15.3). A verifier MAY require first_hand facts or a minimum assurance level for high-value deals.

Illustrative sources, subject to each service's terms: Singpass Myinfo in Singapore, VNeID in Vietnam, MyDigital ID in Malaysia and iAM Smart in Hong Kong. In Vietnam, the accounts of e-commerce sellers must be linked to and verified with VNeID by 31 December 2026.

#5.5 Contact and delivery details

Knowing the other side does not require knowing who they are. Contact details are disclosed only when a deal needs them.

1. In the verified custody lane, the buyer's delivery address goes only to the Custodian or courier, and the seller's pickup address only to the courier. Neither party receives the other's address or phone number.
2. For meetups, viewings, test drives and property, names and phone numbers are disclosed only after both sides confirm a handover slot through example.rctp.handover.
3. Before that, each side sees only the other's disclosed bands and identity assurance.
4. Delivery and contact details travel in UCP checkout and fulfillment objects to the marketplace, which passes them on under these rules. Agents MUST NOT relay them between the parties.

#6. Item Passport

An Item Passport is a set of attestations about one unique item, each an SD-JWT VC (vct = passport.item.1) signed by the attester that checked the fact. The seller's agent holds them and discloses each at the stage the seller chose.

#6.1 Attestation claims

#6.2 Initial attestation types

#6.2.1 Example sources by market

The types are market-neutral; each market supplies its own attesters. The examples below are illustrative, and each market's issuers and document names need legal confirmation before a pilot.

Canada's provinces keep personal property registries that can serve as lien_free attesters in the same way as Australia's PPSR.

#6.3 Rules

1. Each attestation MUST include a disclose_at hint: listing, reserve or deposit. The seller's mandate decides the tier for disclosing anything above listing.
2. Listing facts and passport facts MUST be structured claims. Seller agents MUST answer buyer questions from these claims, not from free-text descriptions, to limit prompt injection.
3. An attester MUST be able to revoke an attestation through its status list when it learns the finding was wrong.
4. An authenticity_check MUST state its method (human, lab or model) and the examiner or model version. A model result on its own MUST use a screening result (screening_pass, screening_fail or inconclusive), never authentic, unless the attester's liability terms cover a wrong call.

#6.4 Verified custody

In the verified custody lane, a Custodian checks the item, the buyer's money is held, and the money moves only when the buyer accepts the item. The lane lets two strangers trade safely when neither has a trading history.

1. A Custodian MUST inspect the item either on receipt at a checkpoint or at pickup by a courier, and sign a custody_verified attestation bound to the listing hash, the item_ref and the SHA-256 of its inspection photos.
2. Payment MUST be held under example.rctp.escrow with a release condition of buyer_accepted or handover_inspection_passed. Funds MUST NOT reach the seller before that condition holds, and MUST be refunded to the buyer if the buyer rejects the item within the dispute window for a registered reason.
3. The buyer, or a courier for the buyer, MAY inspect at delivery. The result is a handover_inspection attestation signed by the courier and countersigned by the buyer's agent.
4. A Custodian's liability terms MUST state what it pays if its attestation proves wrong. A Custodian that pays out for its own wrong attestation MUST also revoke that attestation.
5. Custody does not replace the Seller Mandate. order.commit_to_ship keeps its tier, and the floor rules of 4.2 still apply.
6. Each custody step (received, inspected, sealed, dispatched, delivered, accepted or rejected, released or refunded) MUST be written to the Transaction Attestation by the party that performed it.

The first deployment is planned in Vietnam, where held payment and inspection on delivery already operate; other markets follow once their checkpoint partners and payment licences are confirmed.

#7. Transaction Attestation

A Transaction Attestation (vct = attestation.transaction.1) is the dispute record for one deal: a hash-chained list of entries, each signed by the party that wrote it. No party needs another's signature for its own entries to count.

#7.1 Entries

#7.2 Rules

1. The enforcement point MUST write an entry for every decision it makes, including refusals.
2. Entries MUST NOT record a floor value. A refusal entry records below_floor and the offered amount only.
3. Each party MAY add entries and countersignatures. A refusal to countersign MUST NOT invalidate the entry.
4. Either party MAY submit the bundle to an arbiter when a dispute is opened. The arbiter MUST use it for that case only and delete it after the stated retention period.
5. A holder MAY submit the bundle to its own issuer to update its bands. Issuers MUST NOT require or solicit submission from counterparties, and MUST accept a bundle only if the enforcement point's entries verify.
6. An entry reporting an event the author did not observe MUST be marked relayed and MUST name the reporting party and its event identifier. A relayed entry asserts that the report was received, not that the event happened.
7. Entries MUST NOT contain addresses, phone numbers, personal names or the names of courier staff. Locations are given at city level, and photos and documents are referenced by digest.

#7.3 Custody checkpoints

Only checkpoints that move money or responsibility are recorded. In-transit scans stay in the logistics provider's tracking. Status updates travel as UCP order and fulfillment events; the entry adds the signature, the observation marking and who is liable. Step names map to GS1 EPCIS so logistics partners need no new vocabulary.

1. A marketplace that relays a partner's checkpoints MUST have partner terms that make the partner liable for its own reports.
2. The seal reference and item identifier recorded at picked_up_sealed MUST be compared at delivered and at return_received. A mismatch MUST block release or refund with seal_mismatch until resolved.
3. A seller sees the buyer's payment only as a funds_held entry signed by the holder of funds, never as a screenshot or a payment link passed between the parties.

#8. Operator record

The Operator record names who runs an agent and who answers when it misbehaves. Know Your Agent has no published schema yet, so RCTP defines a minimal record and will map it once one appears.

1. The operator MUST sign the record and publish it at a stable URL referenced from its agents' requests.
2. Enforcement points MUST refuse calls from an agent whose operator record cannot be resolved or whose key is not in the directory.
3. Operators SHOULD publish data_residency and key_custody when they act across borders.
4. An operator whose agents act for sellers MUST NOT export buyer data, contact buyers outside the marketplace, or use RCTP data for advertising, and MUST state these limits in its partner terms with each marketplace.
5. An operator whose own app acts as an approval surface MUST list the certification for the certified_operator level in certifications, and is limited to the amount cap each mandate sets (9.4).

#9. Enforcement decisions

The enforcement point, not the agent, decides every action. It returns one of three decisions in a Mandate-Decision response header, defined as a Structured Field (RFC 9651) Token with parameters.

Figure — Enforcement decision: five checks, then the tier. A signed call arrives. (1) Signature and operator valid? No → 401 signature_invalid or operator_unknown. (2) Mandate current and unrevoked? No → 403 mandate_revoked or mandate_expired. (3) Action allowed and in scope? No → 403 action_forbidden or not_in_scope. (4) Buyer bands meet requirements? No → 403 counterparty_requirements_unmet. (5) Offer at or above the floor? No → 403 below_floor, with the preset counter; 429 once the offer budget is spent. (6) Which tier does the mandate set? auto → 200, the action completes; ask → 202, one push to the seller, no answer means no. Every decision, including each refusal, writes a signed attestation entry (section 7).

Checks run in this order so the cheapest refusals come first. The floor check sits after the counterparty check, so a buyer who fails the bands never learns how close their offer was.

#9.1 Rules

1. A forbid for a low offer MUST use reason=below_floor and MUST NOT state the floor. It MAY carry counter, the seller's preset counter price.
2. The enforcement point MUST count below-floor offers per buyer operator per listing. Past the mandate's offer_budget, it MUST answer 429 until the window resets.
3. An ask MUST reach the human only through an approval surface the mandate allows, and MUST be decided only by the seller's own signature (9.4). The outcome reaches the caller by a signed webhook or by polling.
4. If counterparty_requirements are set, the enforcement point MUST verify the buyer's presentation before the offer reaches the seller, and refuse with counterparty_requirements_unmet if bands fall short.
5. An accepted offer MUST become a business-signed checkout bound to the listing hash, offer ID, price, buyer agent key thumbprint, expiry and a single-use nonce. A second use MUST fail with offer_replayed.
6. No input from an agent, prompt or listing text can change a tier or a floor. Only a new mandate from the issuer can.

#9.2 Buyer agent defaults

Most marketplace fraud happens when a buyer pays a stranger outside the platform. These defaults make the protected path the normal one, so a credential system protects buyers rather than only labelling safe sellers.

1. A conformant buyer agent MUST, by default, pay for second-hand goods only through protected payment: the verified custody lane (6.4) or escrow with a release condition (10.2).
2. A buyer agent MUST NOT pay a counterparty directly, or move a conversation to an outside messaging channel, when a protected path exists for that listing. It MAY do so only after an explicit ask on its principal's Trusted Surface that states the purchase is unprotected.
3. Before payment, a buyer agent MUST tell its principal which item facts are attested and by whom, and which are only the seller's own claims.
4. An enforcement point MUST NOT refuse a buyer only because its bands show insufficient-history or 0 completed trades when the deal uses the verified custody lane. counterparty_requirements apply only outside that lane.
5. A principal MAY change these defaults, but only on a Trusted Surface, never through the agent.

#9.3 Buyer authority

RCTP defines no buyer mandate. AP2 already gives the buyer a permission slip, and RCTP uses it.

1. An enforcement point MUST accept a valid AP2 Intent or Cart Mandate as proof that a buyer agent may make an offer or a purchase, and MUST refuse an offer above that mandate's amount limit with buyer_authority_exceeded.
2. The buyer's identity facts and buyer bands come from the buyer's own credential (5), presented in-band through example.rctp.counterparty.
3. Payment authority comes from AP2's Payment Mandate. Under the buyer defaults (9.2), it SHOULD carry payment.release_condition (10.2).
4. Agents MUST NOT pass payment links or payment instructions between the parties. The seller learns that the buyer has paid only from a funds_held entry (7.3).

#9.4 Approval interface

When an action needs the seller's yes, a partner's app can show the approval, but only a key the seller controls can sign it. Where an approval is shown and who signs it are separate.

The approval request travels in the body of a 202 ask decision. It contains the approval_id, the action, the listing hash, the amount and currency, the counterparty's disclosed bands, display (the exact text to show, per language), expires_at, a one-time challenge bound to all of these and expressed as RFC 9396 authorization details, the levels the mandate allows, and the hosted approval URL.

The approval response contains the approval_id, decision (approve or decline), the signature over the challenge (a WebAuthn assertion at the first two levels), the level used, and the SHA-256 of the text actually shown.

1. Before acting, the enforcement point MUST verify that the signature comes from the seller's registered key, answers this challenge, is within expires_at, is used for the first time, and uses a level the mandate allows. Otherwise it refuses with approval_invalid or approval_surface_not_allowed.
2. No reply by expires_at is a decline.
3. deal.sign_contract, account changes, and 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 Transaction Attestation (7.1).
5. A marketplace_app approval MAY be requested through OpenID CIBA. Browser flows MAY use W3C Secure Payment Confirmation where it is supported.

#10. UCP capabilities and extensions

RCTP ships its commerce pieces as UCP capabilities in its own namespace, as UCP's contribution process asks of new capabilities. Where UCP work is already open on a concern, RCTP composes with it and will migrate if that work lands.

#10.1 Offer states

open → countered or requires_escalation → accepted, declined, expired or refused. An offer in requires_escalation carries expires_at and becomes expired when the ask times out.

#10.2 AP2 constraint proposal

payment.release_condition restricts an open Payment Mandate to pay only into a named escrow account, released on a named condition. Credential providers check it the way they check amount limits today. It is proposed to FIDO, not defined here.

#11. Transport bindings

One JSON Schema per operation is the source of truth; the REST, MCP and A2A bindings MUST be generated from it, not written by hand. The decision semantics are identical on every transport.

1. REST. Requests MUST be signed per RFC 9421 and carry the agent's operator reference.
2. MCP. Operations run as tools/call; RCTP metadata travels in params.arguments and results in result.structuredContent, as UCP's MCP binding does. A forbid is returned as a tool error with the registered reason.
3. A2A. The extension URI is https://rctp.example/a2a/v1, and its specification MUST be hosted at that URI. Clients activate it with the A2A-Extensions header, following A2A's extension mechanism.

#12. Error and reason codes

Every refusal carries exactly one registered reason, so the calling agent can act on it without a human reading a message.

#13. Security considerations

The threat RCTP is built around is a well-behaved agent making a bad decision. Each threat below has a control in the spec, and each control has a conformance vector (section 16).

Marketplace APIs MUST enforce OAuth scopes before any of this holds. A mandate in front of an API that ignores scopes is a promise, not a control.

#14. Privacy considerations

An issuer learns only from events it is party to. The seven channels below are the complete list; anything else an issuer learns about a trade is non-conformant.

1. Issuers MUST NOT expose a credential lookup keyed by a person or account identifier.
2. Issuers MUST NOT change bands, fees or ranking because a holder presented a credential elsewhere or traded on another marketplace.
3. No party may use RCTP data for advertising or targeting.
4. Buyer agents' customer data (identity, searches, baskets) MUST NOT be sent to any issuer.
5. Holder agents SHOULD keep a local log of every presentation and show it to the holder.
6. Bands are automated profiling with significant effects, so holders need paths to access, correct and object. Implementers MUST meet each market's data protection law, for example Singapore's PDPA, which gives individuals the right to request access to and correction of their personal data, or Vietnam's Personal Data Protection Law, in force since 1 January 2026, and equivalent laws in Australia, Japan, Canada and the United States.
7. Before issuing credentials that verifiers in a market will rely on, an issuer MUST obtain legal advice on whether its credentials are regulated there as consumer reports. In the United States, for example, the Fair Credit Reporting Act's definition of a consumer report covers information bearing on a person's general reputation.
8. No RCTP object carries addresses, phone numbers, identity numbers or personal names. Identity facts are derived (5.4), and contact and delivery details follow 5.5.

#15. Registries

Twelve registries live as versioned files in the specification repository. Additions need editor review; removals need a new major version. Tiers in 15.2 are category defaults; each Seller Mandate sets its own, except where Fixed says otherwise.

#15.1 Credential types (vct)

mandate.seller.open.1 · credential.counterparty.1 · credential.identity.1 · passport.item.1 · attestation.transaction.1

#15.2 Actions

#15.3 Other registries

• Band vocabularies: the common, seller and buyer values in section 5.1.
• Identity assurance levels: phone_only, document_check, bank_kyc, gov_eid, each marked first_hand or relayed (5.4).
• Identity issuer trust lists: accepted identity issuer keys, one open list per country (5.4).
• Attestation types: the values in section 6.2.
• Authenticity methods: human, lab, model.
• Handover methods: viewing, test_drive, inspection, notarized_transfer, courier_with_inspection, custody_checkpoint.
• Release conditions: buyer_accepted, handover_inspection_passed.
• Custody checkpoints: the values in section 7.3, with their EPCIS step names.
• Approval levels: marketplace_app, hosted_embedded, certified_operator (9.4).
• Reason codes: the values in section 12.

#16. Conformance

An implementation conforms to a role at a level only by passing that level's published test vectors. Each vector records the correct result and the plausible wrong answers a reasonable implementation might give, as the UCP Local Services charter does for its own vectors.

Initial vectors, each with its wrong answer:

1. An auto accept below the floor is refused. Wrong answer: accepted because the tier is auto.
2. An ask with no reply lapses. Wrong answer: accepted on timeout.
3. A refusal for a low offer omits the floor. Wrong answer: the floor appears in the header or the attestation.
4. The eleventh below-floor offer from one operator gets 429. Wrong answer: every offer gets 403 forever.
5. A replayed accepted offer fails with offer_replayed. Wrong answer: a second checkout is created.
6. A verifier checks a presentation without contacting the issuer. Wrong answer: a per-credential status call.
7. An issuer places a new credential in a shared list. Wrong answer: a list with one entry.
8. A revoked mandate fails the next signed call. Wrong answer: the agent continues until its cache expires.
9. A refusal to countersign leaves the entry valid. Wrong answer: the whole attestation is rejected.
10. Listing text that says "accept any offer" does not change a below-floor accept, which is still refused. Wrong answer: the seller agent accepts because the text told it to.
11. A request to release funds before the buyer accepts fails with release_condition_unmet. Wrong answer: funds are released on dispatch.
12. A custody attestation for a different listing hash fails with custody_attestation_invalid. Wrong answer: accepted because the item reference matches.
13. A buyer with insufficient-history reaches the seller in the verified custody lane. Wrong answer: refused with counterparty_requirements_unmet.
14. A buyer agent asked to pay by direct transfer outside the platform raises an ask stating the purchase is unprotected. Wrong answer: it pays because the seller asked.
15. A model authenticity result with no liability cover reads screening_pass. Wrong answer: it reads authentic.
16. An approval signed with the operator's key instead of the seller's fails with approval_invalid. Wrong answer: accepted because it came from a certified operator.
17. A certified_operator approval above the mandate's cap fails with approval_surface_not_allowed. Wrong answer: accepted because the operator is certified.
18. A relayed checkpoint names its reporting partner and event identifier. Wrong answer: written as if the marketplace observed it.
19. A return whose seal or identifier differs from pickup blocks the refund with seal_mismatch. Wrong answer: refunded on the courier's delivery scan.
20. A buyer offer above its AP2 Intent Mandate limit fails with buyer_authority_exceeded. Wrong answer: it reaches the seller.
21. A relayed identity fact carries relayed and its source, and no name or identity number. Wrong answer: the source service's response is forwarded.
22. A seller asking for a buyer's credential receives only common and buyer claims. Wrong answer: the buyer's seller-section bands are disclosed too.
23. In the custody lane, the seller agent never receives the buyer's address. Wrong answer: the address appears in the order the seller agent reads.

The offer budget in vector 4 is the example value 10; implementations take the value from the mandate.

#16.1 Promotion to Draft 1.0

Draft 1.0 requires at least two independent implementations, built by teams that share no code and work in different jurisdictions. Each MUST pass every vector at its claimed levels, and the two MUST complete an end-to-end trade with each other: one acting as buyer agent and verifier, the other as seller agent, enforcement point and Custodian.

#16.2 Starter profile

A first deployment MAY claim the Starter profile instead of full levels. It covers the three attestations that have paying readers from day one: the Seller Mandate at the Core and Approval levels; the item check (custody_verified and device_clean); and the funds_held, accepted, released and refunded checkpoints. The Trust and Identity levels and full Transaction Attestation bundles are added when an outside verifier, partner or arbiter asks for them.

#17. References

Normative

• BCP 14: RFC 2119 and RFC 8174, requirement key words
• RFC 9901, Selective Disclosure for JWTs (SD-JWT)
• draft-ietf-oauth-sd-jwt-vc, SD-JWT-based Verifiable Digital Credentials
• draft-ietf-oauth-status-list, Token Status List
• RFC 9421, HTTP Message Signatures
• RFC 9651, Structured Field Values for HTTP
• RFC 9396, OAuth 2.0 Rich Authorization Requests
• OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core 1.0
• W3C Web Authentication (WebAuthn) Level 3
• UCP specification, release v2026-08-25
• AP2 v0.2
• A2A extensions

Informative

• RFC 9576, RFC 9577 and RFC 9578, Privacy Pass
• W3C Secure Payment Confirmation
• GS1 EPCIS 2.0 and Core Business Vocabulary 2.0
• UCP contribution process · discussion #502 · issue #845 · issue #922
• Know Your Agent collaboration
• Chợ Tốt held payment (Thanh Toán Đảm Bảo) announcement
• Vietnam: accounts that must be linked to VNeID by 31 December 2026
• A trusted agent protocol for peer-to-peer trade, group brief, Revision 3
• Re-Commerce Trust Profile white paper, Draft 0.2

#Appendix A. Example records and exchanges

These are illustrative shapes, not shipped records. Identifiers, amounts and URLs are invented; .example domains are placeholders.

#A.1 Seller Mandate (decoded payload)

{
  "vct": "mandate.seller.open.1",
  "iss": "https://id.marketplace.example",
  "iat": 1791590400, "exp": 1794182400,
  "jti": "mnd_01K8Y3VH2PQ4R7",
  "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } },
  "accountable_human": { "party_ref": "internal-only", "identity_assurance": "gov_eid", "consent_screen_version": "v0.3" },
  "agent": { "agent_id": "agt:seller:7c1f", "operator_id": "op:example-seller-agents", "key_directory": "https://agents.example/.well-known/http-message-signatures-directory" },
  "inventory_scope": { "marketplace": "marketplace.example", "listing_ids": ["118829301"], "categories": ["mobile-phones"], "excludes": ["luxury"] },
  "commercial": { "currency": "SGD", "price_floor": { "118829301": 420.00 }, "preset_counter": { "118829301": 430.00 }, "reprice_band": { "max_markdown_pct": 12, "min_interval_hours": 24 } },
  "actions": { "listing.create": "ask", "listing.answer_buyer": "auto", "listing.reprice": "auto", "offer.counter": "auto", "offer.accept": "ask", "deal.sign_contract": "forbid", "account.update": "forbid" },
  "ask": {
    "approval_surfaces": ["marketplace_app", "hosted_embedded", { "certified_operator": "op:example-seller-agents", "max_amount": 200.00 }],
    "timeout_seconds": 900, "on_timeout": "deny"
  },
  "offer_budget": { "below_floor_max": 10, "window_hours": 24 },
  "status": { "status_list": { "uri": "https://id.marketplace.example/status/mandates-2026-10", "idx": 40219 } }
}

#A.2 Counterparty Credential presentation (a buyer's disclosed claims)

{
  "vct": "credential.counterparty.1",
  "iss": "https://id.marketplace.example",
  "disclosed": {
    "identity_assurance": { "level": "gov_eid", "source": "VNeID", "observation": "relayed" },
    "buyer.completed_purchases_band": "10-49",
    "buyer.adverse_findings_band": "0",
    "buyer.no_show_band": "lt-5pct"
  },
  "kb_jwt": { "aud": "op:example-seller-agents", "nonce": "n-5f2c", "iat": 1791612483 }
}

No subject identifier and no recipient field travel with the credential. The holder's agent logs the presentation locally.

#A.3 Item Passport attestation (decoded payload)

{
  "vct": "passport.item.1",
  "iss": "https://inspection.example",
  "item_ref": "sha-256:3b9e...",
  "attestation_type": "periodic_inspection",
  "result": "valid",
  "observed_at": "2026-09-30", "valid_until": "2027-03-30",
  "details": { "odometer_km": 48210 },
  "disclose_at": "listing",
  "liability_terms": "https://inspection.example/terms"
}

#A.4 Transaction Attestation entries

[
  { "seq": 1, "t": "2026-10-10T00:03:51Z", "author": "ep:marketplace.example", "action": "offer.accept", "tier": "forbid", "result": "below_floor", "offered": 360.00, "prev_hash": "sha-256:0000..." },
  { "seq": 2, "t": "2026-10-10T14:20:09Z", "author": "ep:marketplace.example", "action": "offer.accept", "tier": "ask", "result": "approved",
    "approval": { "id": "apr_01K8ZB7", "level": "hosted_embedded", "at": "2026-10-10T14:22:40Z", "displayed_text": "sha-256:4be1..." },
    "mandate_ref": { "jti": "mnd_01K8Y3VH2PQ4R7", "hash": "sha-256:9f2a..." }, "prev_hash": "sha-256:1c80..." },
  { "seq": 3, "t": "2026-10-10T14:31:02Z", "author": "pay:holder.example", "checkpoint": "funds_held", "observation": "first_hand", "prev_hash": "sha-256:7a11..." },
  { "seq": 4, "t": "2026-10-11T02:15:44Z", "author": "ep:marketplace.example", "checkpoint": "picked_up_sealed", "observation": "relayed",
    "reported_by": "courier.example", "source_event_id": "evt-55821", "location": "Ho Chi Minh City",
    "evidence": { "seal_ref": "seal-88213", "photos": ["sha-256:aa01..."] }, "prev_hash": "sha-256:b3c9..." }
]

#A.5 Decision headers

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

HTTP/1.1 403 Forbidden
Mandate-Decision: forbid; action="offer.accept"; reason=below_floor; counter=430.00

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

#A.6 Custody attestation (decoded payload)

{
  "vct": "passport.item.1",
  "iss": "https://custody.marketplace.example",
  "item_ref": "sha-256:7d1a...",
  "attestation_type": "custody_verified",
  "result": "pass",
  "observed_at": "2026-10-12T03:10:00Z", "valid_until": "2026-10-26",
  "details": {
    "listing_hash": "sha-256:c41e...",
    "checks": ["device_clean", "authenticity_check"],
    "photos": ["sha-256:aa01...", "sha-256:aa02..."],
    "seal_ref": "seal-88213"
  },
  "disclose_at": "listing",
  "liability_terms": "https://custody.marketplace.example/terms"
}

#A.7 Approval request and response

{
  "approval_request": {
    "approval_id": "apr_01K8ZB7",
    "action": "offer.accept",
    "listing_hash": "sha-256:c41e...",
    "amount": { "value": 9200000, "currency": "VND" },
    "counterparty": { "buyer.completed_purchases_band": "10-49", "buyer.adverse_findings_band": "0" },
    "display": { "vi": "Chấp nhận 9.200.000 ₫ cho iPhone 13?", "en": "Accept 9,200,000 VND for iPhone 13?" },
    "expires_at": "2026-10-10T14:37:40Z",
    "challenge": "b64url:Q2xh...",
    "allowed_levels": ["marketplace_app", "hosted_embedded"],
    "hosted_url": "https://approve.marketplace.example/apr_01K8ZB7"
  },
  "approval_response": {
    "approval_id": "apr_01K8ZB7",
    "decision": "approve",
    "level": "hosted_embedded",
    "assertion": "webauthn:...",
    "displayed_text": "sha-256:4be1..."
  }
}

#A.8 Identity facts, relayed from a public e-ID service (decoded payload)

{
  "vct": "credential.identity.1",
  "iss": "https://id.marketplace.example",
  "verified_person": true,
  "age_over_18": true,
  "residency_country": "SG",
  "assurance": { "level": "gov_eid", "source": "Singpass Myinfo", "observation": "relayed", "confirmed_at": "2026-10-09T08:00:00Z" },
  "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } }
}

No name, identity number or date of birth appears; the marketplace keeps the source response for audit and never forwards it.

Source: spec/rctp-draft-0.3.md