<pre>Network Working Group                                        K. Fujimura
Request for Comments: 3506                                           NTT
Category: Informational                                      D. Eastlake
                                                                Motorola
                                                              March 2003


        <span class="h1">Requirements and Design for Voucher Trading System (VTS)</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   Crediting loyalty points and collecting digital coupons or gift
   certificates are common functions in purchasing and trading
   transactions.  These activities can be generalized using the concept
   of a "voucher", which is a digital representation of the right to
   claim goods or services.  This document presents a Voucher Trading
   System (VTS) that circulates vouchers securely and its terminology;
   it lists design principles and requirements for VTS and the Generic
   Voucher Language (GVL), with which diverse types of vouchers can be
   described.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

Table of Contents

   <a href="#section-1">1</a>.  Background ....................................................<a href="#page-2">2</a>
   <a href="#section-2">2</a>.  Terminology and Model .........................................<a href="#page-3">3</a>
       <a href="#section-2.1">2.1</a> Voucher ...................................................<a href="#page-3">3</a>
       <a href="#section-2.2">2.2</a> Participants ..............................................<a href="#page-3">3</a>
       <a href="#section-2.3">2.3</a> Voucher Trading System (VTS) ..............................<a href="#page-4">4</a>
   <a href="#section-3">3</a>.  VTS Requirements ..............................................<a href="#page-5">5</a>
       <a href="#section-3.1">3.1</a> Capability to handle diversity ............................<a href="#page-6">6</a>
       <a href="#section-3.2">3.2</a> Ensuring security .........................................<a href="#page-6">6</a>
       <a href="#section-3.3">3.3</a> Ensuring practicality .....................................<a href="#page-7">7</a>



<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   <a href="#section-4">4</a>.  Scope of VTS Specifications ...................................<a href="#page-7">7</a>
       <a href="#section-4.1">4.1</a> Voucher Trading Protocol ..................................<a href="#page-7">7</a>
       <a href="#section-4.2">4.2</a> VTS-API ...................................................<a href="#page-8">8</a>
       <a href="#section-4.3">4.3</a> Generic Voucher Language ..................................<a href="#page-8">8</a>
   <a href="#section-5">5</a>.  GVL Requirements ..............................................<a href="#page-8">8</a>
       <a href="#section-5.1">5.1</a> Semantics .................................................<a href="#page-8">8</a>
       <a href="#section-5.2">5.2</a> Syntax ....................................................<a href="#page-9">9</a>
       <a href="#section-5.3">5.3</a> Security .................................................<a href="#page-10">10</a>
       <a href="#section-5.4">5.4</a> Efficiency ...............................................<a href="#page-10">10</a>
       <a href="#section-5.5">5.5</a> Coordination .............................................<a href="#page-10">10</a>
       <a href="#section-5.6">5.6</a> Example of GVL ...........................................<a href="#page-10">10</a>
   <a href="#section-6">6</a>.  Application Scenarios ........................................<a href="#page-11">11</a>
   <a href="#section-7">7</a>.  Q &amp; A ........................................................<a href="#page-13">13</a>
   <a href="#section-8">8</a>.  Security Considerations ......................................<a href="#page-13">13</a>
   <a href="#section-9">9</a>.  Acknowledgments ..............................................<a href="#page-13">13</a>
   <a href="#section-10">10</a>. References ...................................................<a href="#page-13">13</a>
   <a href="#section-11">11</a>. Authors' Addresses ...........................................<a href="#page-14">14</a>
   <a href="#section-12">12</a>. Full Copyright Statement......................................<a href="#page-15">15</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Background</span>

   It is often necessary to credit loyalty points, collect digital
   coupons or gift certificates, etc, to complete purchases or other
   trading transactions in the real world.  The importance of these
   activities is also being recognized in Internet Commerce.  If a
   different issuing or collecting system to handle such points or
   coupons must be developed for each individual application, the
   implementation cost will be excessive, inhibiting the use of such
   mechanisms in electronic commerce.  Consumers may also be forced to
   install a number of software modules to handle these points or
   coupons.

   A voucher is a digital representation of the right to claim services
   or goods.  Using vouchers, a wide-range of electronic-values,
   including points or coupons, can be handled in a uniform manner with
   one trading software module.

   This document presents the terminology and model for a Voucher
   Trading System (VTS) that circulates vouchers securely; it also lists
   design principles and requirements for a VTS and the Generic Voucher
   Language (GVL), with which diverse types of vouchers can be
   described.









