Trade Working Group                                         Ko Fujimura
INTERNET-DRAFT                                                      NTT
Expires: July 2002                                         January 2002

        Requirements and Design for Voucher Trading System (VTS)
               <draft-ietf-trade-drt-requirements-03.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

   Distribution of this document is unlimited. Please send comments to
   the TRADE working group at <ietf-trade@lists.elistx.com>, which may
   be joined by sending a message with subject "subscribe" to <ietf-
   trade-request@lists.elistx.com>.

   Discussions of the TRADE working group are archived at
   http://lists.elistx.com/archives/ietf-trade/.

Abstract

   Functions common in purchasing and general trading transactions,
   include crediting loyalty points and collecting digital coupons or
   gift certificates.  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 the
   terminology of and a model for a Voucher Trading System (VTS) that
   circulates vouchers securely; 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 [RFC2119].


K. Fujimura                                                     [Page 1]


INTERNET-DRAFT            Voucher Trading System            January 2002

Table of Contents

   Status of this Memo ................................................1
   Abstract ...........................................................1
   Conventions used in this document ..................................1
   1. Background ......................................................2
   2. Terminology and Model ...........................................3
     2.1 Voucher ......................................................3
     2.2 Participants .................................................3
     2.3 Voucher Trading System (VTS) .................................4
   3. VTS Requirements ................................................5
     3.1 Capability to handle diversity ...............................5
     3.2 Ensuring security ............................................5
     3.3 Ensuring practicality ........................................6
   4. Scope of VTS Specifications .....................................6
     4.1 Voucher Trading Protocol .....................................7
     4.2 VTS-API ......................................................7
     4.3 Generic Voucher Language .....................................7
   5. GVL Requirements ................................................7
     5.1 Semantics ....................................................7
     5.2 Syntax .......................................................8
     5.3 Security .....................................................9
     5.4 Efficiency ...................................................9
     5.5 Coordination .................................................9
     5.6 Example of GVL ...............................................9
   6. Application Scenarios ...........................................9
   7. Q & A ..........................................................11
   8. Security Considerations ........................................12
   9. Acknowledgments ................................................12
  10. References .....................................................12
  11. Author's Address ...............................................12


1. Background

   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 too expensive, especially for small
   businesses. 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 the concept of a voucher, 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 VTS and the Generic Voucher Language
   (GVL), with which diverse types of vouchers can be described.

K. Fujimura                                                     [Page 2]


INTERNET-DRAFT            Voucher Trading System            January 2002

2. Terminology and Model

