[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 3506

Trade Working Group                                         Ko Fujimura
INTERNET-DRAFT                                                      NTT
Expires: August 2001                                      February 2001

               Requirements for Generic Voucher Trading
              <draft-ietf-trade-drt-requirements-02.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://www.elistx.com/archives/ietf-trade.

Abstract

In purchase and other trading transactions, it is often required to
credit loyalty points, collect digital coupons or gift certificates,
and so on.  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 contains a voucher trading model
and the requirements for the following points:

- A voucher trading system to circulate vouchers securely
- A language to describe diverse types of vouchers

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

Ko Fujimura                                                    [Page 1]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001



Table of Contents

 Status of this Memo ................................................1
 Abstract ...........................................................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. GVL Requirements ................................................6
   4.1 Semantics ....................................................6
   4.2 Syntax .......................................................7
   4.3 Security .....................................................7
   4.4 Efficiency ...................................................8
   4.5 Coordination .................................................8
 5. VTP Requirements ................................................8
 6. Application Examples ............................................8
 7. Q & A ..........................................................10
 8. Security Considerations ........................................11
 9. Acknowledgments ................................................11
10. References .....................................................11
11. Author's Address ...............................................11

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, voucher trading model,
requirements on Voucher Trading System (VTS) that circulate vouchers
securely, and Generic Voucher Language (GVL), in which diverse
types of vouchers can be described.

Along with the Voucher Trading Protocol (VTP), VTS enables companies
or individuals to freely issue, transfer, and redeem various
types of vouchers via the Internet. This document does not

Ko Fujimura                                                    [Page 2]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001


include protocol-related requirements, which will be presented in a
separate document.

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.


Ko Fujimura                                                    [Page 3]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001


The IOTP model [IOTP] 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.

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:

  Definition: 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

Ko Fujimura                                                    [Page 4]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001


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

    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
    result of a redemption transaction). Only the holder can initiate a
    redemption transaction.

Ko Fujimura                                                    [Page 5]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001



(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 in understanding the system, which is necessary for
    people to trust the system.

4. GVL Requirements

To satisfy the diverse requirements placed on VTS (see above), we
believe that a Generic Voucher Language (GVL) that realizes various
voucher properties should be introduced. This approach ensures that
VTS is application independent.
In this section, we mainly discuss how Promise P of the voucher
<I, P, H> can be defined in GVL. Specifying I and H is an
implementation issue and can be achieved by using a public key, hash
of a public key, or other names with scope rule.

4.1 Semantics

(a) Validity control: The invalidation (punching) method that is

Ko Fujimura                                                    [Page 6]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001


    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.

(b) Transferability control: Some types of vouchers require
    transferability. The language MUST be able to specify if an
    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 control 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.

4.2 Syntax

(a) To achieve consistency with other related standards shown below,
    the syntax of the language MUST be based on XML [XML].
(b) 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.

4.3 Security

Ko Fujimura                                                    [Page 7]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001



(a) 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.

4.4 Efficiency

(a) 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 time, which may not be acceptable. The
    language SHOULD enable the efficient definition of vouchers

4.5 Coordination

(a) 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. VTP Requirements

Requirements for the Voucher Trading Protocol (VTP) will be
discussed in a separate document or future version of this document.

6. Application Examples

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:
















Ko Fujimura                                                    [Page 8]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001



                                                      ----------
         ------------------------------------------->| 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 media coordinating 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

Ko Fujimura                                                    [Page 9]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001


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 difficult to manage the trust of individuals rather
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?"

Digital property right can be represented as a voucher and it can
be traded using VTS.  However, some protected rendering system would
be required to regenerate the digital contents securely in order to

Ko Fujimura                                                   [Page 10]


INTERNET-DRAFT Requirements for Generic Voucher Trading    February 2001


support digital property rights. These requirements are out of scope
of VTS.

8. Security Considerations

Security issues are discussed in Section 3.2 and 4.3.

9. Acknowledgments

I would like to thank Masayuki Terada, for his 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", draft-ietf-xmldsig-
core-11.txt, in RFC Editor queue for publication as Proposed Standard.


Author's Address

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-2241
Email: fujimura@isl.ntt.co.jp

Ko Fujimura                                                   [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/