2.1.6 Internet Open Trading Protocol (trade)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Donald Eastlake 3rd <dee3@torque.pothole.com>

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

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

Description of Working Group:

The Internet Open Trading Protocol is 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 can encapsulate and support payment systems such as SET, Mondex, secure channel card payment, 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 working group will document interoperability experience with IOTP version 1 (which has been published as an Informational RFC) and develop the requirements and specifications for IOTP version 2. Version 2 will make use of an independent Messaging Layer and utilize standard XML Digital Signatures. Selection of other items for inclusion in version requirements 2 is to be from the following:

- Dynamic Definition of Trading Sequences

- Offer Request Block

- Improved Problem Resolution (extend to cover presentation of signed receipt to customer support party, etc.)

- Ability to indicate and handle a payment protocol not tunneled through IOTP

- Support for wallet servers

- Repeated/ongoing payments - Server to Server messages

- The ability to add both fields and attributes to trading blocks

- Collaboration with other protocols such as ECML.

The following is out of scope for IOTP version 2:

- legal or regulatory issues surrounding the implementation of the protocol or information systems using it.

- design of an XML Messaging Layer

The working group will specify a Secure Channel Credit Debit syntax that can be used for financial card payments in connection with IOTP.

The working group will specify requirements and specifications for Generic Rights Trading.

The working group will specify requirements for and then a syntax and processing model of ECML (Electronic Commerce Modeling Language) V2.

Goals and Milestones:

Jan 01

  

Submit SET Supplement to IESG for publication as Informational

Jan 01

  

Submit Architecture and Payment API to IESG for Informational

Jan 01

  

Submit Generic Rights Trading Requirements for Informational

Jan 01

  

Submit I-D on Secure Channel Credit/Debit ECML V2.0 Specification

Feb 01

  

Submit I-D on IOTP V2.0 Requirements

Feb 01

  

Submit I-D on Generic Right Trading Specification

Feb 01

  

Submit ECML V2.0 Requirements to IESG (Informational)

Mar 01

  

Submit IOTP V2.0 Requirements (Informational)

Mar 01

  

Submit Secure Channel Credit/Debit ECML V2.0 Specification (Proposed Standard).

Apr 01

  

Submit I-D on IOTP V2.0 Specification

May 01

  

Submit Generic Right Trading Specification (Proposed Standard)

Aug 01

  

Submit IOTP V2.0 Specification (Proposed Standard)

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2803

 

Digest Values for DOM (DOMHASH)

RFC2801

 

Internet Open Trading Protocol - IOTP Version 1.0

RFC2802

 

Digital Signatures for the 1.0 Internet Open Trading Protocol (IOTP)

RFC2935

PS

Internet Open Trading Protocol (IOTP) HTTP Supplement

RFC2936

 

HTTP MIME Type Handler Detection

Current Meeting Report

IETF 51, TRADE WG Minutes

Minutes by Donald Eastlake:
There were no changes in the agenda.

The chair reviewed the status of various documents in detail. We have five RFCs out and four documents being reviewed by our Area Director and/or the IESG on the way to becoming RFCs. There are also five documents out as Internet-Drafts but still being worked on by the working group. More activity on the mailing list would be good.

InterPay gave a presentation on their planned use of IOTP. (See slides) There was considerable discussion and a number of questions related to the presentation.

InterPay handles a lot of bank clearances in Holland. The provide a SET service but it has not been very popular and they want to go to a service with more features, similar to those in IOTP. So it is natural to borrow the IOTP formats. But they plan to add a trusted third party and need to conform to strict European privacy laws. Instead of the SET provision of multiple brand specific certificates, they are looking to a single certificate per customer model with thin clients and most of the work done at a wallet server.

In response to a question about fraud prevention, they use a trusted third party and checks in the shop software for fraud detection.

In response to a question about the cost of encryption, they indicated they already do this but that security, system cost, and ease-of-use are all important.

On communications paths, they use SSL except for the backend payment gateway link which is X.25.

In response to a question about SSL/TLS attacks, they superencrypt data and so are not completely dependent on SSL/TLS security.

In response to a question about speed, they indicated that SET transactions take 15 to 20 seconds to complete, typically, and they think a successful system has to be faster.

In response to a question about patents, InterPay indicated that it had some mostly related to anonymous delivery and not directly related to any of the standards work of the WG.

Donald Eastlake talked briefly about the ECML v2 specification. It needs more input.

Ko Fujimura gave a presentation on Voucher Trading and APIs. (See slides)

In response to a question asking if different vouchers were really just different currencies, several types which were not like currency were explained further.

In response to a question on accommodating taxes, it was indicated that this varied widely and is really the responsibility of the systems processing and entities using vouchers.

It was mentioned that NTT has a contactless smart card that can do ECDSA in 1/2 second typically giving a 1 second time for a full voucher transaction.

SCCD is looking for an author. This should be a fairly straightforward enveloping of a subset of ECML.

Their was discussion of the current state of the IOTP V2 requirements document. The consensus in the room was to move "support for wallet servers" from the may-be-included class to the will-be-included class. Other than that, the WG seemed to feel the document was ready for Last Call.

Next meeting is expected to be at the IETF meeting in Salt Lake City.

The chair again urged working group members to be more active on the mailing list.
End.

Slides

Agenda
I-OTP - Interpay
XML Voucher and VTS-API