Internet Mercantile Protocols BOF
27th IETF Plenary, Amsterdam
Wednesday, 14 July 1993
T. Devetzis J. Davin
August 3, 1993
The Internet Mercantile Protocols (IMP) Birds-of-a-Feather 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 (Bellcore) 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
(Pandora Systems) presented some informal ideas on what a system for
Internet commerce might look like.
2 Kick-Off Presentation
The session began at 16:11 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 Not to solve the "electronic cash" problem
o Not to automate today's billing and collection processes
o Not to solve the directory services problem
o Not to solve the resource identification and discovery problem ...
o Not to replicate the entire EDI suite
o Not to reform society and alter the human condition
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
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 bi-lateral 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
bi-lateral 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
Support for bi-lateral 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 bi-lateral 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
It was also observed that an approach that mechanically decouples
commercial transactions from transport service accounting not only
simplifies the latter but also 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.
3 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 bi-lateral
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 U.S. 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
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
parties. This straightforward strategy can (when desirable) affords 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 bi-lateral
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 bi-lateral 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 email message formats
were being used, this approach implied no necessary dependency on
time-shifted email 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
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.
5 Pandora Systems
A second presentation was made by Mitra of Pandora Systems. Mitra
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.
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, User to Host.
Phill Gross asked about the way in which such a system could scale to
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.
6 Some Issues
Mitra also identified three points for discussion by the group that he
felt were especially important:
1. Bi-lateralism: because a great many transactions will occur
between parties that do not trust each other, a protocol that
supports only bi-lateral transactions between trusting parties is
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.
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 before chartering a working group. To this end, specific
topics for email discussion were identified. If these topics lead to
clearly identifiable workitems, a follow-on BOF session, for
discussing these workitems in view of the possible creation of a WG,
will be considered by the AD.
8 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@example.com).
3. Devetzis took the action item of continuing discussion over email
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 email
discussion into agreed work items and a framework for continued
5. All present took the action item of contributing descriptions of
current mechanisms for Internet commerce as Internet Drafts.
Created before October 2004