FW: Draft minutes of trade IETF San Diego

[Eastlake III Donald-LDE008 <[e-mail]>]

Minutes of the Internet Open Trading Protocol Working Group (trade)

Wednesday, December 13 at 1300-1500
=====================================

CHAIR: Donald Eastlake 3rd [e-mail]
Minutes: Walter Houser [e-mail]

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 Requirement for Generic
Payments Rights - 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 issuer, which can be handed around by untrusted bodies. The
RTS object is an XML object, 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. 

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.