<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology and Model</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Voucher</span>

   A voucher is a digital representation of the right to claim goods or
   services.  To clarify the difference between vouchers and electronic
   money/digital certificates, we introduce a formal definition of
   vouchers in this document.

      Let I be a voucher issuer, H be a voucher holder, P be the
      issuer's promise to the voucher holder.  A voucher is defined as
      the 3-tuple of &lt;I, P, H&gt;.

   Examples of P are as follows:

   o  Two loyalty points are added to the card per purchase.  If you
      collect 50 points, you'll get one item free.  (Loyalty points)

   o  Take 10% off your total purchase by presenting this card.
      (Membership card)

   o  Take 50% off your total purchase with this coupon.  The purchase
      transaction uses up the coupon.  (Coupon)

   o  The bearer can access "http://..." for one month free.  (Free
      ticket for sales promotion)

   o  The bearer can exchange this ticket for the ordered clothes.
      (Exchange ticket or Delivery note)

   o  Seat number A-24 has been reserved for "a-concert" on April 2.
      (Event ticket)

   Note that P does not need to be described in terms of a natural
   language as long as the contents of the vouchers are specified.  For
   example, a set of attribute name and value pairs described in XML can
   be employed to define the contents.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Participants</span>

   There are four types of participants in the voucher trading model:
   issuer, holder, collector, and VTS provider.  Their roles are as
   follows:

   Issuer: Creates and issues a voucher.  Guarantees contents of
      the voucher.





<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   Holder (or user): Owns the vouchers.  Transfers and redeems
      the voucher to other users or collector.

   Collector (or examiner): Collects or examines the voucher and
      implements its promise.  In general, compensated by goods or
      services rendered.

   VTS Provider: Provides a VTS and guarantees that a particular
      voucher is not assigned to multiple holders or used multiple times
      unless permitted for that voucher type.

   The IOTP model [<a href="#ref-IOTP" title="&quot;The Internet Open Trading Protocol&quot;">IOTP</a>] includes merchant, deliverer, consumer and
   other participants.  They take various roles in the settlement
   because a merchant, for example, can be considered as an issuer, or
   holder depending on whether the merchant creates the voucher
   her/himself or purchases it from a wholesaler or manufacturer.  A
   merchant can also be a collector if the shop collects gift
   certificate or coupons.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> Voucher Trading System (VTS)</span>

   A voucher is generated by the issuer, traded among holders (users),
   and finally is collected by the collector:

          &lt;I, P, H&gt;        &lt;I, P, H'&gt;         &lt;I, P, H'&gt;
   Issuer I --------&gt; User H ---------&gt; User H' ---------&gt; Collector
           Issue            Transfer           Redemption

                     Figure 1. Life cycle of vouchers

   The VTS provider supplies a VTS that enables vouchers to be
   circulated among the participants securely.

   A formal definition of VTS is as follows:

      A voucher trading system (VTS) is a system that logically manages
      a set of valid vouchers VVS, which is a subset of {&lt;I, P, H&gt; | I
      in IS, P in PS, H in HS} where IS is the set of issuers, PS is the
      set of promises, and HS is the set of holders; VTS prevents them
      from being modified or reproduced except by the following three
      transactions: issue, transfer, and redemption.  The initial state
      of the VVS is an empty set.

      Note that this does not imply that VVS is stored physically in a
      centralized database.  For example, one implementation may store
      vouchers in distributed smart cards carried by each holder [<a href="#ref-T00" title="&quot;Copy Prevention Scheme for Rights Trading Infrastructure&quot;">T00</a>],