2.1 Voucher

   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 <I, P, H>.

   Examples of P are as follows:

     o Two loyalty points are added to the card. 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. (Coupon)
     o The bearer can access "http://..." for one month free. (Free
       ticket for sales promotion)
     o The bearer can exchange the ordered clothes with this ticket.
       (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.

2.2 Participants

   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.

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

   Collector (or examiner): Collects the voucher. In general,
     compensated by goods or services rendered.

   VTS Provider: Provides a VTS and guarantees that there are no
     duplicate assignments or multiple use of vouchers.

   The IOTP model [IOTP] includes merchant, deliverer, consumer and
   other participants. They take various roles in the settlement because


K. Fujimura                                                     [Page 3]


INTERNET-DRAFT            Voucher Trading System            January 2002

   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.

2.3 Voucher Trading System (VTS)

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

           <I, P, H>        <I, P, H'>         <I, P, H'>
   Issuer I --------> User H ---------> User H' ---------> Collector
            Issue            Transfer           Redemption

                   Figure 1. Life cycle of vouchers

   The VTS provider provides 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
     {<I, P, H> | 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 where
     for 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
     them in distributed smart cards carried by each holder [T00], or
     may store them in multiple servers managed by each issuer or
     trusted third parties. This is a trust policy and/or
     implementation issue [MF99].

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

     Transfer
       A transfer transaction is the action that rewrites the tuple of
       <I, P, H> (in VVS) as <I, P, H'> (H<>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
       <I, P, H> (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 of licenses or passports.

K. Fujimura                                                     [Page 4]


INTERNET-DRAFT            Voucher Trading System            January 2002

       A consumption transaction is the action that deletes the tuple
       of <I, P, H> (in VVS) to reflect the holder H's intention. 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 Section 6.

3. VTS Requirements

   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.

3.1 Capability of handling diversity

   (a) Different issuers

   Unlike a digital cash system that handles only the currency issued
   by a specific issuer such as a central bank, the system MUST handle
   the vouchers issued by different 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.

3.2 Ensuring security

   (c) Preventing forgery

   Voucher MUST NOT be counterfeited. Only the issuer can initiate an
   issue transaction.

   (d) Preventing alteration

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

   (e) Preventing duplicate-redemption

   Voucher MUST NOT be redeemable once it has been consumed (the


K. Fujimura                                                     [Page 5]


INTERNET-DRAFT            Voucher Trading System            January 2002

   result of a redemption transaction). Only the holder can initiate a
   redemption transaction.

   (f) Preventing reproduction

   Voucher MUST NOT be reproduced while in circulation.

   (g) Non-repudiation

   It SHOULD NOT be possible to repudiate the issuance, transfer,
   or redemption of a voucher when it is transferred or sold.

   (h) Ensuring privacy

   Current and previous ownership of voucher SHOULD be concealed.

   (i) Trust manageability

   If diverse types of vouchers are put into circulation, it would be
   difficult for users to judge whether a voucher can be trusted or
   not. To support such a judgment, a trust management system that
   automatically verifies the trust of voucher SHOULD be supported.

3.3 Ensuring practicality

   (j) Scalability

   A centralized broker who sells all types of vouchers, or
   centralized authority that authenticates all issuers or other
   participants, SHOULD NOT be assumed. A system that relies on a
   global, centralized organization is excessively frail; failure
   in the 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
   people to trust the system.

4. Scope of VTS Specifications

   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.


K. Fujimura                                                     [Page 6]


INTERNET-DRAFT            Voucher Trading System            January 2002

4.1 Voucher Trading Protocol

   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
   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.

4.2 VTS-API

   To provide freedom in terms of VTS selection for issuers and
   application developers, we believe that a standard Voucher Trading
   System Application Programming Interface (VTS-API) that can
   encapsulate any VTS implementation 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.

4.3 Generic Voucher Language

   To satisfy the diverse requirements placed on VTS (see Section 3), we
   believe that 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 Promise P of the voucher <I, P, H> 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, or other names with scope rule.

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

5. GVL Requirements

5.1 Semantics

   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.

K. Fujimura                                                     [Page 7]


INTERNET-DRAFT            Voucher Trading System            January 2002

   (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 while in circulation
   [F99], 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
   comprised of multiple sub-vouchers.

5.2 Syntax

   To achieve consistency with other related standards shown below,
   the syntax of the language MUST be based on XML [XML].

   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.



K. Fujimura                                                     [Page 8]


INTERNET-DRAFT            Voucher Trading System            January 2002

5.3 Security

   The language MUST provide the parameters necessary to establish
   security. Security requirements, however, mainly follow VTS
   requirements described in Section 3 rather than GVL requirements.

5.4 Efficiency

   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

5.5 Coordination

   The language specification SHOULD be consistent with the
   following specifications:

     (1) Internet Open Trading Protocol v1.0 [IOTP]
     (2) XML-Signature [XMLDSIG]
     (3) Extensible Markup Language (XML) Recommendation [XML]
     (4) ECML Version 2 [ECML]

5.6 Example of GVL

   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.

   <?xml version="1.0"?>
   <Voucher xmlns="http://www.ietf.org/rfc/rfcnnnn"
            xmlns:vts="http://www.example.com/vts">
     <Title>IOTP Book Coupon</Title>
     <Description>$5 off IOTP Book</Description>
     <Provider name="Voucher Exchanger">
       <vts:Version>VE2.31</vts:Version>
     </Provider>
     <Value type="discount" spend="1">
       <Fixed amount="5" currency="USD"/>
     </Value>
     <Merchandise>
       <bk:Book xmlns:bk="http://www.example.com/bk"
                bk:isbn="0071355014"/>
     </Merchandise>
     <ValidPeriod start="2001-04-01" end="2002-03-31"/>
   </Voucher>

6. Application Scenarios



K. Fujimura                                                     [Page 9]


INTERNET-DRAFT            Voucher Trading System            January 2002

   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:

                                                      ----------
         ------------------------------------------->| Ad       |
        |      (1) Acquire a coupon                  | Agency   |
        |                                             ----------
        |
        |      (2) Send payment information           ----------
        |    --------------------------------------->| Payment  |
        |   |      Acquire a gift certificate        | Handler  |
        |   |                                         ----------
        v   v  (3) Transfer the coupon &
    ----------     gift certificate                   ----------
   | Consumer |<------------------------------------>| Merchant |
    ----------     Acquire an exchange ticket &       ----------
        ^          loyalty points
        |
        |      (4) Transfer the exchange ticket       ----------
         ------------------------------------------->| 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.

   (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

K. Fujimura                                                    [Page 10]


INTERNET-DRAFT            Voucher Trading System            January 2002

   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 |-------->| Deliverer|-------->| Merchant |
     |          |<--------| Handler  |<--------|          |
      ----------  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 effective.

   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 by 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.

7. Q & A

 - 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 DB 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?"

K. Fujimura                                                    [Page 11]


INTERNET-DRAFT            Voucher Trading System            January 2002

   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.

8. Security Considerations

   Security issues are discussed in Section 3.2 and 5.3.

9. Acknowledgments

   I would like to thank Masayuki Terada and Perry E. Metzger, for their
   valuable comments. I would also like to thank all the active member
   of IETF Trade WG, especially Donald E. Eastlake 3rd, who is the chair
   of the WG, for his help and suggestions.

10. References

   [ECML] ECML Version 2, to appear.

   [F99] 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.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IOTP] D. Burdett, "The Internet Open Trading Protocol", RFC2801,
   April 2000.

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

   [T00] 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.

   [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A W3C
   Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.

   [XMLDSIG] "XML-Signature Syntax and Processing", A W3C Proposed
   Recommendation, <http://www.w3.org/TR/xmldsig-core>, August 2001.

11. Author's Address

   Ko Fujimura
   NTT Corporation
   1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN
   Phone: +81-(0)468-59-3814


K. Fujimura                                                    [Page 12]


INTERNET-DRAFT            Voucher Trading System            January 2002

   Fax:   +81-(0)468-59-2241
   Email: fujimura@isl.ntt.co.jp




















































K. Fujimura                                                    [Page 13]