NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00
Chair(s):
Donald Eastlake 3rd <dee3@torque.pothole.com>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Editor(s):
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:
Done |
|
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. |
Internet-Drafts:
· Requirements for Digital-Right 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
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 |
Minutes of the Internet Open Trading Protocol Working Group (trade)
Wednesday, December 13 at 1300-1500
=====================================
CHAIR: Donald Eastlake 3rd dee3@torque.pothole.com
Minutes: Walter Houser houser.walt@forum.va.gov
AGENDA:
1 Agenda Bashing
2 Status of Documents
3 Implementation Experience
4 Documents in Last Call
5 New Charter
6 ECML V2 Requirements
7 Digital Rights Requirements
8 IOTP V2 Requirements
9 TRADE Mailing List Inactivity
10 Schedule of Future Actions/Meetings
1. Agenda basking - no changes.
2. Status of Documents - Five RFCs have been issued and are listed on the current charter at http://ietf.org/html.charters/trade-charter.html.
Two drafts are in working group last call and a few more in process, also listed on the charter page.
3. Implementation Experiences of IOTP
- Hitachi, et al,
- Chris Smith, Royal Bank of Canada.
Betty deBruijn asked for contacts for implementers. Don said he would contact Hitachi and post a contact for them if they will provide one.
4. Of the currents drafts, two are in last call: Payment API for v1.0
Internet Open Trading Protocol (IOTP) at http://ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt and SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) at http://ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt
5. New Charter - Don presented the language for the new charter to be considered by the IESG on December 28, 2000. It has not changed much from previous charters. Two items are declared out of scope for IOTP version
2.0: legal and regulatory issues with respect to the implementation of the protocol, design of the XML messaging layer. The WG will specify the requirements for digitally represented trading rights. The WG will specify requirements and a syntax and processing model for ECML v2. Ned suggested that Secure Channel Credit/Debit be referred to in the Charter text. Ko
Fujimura asked that DRT specifications be added to the new charter.
There was a consensus among those at the meeting to do this.
00 Nov WG Last Call of SET Supplement and Payment API
00 Dec ID for Secure Channel Credit and debit
00 Dec submit to IESG SET Supplement and Payment API
00 Dec ID for ECML V2.0 requirements
01 Jan submit to IESG "Digital Requirements" and ECML v2.0 requirements
01 Jan ID of ECML v2.0 specification
01 Mar submit to IESG Secure Channel Credit/Debit
01 Apr submit to IESG IOTP V2.0 requirements
01 Apr submit to IESG ECML V2.0 specification (proposed standard in XML)
6. ECML Version 2.0 Requirements Document by Parsons and Shepherd. ECML v1.0 describes the customer to merchant fields to be transferred in an HTML form. There is also a usage guide. Steve Hole and Ko Fujimura raised the question "Should there be a more explicit data model?" There are fields for carrying the transaction. Don Eastlake thought this could be added to the requirements document. ECML should include multiple payment elements and types and improved company-to-company exchanges. It also refers to P3P for eCommerce, W3C note dated Nov 29, 1999. This note is ECML v1.0 plus some more payment fields but with strong P3P flavor. Shipper information and other more complex information should go to IOTP.
Microsoft and Versign have established WinPayment. IFX and OFX are in competition. Mark Hale of Interval noted that Mismal and IFX have fundamental differences in how they write their specification. When we say XML, Hole asked, "Do you go for attribute values or do you go for sub elements?"
Eastlake asked for specification applications for the ECML v2 requirements document; the current entries are left over from the XMLDSIG document. Hole suggested making the content representation like the generic representation. This would allow us to move the objects around. Mia Lahteenmaki asked what does the "simcard" string field mean and what is the protocol reference for SIM card payment? Kevin McCandliss asked "What about verification?" Eastlake said this is referenced via ISO 8583. Hole says it is usually out-of-band, say over SSL or using EBXML payload in an S/MIME envelope.
7. Digital Rights Requirements - also known as Requirements for Generic Rights Trading - presentation by Ko Fujimura.
RTS is an infrastructure to circulate diverse types of digitally represented rights. RTS is enables digital versions of coupons and tickets. We need to prevent copying. RTS should allow sharing between several issuers. There are five requirements:
- Prevent alternation
- Provide non-repudiation,
- Provide idempotency (one and only one)
- Prevent reproduction
- Prevent duplicate redemption.
Fujimura presented a Chart for Positioning of RTS in trading area shows the relationship of RTS with respect to IOTP. Hole observes that one needs to trust the coupon. Fujimura replied that trust of the coupon is the result of the issuerand the RTS. The issuer is responsible for the contents and the RTS is responsible for preventing copying. In other words, if there is trust in the issuer and the RTS, it is not required to trust the holder who transfers or redeems the coupon.
The objects transported by the RTS would be XML objects, which would be defined by the WG. Hole observed that the definition of the data representation is distinct from the transport issues. The latter may be appropriate for the WG, but they are nontrivial.
The working group suggested several terms to use in lieu of digital rights or electronic rights, such as trading right, entitlement, coupon, and certificate. There was concern about confusion of the term rights with access control rights. Entitlement was thought cumbersome. Coupon communicates too much of a limitation. Certificate has a specific meaning with respect to network security.
It was agreed to decide the term using the mailing list.
8. IOTP v2 requirements.
An author is needed for a number of items in this document. Some have asked for a standard way in IOTP v2 for payment protocols to communicate outside of IOTP as well as the current payment tunneling through IOTP v1. V2 would include payment for real property, personal property, or personal services. It may not include escrow payments depending on whether the dynamic definition of trading sequences area is included in v2. Customer workflow processes are out of scope for v2. Status queries are in scope.
9. Inactivity of the mailing lists. Should we advertise the work of the WG on other mailing lists? Hole suggested several groups including IFX and OFX. They both do payment vehicles for merchant requirements.
10. The WG will meet in Minneapolis in March. Meanwhile, we need to finish up the ECML requirements and the specification documents. There was no call to hold an interim meeting.
Agenda
Requirements for Generic Rights Trading
ECML v2 Requirements