<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


      or may store them in multiple servers managed by each issuer or
      trusted third parties.  This is a trust policy and/or
      implementation issue [<a href="#ref-MF99" title="&quot;Distributed Digital-Ticket Management for Rights Trading System&quot;">MF99</a>].

   Issue
      An issue transaction is the action that creates the tuple of &lt;I,
      P, H&gt; and adds it to the VVS with the issuer's intention.

   Transfer
      A transfer transaction is the action that rewrites the tuple of
      &lt;I, P, H&gt; (in VVS) as &lt;I, P, H'&gt; (H&lt;&gt;H') to reflect the original
      holder H's intention.

   Redemption
      There are two redemption transactions: presentation and
      consumption.

      A presentation transaction is the action that shows the tuple of
      &lt;I, P, H&gt; (in VVS) to reflect the holder H's intention.  In this
      case, the ownership of the voucher is retained when the voucher is
      redeemed, e.g., redemption (presentation) of licenses or
      passports.

      A consumption transaction is the action that deletes the tuple of
      &lt;I, P, H&gt; (in VVS) to reflect the holder H's intention and
      properties of the voucher.  The ownership of the voucher may be
      voided or the number of times it is valid reduced when the voucher
      is redeemed, e.g., redemption of event tickets or telephone cards.

   Note that one or more of these transactions can be executed as part
   of the same IOTP purchase transaction.  See details in <a href="#section-6">Section 6</a>.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. VTS Requirements</span>

   A VTS must meet the following requirements

   (1) It MUST handle diverse types of vouchers issued by different
       issuers.

   (2) It MUST prevent illegal acts such as alteration, forgery, and
       reproduction, and ensure privacy.

   (3) It MUST be practical in terms of implementation/operation cost
       and efficiency.

   Each of these requirements is discussed below in detail.





<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Capability of handling diversity</span>

   (a) Different issuers

   Unlike a digital cash system that handles only the currency issued by
   a specific issuer such as a central bank, the voucher trading system
   MUST handle vouchers issued by multiple issuers.

   (b) Various types of vouchers

   Unlike a digital cash system that only handles a currency, the system
   MUST handle various types of vouchers, such as gift certificates,
   coupons, and loyalty points.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Ensuring security</span>

   (c) Preventing forgery

   Only the issuer can cause a valid voucher to be issued.  It MUST NOT
   be possible for other parties to cause a valid voucher to be created.

   (d) Preventing alteration

   Voucher MUST NOT be altered during circulation except that the
   transfer transaction, in which the voucher holder is rewritten, is
   permitted.  Only the current holder can initiate a transfer
   transaction.

   (e) Preventing duplicate-redemption

   A voucher MUST NOT be redeemable once it has been consumed (the
   result of some redemption transactions).  Only the holder can
   initiate a redemption transaction.

   (f) Preventing reproduction

   Voucher MUST NOT be reproduced while in circulation.  That is, there
   must be only one valid holder of any particular voucher at any
   particular time.

   (g) Non-repudiation

   It SHOULD NOT be possible to the issuer to repudiate the issuance, or
   the holder to repudiate the transfer or redemption of a voucher,
   after it is issued, transferred or redeemed.






<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   (h) Ensuring privacy

   Current and previous holders of a voucher SHOULD be concealed from
   someone coming into possession of the voucher.

   (i) Trust manageability

   If a wide variety of vouchers are in circulation, it might be
   difficult for users to judge whether a voucher can be trusted or not.
   To assist such users, a trust management function that verifies the
   authenticity of a voucher SHOULD be supported.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Ensuring practicality</span>

   (j) Scalability

   A single centralized broker that sells all types of vouchers, or a
   centralized authority that authenticates all issuers or other
   participants, SHOULD NOT be assumed.  A system that relies on a
   single centralized organization is excessively frail; failure in that
   organization causes complete system failure.

   (k) Efficiency

   It MUST be possible to implement VTS efficiently.  Many applications
   of vouchers, e.g., event ticket or transport passes, require high
   performance, especially when the voucher is redeemed.

   (l) Simplicity

   It SHOULD be possible to implement VTS simply.  Simplicity is
   important to reduce the cost of implementation.  It is also important
   in understanding the system, which is necessary for trust in the
   system.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Scope of VTS Specifications</span>

   To implement a VTS, Voucher Trading Protocol (VTP), VTS Application
   Programming Interface (VTS-API), and Generic Voucher Language (GVL)
   must be developed.  The objectives, benefits, and limitations of
   standardization for each specification are discussed below.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Voucher Trading Protocol</span>

   To achieve interoperability among multiple VTSs developed by
   independent VTS Providers, standard protocols for issuing,
   transferring, or redeeming vouchers will be needed.  However, there
   are several ways of implementing VTS.  For discount coupons or event



