NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Donald Eastlake 3rd <dee3@torque.pothole.com>
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
Surendra Reddy <skreddy@us.oracle.com>
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
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.
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) |
· Requirements for Generic Voucher Trading
· Payment API for v1.0 Internet Open Trading Protocol (IOTP)
· SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP)
· Electronic Commerce Modeling Language (ECML):Version 2 Requirements
· XML Voucher: Generic Voucher Language
· Electronic Commerce Modeling Language (ECML):Version 2 Specification
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 |
Internet Open Trading Protocol Working Group (WG) - TRADE
Minutes of meeting in Minneapolis at the 50th IETF Meeting
WEDNESDAY, March 21 at 1300-1500
================================
CHAIR: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
REPORTER: Walter Houser <houser.walt@forum.va.gov>
edits: Donald E. Eastlake 3rd.
Agenda Bashing - no change.
Documents Status - Don presented his report, which appears in the slides that will be submitted to the proceedings. Three documents have in working group last call for some time: draft-ietf-trade-iotp-v1.0-papi-03.txt, draft-ietf-trade-iotp-v1.0-set-02.txt, and draft-ietf-trade-drt-requirements-02.txt. Due to comments during WG last call, the title Digital Rights has been changed to Voucher in the drt-requirements draft. Minor edits for readability have been made in the papi-03 draft producing papi-04 which is available from <ftp://ftp.pothole.com/pub/ietf-trade/> and will shortly be posted in the IETF Internet-Draft directories. The consensus among those at the WG meeting was to submit these for publication as Informational RFCs.
Don listed the existing drafts currently under consideration:
draft-ietf-trade-voucher-lang-00.txt,
draft-ietf-trade-ecml2-req-00.txt, draft-ietf-trade-ecml2-spec-00.txt,
draft-ietf-trade-iotp2-req-00.txt. The ECML Version 2 requirements
document is fairly close to final but the others need work.
Two WG documents are called for that do not yet exist:
1) Secure Channel Credit Debit, a payment method of equivalent security to HTML forms. Don suggested this might be accomplished by light encapsulation of ECML. There were no objections at the meeting to this approach.
2) IOTP v2 specification, scheduled for April, no author yet which makes meeting that milestone pretty unlikely...
Tony Lewis requested that updated milestone dates be posted in the WG's IETF web page. Don will look into the Charter change that would require.
IOTP/ECML Implementation Experience - Don reported that these include the V1 IOTP Japanese SMILE project. There is a partial list of merchant sites at http://www.ecml.org/, but the list needs to be updated. It notes the IBM wallet and the Microsoft wallet.
ECML V2 Requirements - Is this ready for last call? Don plans a last call in a month. V1 was HTML form oriented, whereas v2 is to be XML oriented. Comments solicited.
ECML V2 Specification - ISO 8583 fields being added. Dave Shepherd of IBM (mailto:dshepher@us.ibm.com) suggested incorporating changes for Java Commerce messages (JCM). JCM uses lineItems, which do not appear in ECML v2. We currently don't have a namespace for ECML. V1 has a DTD but no schema or namespace. Parsons has added fields for v2.
What syntax do we use to ask for missing data? When asking for data, how do we indicate whether the request is Optional or mandatory?
XML Voucher: Generic Voucher Language - Ko Fujimura of NTT (mailto:fujimura@isl.ntt.co.jp) presented background on voucher and current status. Voucher component is not an instance but a definition of voucher. VC defines the rights (or value) per one unit of the voucher instance. Ko outlined the processing model (see slides). Ko plans to publish an API. He is proposing a new trust model based on the voucher components (see slides). The monetary value properties are needed to calculating the redemption. His studies suggest that 90 percent of vouchers can be provided using three or four properties:
1. Minimum number of vouchers needed for redemption
2. Merchandise limitation
3. Merchandise value can be specified in as fixed or percentage of discount.
An xml:ns is specified. Proposed actions for April include Internet-Draft on XML voucher and submit Internet-Draft on VTS (Voucher Trading System) API. Although much discussion on voucher, no major issues so far. Ko asked how should we proceed with specifying the VTS API?
Don noted that our past experience in specifying an API in XML was not satisfactory. But a Java or C binding is reasonable. As the author provides the dates, he saw no problem. There were no other comments.
IOTP V2 Requirements - Version 2 is to be a superset of v1 (but not necessarily backward compatible), dynamic definition of trading sequences, offer request block, improved problem resolution, handle payment protocols not tunneled through IOTP, say via TCP. Optional items include support for wallet servers, repeated or ongoing in payment, enhance server to server (timing of submissions to the payment handler), and the ability to add both fields and attributes to trading blocks. Not to be included are legal and regulatory issues, the XML messaging layer, and XML digital signature. Perhaps a profile on these standards use with IOTP V2 may in order.
Walt Houser asked which XML messaging layer would be used? Don replied that was to be decided but he thought ebXML was a bit ahead. Walt noted that ebXML uses SOAP rather than BEEP. SOAP is an industry consortia protocol that competes with the IETF BEEP standard.
Tony Lewis asked if there is anything in the way of the digital signature becoming a standard? Don replied that the work of the joint IETF/W3C XML Digital Signature Work Group is currently a Proposed Standard in the IETF [RFC 3075] and a Candidate Recommendation in the W3C. The W3C plans to make it a full RECommendation abut the time the IETF should be advancing it to Draft Standard. It is unclear when the IETF will further advance it to Full Internet Standard because this requires widespread deployment.
Ko asked how would one approach dynamic definition of trading sequences. Don replied describing one method, which has been partially specified by Dave Burdett, where the merchant proposes the structure of the trade along with the prices and currencies, etc.
Schedule of Future Actions/Meetings -
1) Authors are needed for SCCD and IOTP v2 specification
2) The WG will meet in London in early August and until then continue work on the mailing list.
The WG meeting adjourned at 14:22