2.1.6 Internet Open Trading Protocol (trade)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 16-Feb-99


P Vixie <dee3@torque.pothole.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Patrik Faltstrom <paf@swip.net>


Surendra Reddy <skreddy@us.oracle.com>

Mailing Lists:

General Discussion:ietf-trade@lists.eListX.com
To Subscribe: ietf-trade-request@lists.eListX.com
In Body: (un)subscribe
Archive: http://www.eListX.com/archives/ietf-trade

Description of Working Group:

The Internet Open Trading Protocol provides an interoperable framework for Internet commerce. It is optimized for the case where the buyer and the merchant do not have a prior acquaintance and is payment system independent. It will be able to encapsulate and support payment systems such as SET, Mondex, CyberCash's CyberCoin, DigiCash's e-cash, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the deliverer of goods or services, and the provider of customer support are performed by different Internet sites.

The Internet Open Trading Protocol (IOTP) working group will (1) determine requirements and document scenarios for IOTP message transport and for IOTP version 2 specification, (2) document interoperability experience with IOTP version 1 (which will have been published as Informational), and (3) develop the specification for IOTP transport and IOTP version 2.

Selection of items for inclusion in version 2 is expected to be from the following and others suggested by the Working Group:

- Dynamic Definition of Trading Sequences - Multiple Protocol Options - Offer Request Block - Public Key Signatures (v1.0 uses secret key signatures) - Signatures on the Delivery Response - Improved Problem Resolution (extend to cover presentation of signed receipt to customer support party, etc.) - Selection of Additional Options - OTP Architecture (informational development of standard interfaces to software components).

The following are out of scope for version 2:

- server to server messages (except as messages needed for client to server communications may also be useful for server to server communications) - legal or regulatory issues surrounding the implementation of the protocol or information systems using it.

Goals and Milestones:

Jul 98


Submit IOTP v1.0 to the IESG to consider publication as an Informational RFC.

Oct 98


Submit Internet-Draft of Open Trading Protocol requirements and scenarios

Oct 98


Submit IOTP transport requirements Internet Draft

Dec 98


Submit Internet-Draft on IOTP v1.0 interoperability experience

Jan 99


Submit Internet-Draft on IOTP transport requirements to IESG for publication as an Informational RFC.

Jan 99


Submit Internet-Draft on IOTP v1.0 interoperability experience to IESG for publication as an Informational RFC.

Feb 99


Submit Internet-Draft of IOTP v2.0 specification

Feb 99


Submit Internet-Draft of IOTP transport specification

May 99


Submit IOTP transport specification I-D to IESG for consideration as a Proposed Standard.

Jun 99


Submit IOTP v2.0 specification I-D to IESG for consideration as a Proposed Standard.


No Request For Comments

Current Meeting Report

TRADE WG Meeting 3/17/1999

Started 1999, March 17th, 13:05

Reported by Kent Davidson, Edited by Donald Eastlake, Chair Donald Eastlake.

The WG meeting agenda was presented and agreed to.

David Burdett spoke about what changes were made to the main document between version 02 and 03 (See slides).

Hitachi indicated there were putting together a document on how they will implelement the Payment Instrument Customer Care transaction.

A question was raised as to whether using the SET brand structure which has embedded colons (":") would be a problem. Answer: No.

The chair announced he was planning to proceed to working group last call on the main IOTP document and association digital signature spec with an aim towards sending them up to the IESG to become Informational RFCs. There was substantial support for this and no objections.

David Burdett spoke on splitting out the messaging level of IOTP in the future into a separate specification, possibly called XML Messaging (other suggestions for name welcome).

The digital signature part of IOTP is having its own BoF for a more general XML DSIG standard.

Future vesions of trading domain specific IOTP items could be developed after feedback from pilots of IOTP 1.0

(See XML Messaging slides.)

WG reaction was positive to XML Messaging. One attendee said their company was trying to send encapsulated XML data back and forth and could use XML Messaging.

Audience question: Can you link transactions?
Answer: Yes, RelatedTo option allows for linking of different transactions
Audience: Good example is authorization for credit card payment and subsequent settlement

What we could do is take this XML Messaging specification and back to (slide 4) use these for implementation, lift this out and create a new standard for exchanging XML documents. How can we best take it forward?

Chair: There has been a WG consensus for modularizing our documentation after v1.0 is out. Splitting out messaging level follows that. But explicitly making it a general XML transaction protocol seems out of our scope.

The core applications protocol BoF (APPLCORE) is asking for drafts for this type of thing. The mindset there, however, was different than this so they may not want to take it.

Question: For now the is the focus to stay in the IOTP protocol? Is there any intent of becoming generic XML messaging?

Chair Answer: XML Mesaging was described by David Burdett in the general fashion but it is that layer of the current trading protocol effort. There's virtue in layering, etc. Even if it's never used outside of IOTP, it makes sense to keep it as a separate, modular document.

Question: Could this apply in the OBI (Open Buying on the Innternet) community?

Answer: OBI is heading towards XML. It should serve OBI quite well. OBI is another organization. Any individuals may present this to OBI.

Question: XML is owned by the W3C. Should we be taking this on?
Chair Answer: IP was designed by IETF but not all applications using IP are within IETF.

Consensus at meeting was that it was useful to split out the messaging layer into a separate document.

Kent Davidson, Differential, then spoke about XML DSIG document which supplements the main specification.

It is based on Richard Brown's digital signing document. His document was very broad and had various aspects which did not apply to IOTP. Major changes were making Originator and Recipient information specific to IOTP, instead of the generic representation in dsig. We also made the algorithm specifications more reusable to keep the signature components of IOTP small.

Donald Eastlake spoke briefly on the HTTP supplement, which is how to do IOTP over HTTP. It is based on a document originally by Chris Smith. Needs a little more work. Comments welcome.

On the Architecture and Payment API supplement, it gives an example of how you might structure an implementation, how you might have an interface to different payment systems, etc. See slides for URL. This has not yet been converted to Internet Draft form.

Andrew Drapp talked about the SET supplement, which is how to use SET inside IOTP. It need some changes to track the Current API document.A new version will be out in a month or two.

The IOTP SCCD Supplement will cover how to use credit and debit cards via a secure channel. An early version of the document was done by JCP. A request was made for volunteers to work on it and Tom Arnold from CyberSource volunteered.

There is no document yet to how to use eCheck with IOTP.

Andrew Drapp gave a presentation on the SMILE pilot (see slides) which will use IOTP. It is sponsored by MITI (Japanese Ministry of International Trade and Industry).

Detecting whether or not wallet software (in this case an applicaton/iotp MIME type handler) is installed is not easy. Most browsers don't tell you if they accept a type in the appropriate HTTP header. Instead the just reply with */*. We should document an engineering solution to this problem

There was a brief description of the ANSI X9.59 standards which can be used as a building block for a secure payment protocol. No one volunteered to do any work or further investigation in the X9.59 area.

We need to update our charter. People should think about this.

Next WG meeting will July at the IETF meeting in Oslo, Norway.

Meeting terminated 1999, March 17, 14:35


CHANGES "02" TO "03"
Standard SMart Card Integrated SettLEment System Project - SMILE Project -