<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   tickets, for example, the smart-card-based decentralized offline VTS
   is often preferred, whereas for bonds or securities, the centralized
   online VTS may be preferred.  It is impractical to define any
   standard protocol at this moment.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> VTS-API</span>

   To provide freedom in terms of VTS selection for issuers and
   application developers, a standard Voucher Trading System Application
   Programming Interface (VTS-API) that can encapsulate VTS
   implementations should be specified.  It allows a caller application
   to issue, transfer, and redeem voucher in a uniform manner
   independent of the VTS implementation.  Basic functions, i.e., issue,
   transfer, and redeem, provided by VTS-API can be straightforwardly
   derived from the VTS model described in this document.  More design
   details of the VTS-API will be discussed in a separate document or a
   separate VTS-API specification.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a> Generic Voucher Language</span>

   To satisfy the diverse requirements placed on VTS (see <a href="#section-3">Section 3</a>), a
   standard Generic Voucher Language (GVL) that realizes various voucher
   properties should be specified.  This approach ensures that VTS is
   application independent.  The language should be able to define
   diverse Promises P of the voucher &lt;I, P, H&gt; to cover tickets,
   coupons, loyalty points, and gift certificates uniformly.  Specifying
   I and H is a VTS implementation issue and can be achieved by using a
   public key, hash of a public key, URI or other names with scope rule.

   In the following section, we discuss GVL Requirements in detail.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. GVL Requirements</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a> Semantics</span>

   Semantics supported by the language and their requirements levels are
   described below in detail.

   (a) Validity control

   The invalidation (punching) method that is executed when the voucher
   is redeemed depends on the type of the voucher.  For example, a
   loyalty point will be invalidated if the point is redeemed but a
   membership card can be used repeatedly regardless of the number of
   times presented.  The language MUST be able to define how validity is
   modified.  Additionally, the language MUST be able to define the
   validity period, start date and end date.




<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   (b) Transferability control

   Some types of vouchers require transferability.  The language MUST be
   able to specify if a voucher can be transferred.

   (c) Circulation control

   Depending on the type of the voucher, various circulation
   requirements or restrictions must be satisfied [<a href="#ref-F99" title="&quot;Digital-Ticket-Controlled Digital Ticket Circulation&quot;">F99</a>], for example,
   only qualified shops can issue particular vouchers or only a certain
   service provider can punch (invalidate) particular vouchers.  The
   language SHOULD be able to specify such circulation requirements.

   (d) Anonymity control

   Different types of voucher will require different levels of
   anonymity.  The language SHOULD be able to achieve the required level
   of anonymity.

   (e) Understandability

   The terms and description of a voucher SHOULD be objectively
   understood by the participants, because this will contribute to
   reducing the number of disputes on the interpretation of the vouchers
   promised.

   (f) State manageability

   Some types of vouchers have properties the values of which may change
   dynamically while in circulation, e.g., payment status, reservation
   status, or approval status.  The language MAY support the definition
   of such properties.

   (g) Composability

   Some types of vouchers consist of several sub-vouchers, which may be
   issued separately from the original vouchers typically because the
   vouchers are issued by different organizations or issued at different
   times.  The language MAY support compound vouchers composed of
   multiple sub-vouchers.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a> Syntax</span>

   To achieve consistency with other related standards shown below, the
   syntax of the language MUST be based on XML [<a href="#ref-XML" title="&quot;Extensible Mark Up Language (XML) 1.0 (Second Edition)&quot;">XML</a>].






<span class="grey">Fujimura &amp; Eastlake          Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   The language syntax MUST enable any application-specific property,
   e.g., seat number, flight number, etc. to be defined.  A schema
   definition language that can be translated into application-specific
   DTDs may be needed.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a> Security</span>

   The language MUST provide the parameters necessary to establish
   security.  Security requirements, however, mainly follow VTS
   requirements described in <a href="#section-3">Section 3</a> rather than GVL requirements.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a> Efficiency</span>

   The vouchers may be stored in a smart card or PDA with a restricted
   amount of memory.  Large definitions may incur long transfer and
   processing times, which may not be acceptable.  The language SHOULD
   enable the efficient definition of vouchers

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a> Coordination</span>

   The language specification SHOULD be consistent with the following
   specifications:

      (1)  Internet Open Trading Protocol v1.0 [<a href="#ref-IOTP" title="&quot;The Internet Open Trading Protocol&quot;">IOTP</a>]
      (2)  XML-Signature [<a href="#ref-XMLDSIG" title="&quot;XML-Signature Syntax and Processing&quot;">XMLDSIG</a>]
      (3)  Extensible Markup Language (XML) Recommendation [<a href="#ref-XML" title="&quot;Extensible Mark Up Language (XML) 1.0 (Second Edition)&quot;">XML</a>]
      (4)  ECML Version 2 [<a href="#ref-ECML">ECML</a>]

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a> Example of GVL</span>

   An example of a voucher definition in GVL is described below.  This
   example defines a five dollar discount coupon for specific
   merchandise, a book with ISBN number 0071355014.  This coupon is
   circulated using a VTS called "Voucher Exchanger".  To claim this
   offer, one coupon must be spent.  The coupon is valid from April 1st
   in 2001 to March 31st in 2002.

   &lt;?xml version="1.0"?&gt;
   &lt;Voucher xmlns="urn:ietf:params:xml:schema:vts-lang"
            xmlns:vts="http://www.example.com/vts"&gt;
     &lt;Title&gt;IOTP Book Coupon&lt;/Title&gt;
     &lt;Description&gt;$5 off IOTP Book&lt;/Description&gt;
     &lt;Provider name="Voucher Exchanger"&gt;
       &lt;vts:Version&gt;VE2.31&lt;/vts:Version&gt;
     &lt;/Provider&gt;
     &lt;Value type="discount" spend="1"&gt;
       &lt;Fixed amount="5" currency="USD"/&gt;
     &lt;/Value&gt;



