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 ([email protected]).

 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               [email protected]
Toshiya Asaba            [email protected]
Josee Auber              [email protected]
J. Nevil Brownlee        [email protected]
Ross Callon              [email protected]
David Crocker            [email protected]
James Davin              [email protected]
Taso Devetzis            [email protected]
Hans Eriksson            [email protected]
Peter Furniss            [email protected]
David Ginsburg           [email protected]
Ramesh Govindan          [email protected]
Phillip Gross            [email protected]
Marc Horowitz            [email protected]
Erik Huizer              [email protected]
Frank Kastenholz         [email protected]
Sean Kennedy             [email protected]
Michael Khalandovsky     [email protected]
Peter Kirstein           [email protected]
John Klensin             [email protected]
Andrew Knutsen           [email protected]

                                  7





John Larson              [email protected]
Paul Lustgarten          [email protected]
Cynthia Mills            [email protected]
Mitra                    [email protected]
Andrew Partan            [email protected]
Michael Patton           [email protected]
Shawn Routhier           [email protected]
Miguel Sanz              [email protected]
Eve Schooler             [email protected]
Robert Shirey            [email protected]
A. Velu Sinha            [email protected]
Timon Sloane             [email protected]
Karen Sollins            [email protected]
Kamlesh Tewani           [email protected]
Susan Thomson            [email protected]
Claudio Topolcic         [email protected]
Mario Vecchi             [email protected]
John Veizades            [email protected]
Sandro Wallach           [email protected]
Abel Weinrib             [email protected]



                                  8