CURRENT_MEETING_REPORT_ Reported by Taso Devetzis/Bellcore Minutes of the Internet Mercantile Protocols BOF (IMP) Introduction The IMP BOF session was convened to assess community interest in Internet-based commerce and to explore some concrete ideas on how that might be realized using existing technology. The session comprised two presentations together with some general discussion. Taso Devetzis presented some principles on which protocols for Internet commerce might be based followed by an illustrative example of how such principles might be realized using existing Internet technology (e.g., PEM, MIME). Mitra presented some informal ideas on what a system for Internet commerce might look like. Kick-Off Presentation The session began with the circulation of the attendance roster and other administrativa. The following agenda was accepted without much discussion: o Introductory talk - The vision - Bits, bytes, and examples o Questions and discussion o Future directions Taso began with an introductory presentation. He identified the goal as enabling commerce over the Internet---focusing on ``commercial consummation'' rather than on ``commercial foreplay.'' He also attempted to focus discussion by identifying goals that, however worthy, are not the most immediate problems for enabling Internet commerce. Among these non-goals are: o The ``electronic cash'' problem o Automation of today's billing and collection processes o The directory services problem o The resource identification and discovery problem o Replication of the entire EDI suite o Reforming society and altering the human condition 1 Taso identified the motivations for pursuing this work and cited a number of unilateral efforts as evidence of growing interest, and suggested that this technology should be driven by the needs of Internet users rather than by any of a number of other vested interests. He identified the other benefits to the community that this effort could provide: o Convenience to Internet users o Easier vendor access to broader markets o Internet commerce will help fund Internet infrastructure o Promotes Internet growth o Provides incentive for fully automated procurement and its benefits o Reduces paperwork and bureaucracy The discussion then turned to the principles on which an overall approach might be based. The emphasis was on policy-free mechanisms and the use of already-standardized Internet technology and infrastructure. o Allow for bilateral transactions (``Look ma, no trusted third party!'') o Universal deployment not required o Simple mechanism o Leverage existing Internet technology - Support for multimedia via MIME - Security enhancements via PEM - No new or exotic technology is necessary! o Provide a core mechanism to enable commerce o Decouples transport accounting from higher-layer services Taso emphasized the importance of support for bilateral transactions. Bilateral transactions are the simplest case. They represent a mechanism by which commerce is conducted over the Internet today, and new standards in this area should seek to enhance these existing capabilities rather than to restrict them in the service of a particular commercial agenda. To preclude or deprecate support for bilateral transactions is technologically to compel people to accept mediation services for all of their business---even where such mediation may be neither economically warranted nor socially acceptable. Support for bilateral transactions is not only important as a social principle, but it affords practical advantages as well. Because it represents the mode in which Internet commerce can be conducted today, it serves as a simple reference paradigm by which seemingly complicated legal or social concerns may be placed in proper perspective. Because bilateral transactions represent the mode in which Internet commerce can be conducted today, they may play a significant role in ``bootstrapping'' deployment---that is, enabling commerce even before total acceptance and deployment of the relevant infrastructures. 2 It was also observed that an approach that mechanically decouples commercial transactions from transport service accounting not only simplifies the latter but may also admit cost recovery for transport services in ways that enjoy increased social appeal. For example, the dynamics of the user's interaction with the postal service is completely decoupled from the interaction between the transacting parties. In mail-order transactions, costs for the postal service are recovered in a variety of ways that can be matched to the accounting overhead and market strategies of the parties. Example Mechanisms To illustrate these ideas, a possible solution approach that is consistent with the high-level goals was sketched out. The illustrative mechanisms exploited MIME and PEM technology to provide for secure documentation of agreements among Internet users to exchange goods and services. This mechanism supports both a bilateral transaction model, and a transaction model in which third-party mediators are desirable. Detailed examples of how the mechanism would work in both of these cases were presented. Basic protocol dynamics were sketched. A message containing an ``offer'' to make some exchange is sent from one party to the other. Should the latter party agree, that party responds with a message that ``accepts'' the tendered offer. This acceptance message documents the agreement in a potentially non-repudiable way. The goods and services being represented in the protocol can be either negotiable or non-negotiable. In this context, negotiable denotes an object of abstract value rather than a concrete object or service. For example, when you hold a negotiable interest in a company, you may not lay claim to a particular desk or paper clip, but you have an abstract claim upon the assets of the company as a whole. Similarly, a dollar is an abstract claim upon the assets of the US Treasury. A non-negotiable good is a concrete object or service, like a bushel of apples or a haircut. As an example of the simplest case, two mutually-trusting users can consummate the exchange of a tee-shirt in return for a negotiable value of ten guilders. In this case, one party sends an offer message to the other stating a willingness to exchange a specified tee-shirt (described using MIME and/or EDI conventions) for a negotiable obligation in the amount of ten guilders on the part of the other party (essentially, a personal ``IOU'' from the latter party). The offer message contains an expiration date after which the offer is no longer valid. If the second party accepts the offer, then that party responds with an acceptance message, and the transaction is concluded. A more complicated example (in which the parties do not trust each other) was also presented. In this case, the transaction is mediated by one or more third parties who are trusted by both principals. This 3 example illustrates a number of distinct functional roles that can be realized by various commercial enterprises: o Consumers -- exchange negotiables for goods or services o Merchants -- vice-versa o Co-operatives -- provide anonymity o Banks -- certify negotiables (like certifying a check) o Notaries -- certify dates (to validate contract acceptances) In this more complicated case, one principal may not be willing to accept as payment what is essentially a personal ``IOU'' from the other. Thus, as part of the offer message, the former specifies that the negotiable instrument must be certified by some trusted financial organization (e.g., Citibank). The policy by which Citibank might certify the user's payment could be related to his current bank balance, some pre-arranged credit line, or simply the cut of his/her jib. It is not a matter for protocol standardization. Because this ``check certification'' function (and also the notarization function) are themselves modelled as transactions, not only is there an established way for certifiers and notaries to get paid for their service, but also the complexity of the overall protocol is reduced. (A minor ``bootstrapping'' issue does arise: presumably, a certifier may require a customer to have at least some ``hard'' funds on account, if only to be assured of payment for the certification service.) Once a transaction is completed, a user may ask his bank (certifier) to credit his account with any new income he derived from the transaction. The user may send the transaction acceptance message to his bank, and the bank will inspect the transaction to determine what additional credit (if any) it will confer upon the user as a result of the transaction. Again, the policy by which credit is assigned is specific to the institution and not a matter of protocol standardization. Because transactions are numbered, a bank can employ fairly simple strategies to counter efforts to ``cash-in'' a single transaction multiple times (see Dukach and Sollins, among others). With appropriate protocol design, this tracking of transactions need only occur locally between a user and his bank---thereby providing a solution that is not only relatively low in cost but eminently scalable to large numbers of participants. One functional role not illustrated in the examples is the ``Cooperative.'' This function is one of obscuring the identity of a party to a transaction by acting as a proxy for some large number of parties. This straightforward strategy can (when desirable) afford an acceptable level of privacy to any transaction at lower cost and complexity than electronic cash systems. The presentation also included detailed examples of message formats and semantics not included in these minutes. 4 Observations and Discussion One participant raised the question of how multi-party transactions might be modelled by bilateral protocol exchanges. There was a brief discussion of this question in which various examples of multi-party transactions were posed and analyzed. One view that was expressed was that, in real life, sometimes what seem to be multi-party transactions (e.g., buying a house) are really collections of bilateral transactions that just happen to be concluded at the same meeting (the closing). Another view that was expressed is that it should always be possible to decompose any prima facie multi-party transaction into multiple bilateral agreements, each of which is explicitly conditioned on the others. Karen Sollins commented that mail queueing mechanisms might impose unacceptable performance constraints on interactive browse-and-buy applications. Devetzis explained that, although e-mail message formats were being used, this approach implied no necessary dependency on time-shifted e-mail delivery mechanisms: the same message formats could be used in both interactive and non-interactive modes. When the certification procedure was discussed, one of those present observed that a denial of service attack was possible unless the certification failure message is authenticated. This form of attack was not deemed to be very troubling, but it is also not much trouble to counter. Rob Shirey commented that the presentation at times used the term ``privacy'' where the term ``confidentiality'' might be more appropriate. Rob also commented that a list of what services were being provided (and which were not) would also be useful. Such a list would need to be matched against the perceived requirements. Second Presentation Mitra gave the second presentation. He described some informal ideas on what a system for Internet commerce might look like. He contrasted the strategy he described with the strategy currently in use by a prototype server. He invited session participants to contact this server on host ``path.net'' at port 8001. The described strategy had five components: 1. Information Provider - the party who actually produces some information for distribution. 2. Information Retailer - the party who makes information available for sale to Internet users. The Internet system operated by a retailer is sometimes called a ``gateway.'' 3. Host Operator - the party that operates a host system that is used by Internet users for Internet commerce. 5 4. User - the party who buys stuff from an Information Retailer using a system provided by a Host Operator. 5. Authentication Server - the party who authorizes charges made by an Information Retailer against the account of a Host Operator. Mitra explained that, in his model, Host Operators and Retailers are authenticated by IP address. Via traditional, out-of-band channels, the Authentication Server bills the Host Operator who in turn bills the attached User for purchased goods. Mitra identified three trust relationships that are present in his system: Host to Authentication Server, Gateway to Authentication Server, and User to Host. Phill Gross asked about the way in which such a system could scale to a large number of users. Mitra suggested that a hierarchy of such servers could address the scaling problem, and he cited the use of a single server for Visa credit card authorizations. Some Issues Mitra also identified three points for discussion by the group that he felt were especially important: 1. Bilateralism: because a great many transactions will occur between parties that do not trust each other, a protocol that supports only bilateral transactions between trusting parties is not adequate. 2. An acceptable protocol must support ``real-time,'' interactive use. 3. An acceptable protocol must be compatible with existing Internet applications (e.g., Gopher). Brief discussion led to general agreement on the second and third points. Neither point was regarded as inconsistent with the proposed leveraging of MIME and PEM technology. Although time did not permit full discussion of the first point above, it is not clear that it represented a point of actual disagreement as much as a particular way of expressing generally shared beliefs. Conclusion Erik Huizer, IETF Area Director for Applications, concluded the meeting by saying that interest in this topic was clearly sufficient to merit further work but that further definition of the task would be valuable 6 before chartering a working group. To this end, specific topics for e-mail discussion were identified. If these topics lead to clearly identifiable work items, a follow-on BOF session, for discussing these work items in view of the possible creation of a WG, will be considered by the area director. Action Items 1. David Ginsburg of Alcatel SEL volunteered to compile and post via the mailing list a survey of existing experiences in conducting commerce over the Internet. 2. Taso Devetzis took the action of adding the names of the BOF attendees to the mailing list (imp-interest@thumper.bellcore.com). 3. Devetzis took the action item of continuing discussion over e-mail in order to identify work items for the group in addition to those areas of study that would not be appropriate for the IETF. 4. Devetzis took the action item of organizing a second BOF session at the next IETF meeting in order to crystalize intervening e-mail discussion into agreed work items and a framework for continued work. 5. All present took the action item of contributing descriptions of current mechanisms for Internet commerce as Internet Drafts. Attendees George Abe abe@infonet.com Toshiya Asaba asaba@iij.ad.jp Josee Auber Josee_Auber@hpgnd.grenoble.hp.com J. Nevil Brownlee nevil@ccu1.aukuni.ac.nz Ross Callon rcallon@wellfleet.com David Crocker dcrocker@mordor.stanford.edu James Davin davin@thumper.bellcore.com Taso Devetzis devetzis@bellcore.com Hans Eriksson hans@sics.se Peter Furniss p.furniss@ulcc.ac.uk David Ginsburg ginsb@us-es.sel.de Ramesh Govindan rxg@thumper.bellcore.com Phillip Gross pgross@ans.net Marc Horowitz marc@mit.edu Erik Huizer Erik.Huizer@SURFnet.nl Frank Kastenholz kasten@ftp.com Sean Kennedy liam@nic.near.net Michael Khalandovsky mlk@ftp.com Peter Kirstein P.Kirstein@cs.ucl.ac.uk John Klensin Klensin@infoods.unu.edu Andrew Knutsen andrewk@sco.com 7 John Larson jlarson@parc.xerox.com Paul Lustgarten Paul.Lustgarten@att.com Cynthia Mills cmills@bbn.com Mitra mitra@pandora.sf.ca.us Andrew Partan asp@uunet.uu.net Michael Patton map@bbn.com Shawn Routhier sar@epilogue.com Miguel Sanz miguel.sanz@rediris.es Eve Schooler schooler@isi.edu Robert Shirey shirey@mitre.org A. Velu Sinha avsinha@attmail.com Timon Sloane timon@timon.com Karen Sollins sollins@lcs.mit.edu Kamlesh Tewani ktt@arch2.att.com Susan Thomson set@bellcore.com Claudio Topolcic topolcic@cnri.reston.va.us Mario Vecchi mpv@thumper.bellcore.com John Veizades veizades@wco.ftp.com Sandro Wallach sandro@elf.com Abel Weinrib abel@bellcore.com 8