<span class="grey">Fujimura &amp; Eastlake          Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


     &lt;Merchandise&gt;
       &lt;bk:Book xmlns:bk="http://www.example.com/bk"
                bk:isbn="0071355014"/&gt;
     &lt;/Merchandise&gt;
     &lt;ValidPeriod start="2001-04-01" end="2002-03-31"/&gt;
   &lt;/Voucher&gt;

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Application Scenarios</span>

   This section describes, as a typical electronic commerce example
   involving advertisement, payment, and delivery transactions, the use
   of vouchers and VTS, and shows that vouchers can be used as an
   effective way to coordinate autonomous services that have not yet
   established trust among each other.

   Figure 2 shows a typical electronic commerce example of a consumer
   searching for goods or services and making a purchase:

                                                      ----------
         -------------------------------------------&gt;| Ad       |
        |      (1) Acquire a coupon                  | Agency   |
        |                                             ----------
        |
        |      (2) Send payment information           ----------
        |    ---------------------------------------&gt;| Payment  |
        |   |      Acquire a gift certificate        | Handler  |
        |   |                                         ----------
        v   v  (3) Transfer the coupon &amp;
    ----------     gift certificate                   ----------
   | Consumer |&lt;------------------------------------&gt;| Merchant |
    ----------     Acquire an exchange ticket &amp;       ----------
        ^          loyalty points
        |
        |      (4) Transfer the exchange ticket       ----------
         -------------------------------------------&gt;| Deliverer|
                   Supply goods or services          | Handler  |
                                                      ----------

                Figure 2.  Application example of vouchers

   (1) Use a search engine to find the desired goods or services and
       acquire a coupon from an ad agency that represents the right to
       purchase the goods or services at a discounted price.

   (2) Acquire a gift certificate from a payment handler in exchange for
       cash or payment information.





<span class="grey">Fujimura &amp; Eastlake          Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   (3) Transfer the coupon and gift certificate to the merchant, and in
       exchange acquire an exchange ticket and loyalty points.

   (4) Transfer the exchange ticket to the deliverer handler and receive
       the goods or services.

   In this example, the coupon, gift certificate, and exchange ticket
   each represent the media that yields the above four transactions.

   Note that it is not necessary to trust the participants involved in
   the transactions, but to trust the vouchers themselves.  In other
   words, there is no need to exchange contracts among the participants
   beforehand if the vouchers themselves are trusted.

   Take the exchange ticket as an example; even if the delivery handler
   does not trust the consumer, the merchant that issued the exchange
   ticket is trusted, and if the VTS guarantees that there is no
   duplication in the trading process of the exchange ticket, there is
   no problem in swapping the exchange ticket for the goods or services.
   In the same way, even if the merchant does not trust the delivery
   handler, the issuance of the exchange ticket can be verified, and if
   the VTS guarantees that there is no duplication in the trading
   process of the exchange ticket, there is no problem in swapping the
   exchange ticket for the goods or services (Fig. 3).  In other words,
   if there is trust in the issuer and the VTS, trust among the
   participants involved in the transactions is not required.

                      Exchange             Exchange
          ----------  ticket   ----------  ticket   ----------
         | Consumer |--------&gt;| Delivery |--------&gt;| Merchant |
         |          |&lt;--------| Handler  |&lt;--------|          |
          ----------  Goods or ----------  Goods or ----------
                      services             services

           Figure 3. Coordination of untrusted participants
                              using exchange ticket

   In general, it is more difficult to trust individuals than companies,
   so this characteristic of VTS is especially important.

   Moreover, the transactions involving vouchers have desirable features
   with respect to privacy protection.  For example, in the above
   exchange ticket scenario, the consumer can designate the delivery
   service for himself, so the merchant does not even need to know any
   personal information such as the delivery address.  Furthermore, by
   designating a convenience store etc. as the receiving point, the
   delivery service does not need to know the address of the consumer.




