Standards activity under the IETF Trade working group includes:
- Internet Open Trading Protocol (IOTP - RFC 2802)
- XML Voucher: Generic Voucher Language
- Electronic Commerce Modeling Language (ECML)
- Digest Values for DOM (DOMHASH - RFC 2803)
- Digital Signatures for the 1.0 Internet Open Trading Protocol (IOTP - RFC 2802)
- Internet Open Trading Protocol (IOTP) HTTP Supplement (RFC 2935)
- HTTP MIME Type Handler Detection (RFC 2936)
[April 28, 2001] From the Internet Open Trading Protocol. Version 2 Requirements: "Version 2 of the Internet Open Trading Protocol (IOTP) will extend the interoperable framework for Internet commerce capabilities of Version 1 while replacing the XML messaging and digitial signature part of IOTP v1 with standards based mechanisms. [It will replace the ad hoc XML messaging and digitial signature (RFC 2802) parts of IOTP v1 with standards based mechanisms.] IOTP Version 2 will (1) Be a superset of IOTP Version 1. (2) Provide for the Dynamic Definition of Trading Sequences. (3) Include specification of an Offer Request Block. (4) Support Improved Problem Resolution - extend to cover presentation of signed receipt to customer support party, etc. (5) Add provisions to indicate and handle a payment protocol not tunneled through IOTP. IOTP v2 will provide optional authentication via standards based XML Digitial Signatures; however, neither IOTP v1 nor v2 provide confidentiality mechanism. Both depend on the security mechanisms of any payment system used in conjuction with them to secure payments and require the use of secure channels such as those provided by TLS or IPSEC for confidentiality."
"The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, GeldKarte, etc. OTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. The developers of OTP seek to provide a virtual capability that safely replicates the real world, the paper based, traditional, understood, accepted methods of trading, buying, selling, value exchanging that has existed for many hundreds of years. The negotiation of who will be the parties to the trade, how it will be conducted, the presentment of an offer, the method of payment, the provision of a payment receipt, the delivery of goods and the receipt of goods. These are events that are taken for granted in the course of real world trade. OTP has been produced to provide the same for the virtual world, and to prepare and provide for the introduction of new models of trading made possible by the expanding presence of the virtual world. The other fundamental ideal of the OTP effort is to produce a definition of these trading events in such a way that no matter where produced, two unfamiliar parties using electronic commerce capabilities to buy and sell that conform to the OTP specifications will be able to complete the business safely and successfully. In summary, OTP supports: 1) Familiar trading models; 2) New trading models; 3) Global interoperability." [from the OTP Specification Version 0.9.9]
OTP Messages are XML documents which are physically sent between the different organisations that are taking part in a trade. Overview: "Trading Components are constructed into Trading Blocks; OTP Messages are physically sent in the form of XML documents between the different Trading Roles; OTP Messages are exchanged between Trading Roles to create an OTP Transaction; XML definitions of an OTP Message include a Transaction Reference Block which contains information which identifies the OTP Transaction and OTP Message; XML ID Attributes are used to identify OTP Messages, Trading Blocks and Trading Components; OTP Signature Components use digital signature techniques to preserve the integrity of OTP Messages and provide the trust relationships required by OTP; extra XML Elements and new user defined values for existing OTP codes can be used when Extending OTP."
The Open Trading Protocol (OTP), "a global standard for retail trade on the Internet has been published and is available now on the Internet. The complete specification for the Open Trading Protocol (OTP) developed by the leaders in Internet commerce has been posted for public comment, and pilot implementation and trials." The OTP Consortium now has over 30 member companies. "The OTP standards enable a consistent framework for multiple forms of electronic commerce, ensuring an easy-to-use and consistent consumer purchasing experience regardless of the payment instrument or software and hardware product used. The protocol is freely available to developers and users, and builds on XML, an emerging standard for information exchange on the Internet. As a set of truly open standards, the protocol is not 'owned' by any one company, and its development will be managed by an appropriate independent organization."
See especially the appendices in Part 2 (the technical specification) for the XML foundation of the protocol.
[February 11, 1998] On the [OTP] DTD watch this space [OTP List]. We hope to put a DTD based on v 0.9 of the spec on the OTP Web Site soon. When we do we'll post a message to OTP Forum. As the spec moves to version 1.0, revised DTDs will be produced. - David Burdett, Development Director, Mondex International Ltd, 04 February 1998.
References:
Internet Open Trading Protocol. Version 2 Requirements. By Donald E. Eastlake 3rd. February 2001. 'draft-ietf-trade-iotp2-req-00.txt'. [cache]
[December 30, 2002] "A Formal Service Specification for the Internet Open Trading Protocol." By Chun Ouyang, Lars Michael Kristensen, and Jonathan Billington (Computer Systems Engineering Centre, School of Electrical and Information Engineering, University of South Australia Mawson Lakes Campus, SA 5095, Australia). Paper presented at the 23rd International Conference on the Applications and Theory of Petri Nets (ICATPN 2002), Adelaide, Australia, June 24-30, 2002. "This paper presents our service specification for the Internet Open Trading Protocol (IOTP) developed using Coloured Petri Nets. To handle IOTP's complexity, we apply a protocol engineering methodology based on Open Systems Interconnection (OSI) principles consisting of five iterative steps: the definition of service primitives and parameters; the creation of an automaton specifying the local service language for each of the four trading roles of IOTP; the development of a CPN model synthesizing the local automata into a specification of the global service capturing the correlations between the service primitives at the distributed trading roles; the generation of the occurrence graph representing the global service language; and lastly a new step, language comparison to ensure the consistency between the specifications of the local service language and the global service language. The outcome is a proposed formal service specification for IOTP..."
[October 26, 2000] "Payment API for v1.0 Internet Open Trading Protocol (IOTP)." IETF Internet Draft. TRADE Working Group. By Hans-Bernhard Beykirch, Werner Hans, Masaaki Hiroya, and Yoshiaki Kawatsura. Reference: 'draft-ietf-trade-iotp-v1.0-papi-02.txt'. September 2000. "The Internet Open Trading Protocol provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. This document addresses the common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores. Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. . .The Payment API is formalized using the Extensible Markup Language (XML). It defines wrapper elements for both the input parameters and the API function's response. In particular, the response wrapper provides common locations for Error Codes and Error Descriptions. It is anticipated that this description reflects the logical structure of the API parameter and might be used to derive implementation language specific API definitions..." XML DTDs are presented in the document. [cache]
[October 27, 2000] Requirements for Digital-Right Trading By Ko Fujimura (NTT Corporation). IETF Internet Draft. 'draft-ietf-trade-drt-requirements-00.txt'. "In purchase and other trading transactions, it is often required to credit loyalty points, collect digital coupons or gift certificates, and so on. The IETF Trade Working Group is investigating how these activities can be generalized using the concept of a 'digital-right', which is a digital representation of the right to claim goods or services. This document contains the requirements in the following areas: (1) The digital rights trading model; (2) The language to describe diverse types of digital rights. This document presents the terminology, digital-right trading model, general requirements on Digital Right Trading System (DRTS), and the detail requirements of the Digital-Right Definition Language (DRDL), in which diverse types of rights can be described. Along with the Digital-Right Trading Protocol (DRTP), it enables companies or individuals to freely issue, transfer, and redeem various types of digital rights via the Internet using a specification- compliant DRTS. This document does not include protocol-related requirements, which will be presented in a separate document. To achieve consistency with other related standards shown below, the syntax of the language [DRDL] MUST be based on XML..." Details: "There are three types of participants in the digital-right trading model: issuer, holder, and collector. Their roles are as follows: (1) Issuer: Creates and issues a digital-right (2) Holder: Transfers and redeems the digital-right (3) Collector (or examiner): Collects the digital-right. The IOTP model includes merchant, deliverer, consumer and other participants. They take various roles in the settlement because a merchant, for example, can be considered as an issuer, or holder depending on whether the merchant creates the digital-right her/himself or purchases it from a wholesaler or manufacturer. A shop can also be a collector if the merchant collects gift certificate or coupons." [cache]
SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP). [cache]
- See also: "XML Messaging (IETF)."
Internet Open Trading Protocol. Version: 0.9.9, 17 August 1998. This document was submitted to the IETF Trade working group by the Open Trading Protocol Consortium. Section 10 provides an XML Overview, and Section 11 supplies the DTD. [local archive copy]
[January 18, 1999] "Internet Open Trading Protocol - IOTP. Version 1.0" TRADE Working Group. Internet Draft: draft-ietf-trade-iotp-v1.0-protocol-02.txt. David Burdett, Mondex International. 23 October 1998. "The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. . . All IOTP transaction messages are well formed XML documents. IOTP Messages are XML documents which are physically sent between the different organisations that are taking part in a trade." [local archive copy]
"Internet Open Trading Protocol (IOTP) HTTP Supplement." - "Internet Open Trading Protocol (IOTP) messages will be carried as XML documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This documents describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2068]." [local archive copy]
[October 15, 1998] OTP Document Type Definition Version 0.9.9-1; or [local archive copy]
See also: "Digital Signatures for XML." TRADE Working Group. Richard D. Brown, GlobeSet, Inc. November 1998. - "The objective of this document is to propose syntax and procedures for the computation and verification of digital signatures applicable to general XML documents." [local archive copy]
[January 19, 1999] See also: "Digital Receipt XML Data Type Definition" from the Digital Receipt Consortium.
Press release from Mondex International - "Open Trading Protocol Standards for Internet Commerce Now Available For Comment and Implementation." [local archive copy]
[March 31, 1998] "...a BoF (Birds of a Feather) meeting on the Internet Open Trading Protocol at the Internet Engineering Task Force http://www.ietf.org meeting next week. This is scheduled (subject to change) to be held in the Avalon room of the Westin Bonaventure Hotel, 404 S. Figueroa Street, Los Angeles, California, Tuesday, March 31, from 15:45 to 16:45. The purpose of the meeting will be to see if there is appropriate interest and work items to form an IETF Working Group to further develop the OTP protocol after the current 0.9/1.0 effort."
"Banking on the Java of E-Payment Systems." By Joe Nickell. In Wired News (January 23, 1998).
[June 16, 1998] Note from Donald E. Eastlake on 'IETF TRADE WG and the OTP Consortium'.
[June 23, 1998] ". . . we are now working hard on getting the next version of the OTP specs (version 1.0) out in July. At this point the technical development of OTP will be handed over the the IETF under the IETF-Trade Working Group which has recently been set up." See ietf-trade@lists.eListX.com; subscribe with 'subscribe' in the message body to ietf-trade-request@lists.eListX.com. See also the list archive.
[January 12, 1998] Press Release
Public Downloads for the draft OTP Specification
Email discussion forum: otp-forum-request@lists.commerce.net (just say 'subscribe' in the message body). See also the Monthly Archives for otp-forum.
[July 23, 1998] 'There is a meeting of the OTP Consortium scheuled for September 9-11 in Reston, Virginia.'
