Re-Commerce Trust Profile (RCTP) — Draft 0.4

Adopted for v0.2, 27 October 2026

#Abstract

RCTP is a profile of existing commerce standards that lets AI agents buy and sell second-hand goods for people. The seller sets the rules once, the marketplace enforces them on every agent call, and every deal leaves signed proof. 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 draft was adopted for v0.2 on 27 October 2026 after editor review (#21). It is still a draft, not a standard: names, fields and numbers may change in a later draft. It supersedes Draft 0.3 and incorporates the Draft 0.4 proposal. The open issues raised during review and their resolutions are listed 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.*.

#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.3).

#1.2 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.3 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.4 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 request signing

1. Every agent request to an enforcement point MUST be signed per UCP Message Signatures (RFC 9421, ES256 baseline) and carry UCP-Agent naming the operator's UCP profile.
2. The operator's profile MUST publish its signing keys in keys[], 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 or whose operator it has not onboarded, 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.

#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-draft4. A deployment MAY keep serving 2026-10-draft3 beside it for at most 90 days after it starts serving 2026-11-draft4.

#5. Agent Grant

An Agent Grant is a UCP Identity Linking grant, issued by the marketplace, with RCTP scopes, bound to one agent key. 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. The token MUST be sender-constrained with cnf.jkt (RFC 7800), and the request signature MUST cover authorization.
2. The enforcement point MUST look the grant up on every call and check that the signing key's thumbprint equals cnf.jkt, that the grant is active and unexpired, and that the verb's scope is granted.

#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 signed call.

#6. Listing Terms

Listing Terms are the seller's private negotiating envelope for one listing. The seller sets them once, on a Trusted Surface, when approving the listing their agent proposed. The platform stores them and enforces them on every call.

#6.1 Setting terms

1. The seller agent calls listing.create with the item and its public list price. It sends no private terms.

2. listing.create is always ask. The hosted approval page shows the listing and a form built from the category's term set. The seller fills it in and approves with their passkey.

3. The approval challenge MUST bind the listing hash and the terms_commitment (6.4). The platform MUST store exactly the terms the seller signed.

4. The seller agent learns the outcome, the term set ID and terms_commitment, never the private values.

5. A listing a seller creates by hand in the marketplace app takes the same form.

6. An agent MUST NOT pre-fill or suggest values in the terms 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. Every term set MUST include floor and available_until. Platforms MUST advertise the term sets they enforce in the config of dev.rctp.listing in their UCP profile.

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; its only tier is ask.
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 MUST NOT appear in listing data, offers, decisions, approval request bodies, webhooks, partner-readable logs or deal records.
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, including the seller's own choice, lets an agent receive them.

#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.

#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 requires_escalation → accepted, declined, expired, superseded or refused.

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.

#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

Every decision, including each refusal, appends a deal record entry (10).

#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 MUST NOT state the floor. It MAY carry counter only when the counter is above the floor.

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.

offer.create is a buyer verb: it is checked against the terms and has no tier.

#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 on the hosted page 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 forbid is a tool error with the registered reason.

#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. Private terms are seen by the seller and the platform only (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

#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.

#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 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. 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.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" },
    "counter": { "value": 340, "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;counter=340.0

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 },
  { "seq": 2, "author": "ep:marketplace.example", "action": "offer.accept", "tier": "auto", "result": "accepted", "terms_commitment": "sha-256:5b1e..." },
  { "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" }
}

#Appendix B. Resolved open issues

Raised and resolved in #21; every resolution is decision D-31.

#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.4.md