<span class="grey">Fujimura &amp; Eastlake          Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Q &amp; A</span>

   - Is it possible to implement a VTS using digital certificates?

      If transferability is not required, a voucher can be easily
      implemented as a digital certificate, i.e., Signed_I(I, P, H),
      where the phrase "Signed_I" means that the entire block is signed
      by the issuer's digital signature.  If transferability is
      required, then H is changed during the transfer, i.e., the
      signature is broken. Additionally, online data base checking or
      tamper-resistant devices are required to prevent duplicate-
      redemption.

   - What is the difference from digital-cash?

      VTS must handle various types of vouchers, such as gift
      certificates, coupons, or loyalty points unlike a digital cash
      system which handles only currency.  Additionally, vouchers are
      issued by different issuers.

   - Is it possible to support "digital property rights?

      Digital property rights can be represented as a voucher and can be
      traded using VTS.  However, some protected rendering system would
      be required to regenerate the digital contents securely in order
      to support digital property rights.  These requirements are out of
      scope of VTS.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>

   Security issues are discussed in <a href="#section-3.2">Section 3.2</a> and 5.3.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>

   I would like to thank Masayuki Terada and Perry E. Metzger, for their
   valuable comments.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>

   [<a id="ref-ECML">ECML</a>]    ECML Version 2, Work in Progress.

   [<a id="ref-F99">F99</a>]     K. Fujimura, H. Kuno, M. Terada, K. Matsuyama, Y. Mizuno,
             and J.  Sekine, "Digital-Ticket-Controlled Digital Ticket
             Circulation", 8th USENIX Security Symposium, August 1999.

   [<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.




<span class="grey">Fujimura &amp; Eastlake          Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


   [<a id="ref-IOTP">IOTP</a>]    Burdett, D., "The Internet Open Trading Protocol", <a href="./rfc2801">RFC</a>
             <a href="./rfc2801">2801</a>, April 2000.

   [<a id="ref-MF99">MF99</a>]    K. Matsuyama and K. Fujimura, "Distributed Digital-Ticket
             Management for Rights Trading System", 1st ACM Conferences
             on Electronic Commerce, November 1999.

   [<a id="ref-T00">T00</a>]     M. Terada, H. Kuno, M. Hanadate, and K. Fujimura, "Copy
             Prevention Scheme for Rights Trading Infrastructure", 4th
             Smart Card Research and Advanced Application Conference
             (CARDIS 2000), September 2000.

   [<a id="ref-XML">XML</a>]     "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
             W3C Recommendation, &lt;<a href="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</a>&gt;, October
             2000.

   [<a id="ref-XMLDSIG">XMLDSIG</a>] "XML-Signature Syntax and Processing", A W3C Proposed
             Recommendation, &lt;<a href="http://www.w3.org/TR/xmldsig-core">http://www.w3.org/TR/xmldsig-core</a>&gt;, August
             2001.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Authors' Addresses</span>

   Ko Fujimura
   NTT Corporation
   1-1 Hikari-no-oka
   Yokosuka-shi
   Kanagawa, 239-0847 JAPAN

   Phone: +81-(0)468-59-3814
   Fax:   +81-(0)468-59-8329
   EMail: fujimura@isl.ntt.co.jp


   Donald E. Eastlake 3rd
   Motorola
   155 Beaver Street
   Milford, MA 01757 USA

   Phone:  +1-508-851-8280
   EMail:  Donald.Eastlake@motorola.com











<span class="grey">Fujimura &amp; Eastlake          Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3506">RFC 3506</a>              Voucher Trading System (VTS)            March 2003</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  Full Copyright Statement</span>

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Fujimura &amp; Eastlake          Informational                     [Page 15]
</pre>