Trade Working Group                                         Ko Fujimura
INTERNET-DRAFT                                                      NTT
Expires: June 2001                                        December 2000

               Requirements for Generic Rights Trading
             draft-ietf-trade-drt-requirements-01.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.  The IETF Trade Working Group is investigating how these 
activities can be generalized using the concept of a "electronic-
right", which is a digital representation of the right to claim goods 
or services. This document contains a rights trading model and the 
requirements for the following points:

- A rights trading system to circulate electronic-rights securely
- A language to describe diverse types of electronic-rights

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 Rights Trading    December 2000



Table of Contents

 Status of this Memo ................................................1
 Abstract ...........................................................1
 1. Background ......................................................2
 2. Terminology and Model ...........................................3
   2.1 Electronic-right .............................................3
   2.2 Participants .................................................3
   2.3 Rights trading system (RTS) ..................................4
 3. RTS Requirements ................................................5
   3.1 Capability to handle diversity ...............................5
   3.2 Ensuring security ............................................5
   3.3 Ensuring practicality ........................................6
 4. GRDL Requirements ...............................................6
   4.1 Semantics ....................................................6
   4.2 Syntax .......................................................7
   4.3 Security .....................................................7
   4.4 Efficiency ...................................................8
   4.5 Coordination .................................................8
 5. GRTP 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. An electronic-
right is a digital representation of the right to claim services or 
goods.  Using the concept of an electronic-right, 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, rights trading model, 
requirements on Rights Trading System (RTS) that circulate electronic-
rights securely, and Generic Rights Definition Language (GRDL), in 
which diverse types of rights can be described. 

Along with the Generic Rights Trading Protocol (GRTP), RTS enables 
companies or individuals to freely issue, transfer, and redeem various 
types of electronic-rights via the Internet. This document does not 

Ko Fujimura                                                    [Page 2]

INTERNET-DRAFT Requirements for Generic Rights Trading    December 2000


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

2. Terminology and Model

2.1 Electronic-right

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

   Let I be an electronic-right issuer, H be an electronic-right 
   holder, P be the issuer's promise to the electronic-right holder. 
   An electronic-right 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 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 rights 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 rights trading model: 
issuer, holder, collector, and RTS provider.  Their roles are as 
follows:

  Rights Issuer: Creates and issues an electronic-right. Guarantees 
    contents of the electronic-right.

  Rights Holder (or user): Owns the electronic-rights. Transfers and 
    redeems the electronic-right to other users or rights collector.

  Rights Collector (or examiner): Collects the electronic-right. In 
    general, compensated by goods or services rendered.

  RTS Provider: Provides an RTS and guarantees that there are no 
    duplicate assignments or multiple use of electronic-rights.


Ko Fujimura                                                    [Page 3]

INTERNET-DRAFT Requirements for Generic Rights Trading    December 2000


The IOTP model 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 electronic-right 
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 Rights Trading System (RTS)

An electronic-right 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 electronic-rights

The RTS provider provides an RTS that enables electronic-rights to be 
circulated among the participants securely. 

A formal definition of RTS is as follows:

  Definition: A rights trading system (RTS) is a system that logically 
    manages a set of valid electronic-rights RS, 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; 
    RTS prevents them from being modified or reproduced except where  
    for the following three transactions: issue, transfer, and 
    redemption. The initial state of the RS is an empty set.

Note that this does not imply that RS 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 RS with the issuer's intention.

  Transfer
    A transfer transaction is the action that rewrites the tuple of 
    <I, P, H> (in RS) 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 Rights Trading    December 2000


    <I, P, H> (in RS) to reflect the holder H's intention. In this 
    case, the ownership of the ticket is retained when the electronic-
    right is redeemed, e.g., redemption of licenses or passports.

    A consumption transaction is the action that deletes the tuple of 
    <I, P, H> (in RS) to reflect the holder H's intention. The 
    ownership of the electronic-right may be voided or the number of 
    times it is valid reduced when the ticket 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. RTS Requirements

An RTS must meet the following requirements

(1) It MUST handle diverse types of rights 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 
electronic-rights issued by different issuers.

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

3.2 Ensuring security

(c) Preventing forgery
Electronic-right MUST not be counterfeited. Only the issuer can 
initiate an issue transaction.

(d) Preventing alteration
Electronic-right MUST not be altered during circulation except for the 
transfer transaction in which the electronic-right holder is rewritten. 
Only the holder can initiate a transfer transaction.

(e) Preventing duplicate-redemption
Electronic-right 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 Rights Trading    December 2000



