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.