Summary

  • RFC 3354 required a prospective IOTP v2 to let parties propose arbitrary trading-step sequences, but the proposal itself did not authorize a payment, prove shipment or execute a charge.
  • Its examples kept bounded approval for future purchases, shipment evidence, external payment authorization, charge execution, settlement and customer-care receipts on distinct control surfaces.

Imagine an online purchase in which the merchant may charge only after a warehouse says that the goods have shipped. The order looks simple: offer, customer agreement, shipment message, charge, receipt. Put those blocks in a protocol diagram and the arrow between shipment and charge can quietly acquire too much meaning. Did the warehouse merely report an event? Did the customer consent to one charge or ten? Did the payment system authorize the amount? Was money actually captured? A sequence can describe the intended order without answering any of those questions.

RFC 3354, published as an Informational document in August 2002, made flexibility a requirement for a proposed second version of the Internet Open Trading Protocol. IOTP version 1 had modeled electronic trade through roles, blocks and message exchanges. The requirements work wanted to retain that foundation while removing the assumption that a transaction consisted of one payment followed by one delivery. Parties should be able to propose an arbitrary sequence of transaction steps.

The decisive word is propose. It describes compositional freedom, not a standing mandate. A party may suggest that shipment precede charging, that an external payment protocol run between two IOTP steps, or that customer care receive a signed receipt after a failure. The resulting graph identifies possible dependencies. It does not, merely by existing, supply the customer’s consent, the payment handler’s authorization or evidence that any step occurred.

That boundary matters because RFC 3354 was a requirements document, not the completed IOTP v2 protocol. It divided ideas into capabilities the future specification would include, capabilities it might include and subjects outside its scope. The IETF TRADE working-group history records the requirements milestone as complete. That is evidence that the design questions were documented, not that a v2 protocol, implementation or deployment was completed.

The required set was already ambitious. It included dynamic trading sequences, an Offer Request Block, improved problem resolution, a clearer Customer Care role, support for payment protocols that were not tunneled through IOTP, and server-based wallets. A customer encountering a problem should be able to present a signed receipt to customer support. Yet the receipt did not compel a refund or prove that the support agent had authority to issue one. It was bounded evidence for a dispute process.

Likewise, a server wallet was a place where delegated payment functions might live. Its presence did not authenticate the person now using it, enlarge an earlier consent or erase the payment system’s own checks. Support for an external payment protocol was an architectural admission that orchestration and payment execution were different domains. The trade flow could invoke or coordinate a payment system without absorbing its authorization and settlement facts.

RFC 3354 placed repeated or ongoing payments in the optional, “may include” group. Its example was carefully limited: a customer could approve a finite number of future purchases, subject to a total spending ceiling or a limit per purchase. This was not infinite consent. A usable grant would need to carry scope: which merchant or purpose, how many purchases remained, what maximum applied, when the approval expired and whether it had been revoked.

Every later payment would still require a decision against that grant. A request inside the permitted count might exceed the per-purchase limit. A small request might arrive after expiry. A valid-looking request might concern the wrong merchant. The orchestration engine could order the test, but it could not declare success by pointing to the sequence itself. Authorization was an evaluated fact, not a property of the arrow.

The document’s shipment example exposes the same separation from the opposite direction. An enhanced server-to-server message might let a Delivery Handler tell a Payment Handler that goods had shipped. The payment handler could treat that notice as a precondition for a credit-card charge. But a precondition is not a command. The message reported what an identified handler asserted. It did not prove physical delivery, customer acceptance, issuer authorization, capture or settlement.

A robust implementation would therefore preserve at least three records: the authenticated shipment assertion and its scope; the rule that says which shipment state is sufficient for which payment request; and the payment system’s own authorization or refusal. If a charge follows, capture and settlement produce further records. Compressing all of them into “shipment triggered payment” may be convenient for a dashboard, but it destroys the evidence needed when the event is late, duplicated, revoked or disputed.

The adjacent IOTP documents reinforce this layered view without changing RFC 3354’s status. RFC 2801 defined version 1 transactions, roles, identifiers and idempotent processing. That history explains how duplicate messages could be handled safely; it does not turn a new v2 sequence into purchase authority. RFC 2802 used manifests to define which IOTP components a digital signature covered. A valid signature authenticates only the selected material under the relevant key and processing rules. It does not fill in absent consent.

RFC 2935 described carrying IOTP over HTTP. A transport can deliver an offer, shipment notice or payment-related message, but delivery of bytes does not determine the message’s commercial power. RFC 3106 standardized field names used to collect customer information. A common vocabulary makes data interoperable; it does not validate an address, identity or entitlement.

RFC 3275 supplied XML Signature syntax and processing, which RFC 3354 expected to reuse rather than reinvent. RFC 2246 supplied TLS channel protection. The requirements document was explicit about the division: IOTP itself had no confidentiality mechanism, so TLS or IPsec could protect the channel, while the chosen payment system remained responsible for payment security. Confidential transport, authenticated content and commercial authority were related, but none substituted for the others.

The optional ability to add fields and attributes to existing trading blocks posed the same governance problem in miniature. Extensibility gives a message greater representational capacity. It does not make every new field authoritative. A field named “approved,” for example, is only an assertion until its producer, scope, signature, policy basis and current validity are established.

Legal and regulatory questions were explicitly outside RFC 3354’s scope. Protocol conformance therefore could not prove enforceability, consumer-law compliance or the right to charge in a jurisdiction. That exclusion was not a defect to be patched with a larger schema. Local law and institutional authority vary; encoding them all in a universal trading grammar would have made the protocol both brittle and misleading.

Later IOTP work offers useful context but no retroactive proof of v2 deployment. RFC 3538 supplemented IOTP v1 for SET. RFC 3867 later specified an API between an IOTP application core and payment modules. That API made the architectural seam even clearer: a trading application could coordinate with payment-specific machinery while preserving separate results and error states. Neither document proves that the RFC 3354 requirements became a deployed v2 system.

The historical importance of RFC 3354 lies in what it did not collapse. It allowed the transaction grammar to become more expressive while leaving authority where it belonged. A proposed sequence was a plan. A customer approval was a bounded grant. A shipment notice was event evidence. A signature authenticated selected content. TLS protected a channel. A payment system authorized and executed a charge. Settlement and a customer-care remedy happened still later.

That distinction remains useful wherever workflows are automated. Modern systems often turn event streams into actions: a parcel status releases funds, a usage threshold creates an invoice, or a subscription schedule initiates a debit. The engineering temptation is to treat a configured sequence as permission. RFC 3354 points toward the safer design: keep the sequence flexible, but force each irreversible act to present its own authority and receipt.

Sources