(f) Preventing reproduction
Electronic-right MUST not be reproduced while in circulation.

(g) Non-repudiation
It SHOULD not be possible to repudiate the issuance, transfer, or 
redemption of an electronic-right when it is transferred or sold.

(h) Ensuring privacy
Current and previous ownership of electronic-right SHOULD be concealed.

(i) Trust manageability
If diverse types of electronic-rights are put into circulation, it 
would be difficult for users to judge whether an electronic-right can 
be trusted or not. To support such a judgment, a trust management 
system that automatically verifies the trust of electronic-right 
SHOULD be supported.

3.3 Ensuring practicality

(j) Scalability
No centralized broker who sells all types of electronic-rights, or 
centralized authority that authenticates all issuers or other 
participants, SHOULD 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 RTS efficiently. Many applications of 
electronic-rights, e.g., event ticket or transport passes, require 
high performance, especially when the electronic-right is redeemed. 

(l) Simplicity
It SHOULD be possible to implement RTS 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. GRDL Requirements 

To satisfy the diverse requirements placed on RTS (see above), we 
believe that a Generic Rights Definition Language (GRDL) that realizes 
various electronic-right properties should be introduced. This 
approach ensures that RTS is application independent.
In this section, we mainly discuss how Promise P of the electronic-
right <I, P, H> can be defined in GRDL. 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 Rights Trading    December 2000


    executed when the electronic-right is redeemed depends on the 
    type of the electronic-right. 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 electronic-rights require 
    transferability. The language MUST be able to specify if an 
    electronic-right can be transferred.

(c) Circulation control: Depending on the type of the electronic-
    right, various circulation requirements or restrictions must be 
    satisfied while in circulation [F99], for example, only 
    qualified shops can issue particular electronic-rights or only a 
    certain service provider can punch (invalidate) particular 
    electronic-rights. The language SHOULD be able to specify such 
    circulation requirements.

(d) Anonymity control: Different types of electronic-right 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 an electronic-
    right SHOULD be objectively understood by the participants, 
    because this will contribute to reducing the number of disputes 
    on the interpretation of the rights promised.

(f) State manageability: Some types of electronic-rights 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 electronic-rights consist of 
    several sub-rights, which may be issued separately from the 
    original rights typically because the electronic-rights are 
    issued by different organizations or issued at different times. 
    The language MAY support compound electronic-rights comprised of 
    multiple sub-rights.

4.2 Syntax

(a) To achieve consistency with other related standards shown below, 
    the syntax of the language MUST be based on 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 Rights Trading    December 2000



(a) The language MUST provide the parameters necessary to establish 
    security. Security requirements, however, mainly follow RTS 
    requirements described in Section 3 rather than GRDL requirements.

4.4 Efficiency

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

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

Requirements for the Generic Rights Trading Protocol (GRTP) 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 electronic-rights and RTS, and shows that electronic-rights 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 Rights Trading    December 2000



                                                      ----------
         ------------------------------------------->| 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 electronic-rights

(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 electronic-rights themselves. In 
other words, there is no need to exchange contracts among the 
participants beforehand if the electronic-rights 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 RTS 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 RTS 

Ko Fujimura                                                    [Page 9]

INTERNET-DRAFT Requirements for Generic Rights Trading    December 2000


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 RTS, 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 RTS is especially effective. 

Moreover, the transactions involving electronic-rights 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 an RTS using digital certificates?

If transferability is not required, an electronic-right 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?

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

- Is it possible to ensure digital "property" rights?

Yes, since digital property rights can be considered as a kind of 
electronic-right. RTS, however, would need to be extended by adding 
some protected rendering system that would regenerate the original 

Ko Fujimura                                                   [Page 10]

INTERNET-DRAFT Requirements for Generic Rights Trading    December 2000


digital contents securely. 

8. Security Considerations

Security issues are discussed in Section 3.2 and 4.3.

9. Acknowledgments
   T.B.S.

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 Right Trading Infrastructure", 4th Smart Card 
Research and Advanced Application Conference (CARDIS 2000), September 
2000.

[XML] Extensible Mark Up Language (XML) 1.0, A W3C recommendation, 
http://www.w3.org/TR/REC-xml.

[XMLDSIG] XML-Signature Syntax and Processing, A W3C Candidate 
Recommendation, http://www.w3.org/TR/xmldsig-core/.

Author's Address

Ko Fujimura
NTT Corporation
1-1      Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN
Phone: +1-81-(0)468-59-3814
Fax:   +1-81-(0)468-59-2241
Email: fujimura@isl.ntt.co.jp







Ko Fujimura                                                   [Page 11]