Internet Draft NTT draft-ietf-trade-drt-requirements-00.txt February 2000 Expires: August 2000 Ko Fujimura Requirements for Digital-Right Trading 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 "digital-right", which is a digital representation of the right to claim goods or services. This document contains the requirements in the following areas: - The digital rights trading model - The language to describe diverse types of digital rights Ko Fujimura [Page 1]
Internet Draft Requirements for Digital-Right Trading February 2000 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]. Table of Contents Status of this Memo ................................................1 Abstract ...........................................................1 1. Background .....................................................2 2. Terminology and Model ...........................................3 2.1 Digital-right ................................................3 2.2 Participants .................................................3 2.3 Digital-right trading system .................................4 3. General requirements on DRTS ....................................5 3.1 Capability to handle diversity ...............................5 3.2 Ensuring security ............................................5 3.3 Ensuring practicality ........................................6 4. Requirements on DRDL ............................................6 4.1 Semantics ....................................................6 4.2 Syntax .......................................................7 4.3 Security .....................................................7 4.4 Efficiency ...................................................7 4.5 Coordination .................................................7 5. Requirements on DRTP ............................................8 6. Q & A ...........................................................8 7. Security Considerations .........................................8 8. Acknowledgments .................................................8 9. References ......................................................8 10. Author's Address ................................................9 1. Background It is common necessity to credit loyalty points, collect digital coupons or gift certificates, etc, within purchases or other trading transactions in the real world. The importance of these activities is also becoming 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 digital-right is a digital representation of the right to claim the services or goods. Using the concept of a "digital-right", a wide-range of electronic-values including points or coupons can be handled in a uniform manner using the one trading software module. Ko Fujimura [Page 2]
Internet Draft Requirements for Digital-Right Trading February 2000 This document presents the terminology, digital-right trading model, general requirements on Digital Right Trading System (DRTS), and the detail requirements of the Digital-Right Definition Language (DRDL), in which diverse types of rights can be described. Along with the Digital-Right Trading Protocol (DRTP), it enables companies or individuals to freely issue, transfer, and redeem various types of digital rights via the Internet using a specification- compliant DRTS. This document does not include protocol-related requirements, which will be presented in a separate document. 2. Terminology and Model 2.1 Digital-right A digital-right is a digital representation of the right to claim the services or goods. To clarify the difference between digital-right and digital money/digital certificates, we introduce a formal definition of digital-right in this document. Let I be a digital-right issuer, H be a digital-right holder, P be the issuer's promise to the digital-right holder. A digital-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 download 20 image files in the server "ftp://...". (Coupon ticket) o Seat number A-24 has been reserved for "a-concert" on April 2. (Event ticket) 2.2 Participants There are three types of participants in the digital-right trading model: issuer, holder, and collector. Their roles are as follows: Issuer: Creates and issues a digital-right Holder: Transfers and redeems the digital-right Collector (or examiner): Collects the digital-right Ko Fujimura [Page 3]
Internet Draft Requirements for Digital-Right Trading February 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 digital-right her/himself or purchases it from a wholesaler or manufacturer. A shop can also be a collector if the merchant collects gift certificate or coupons. 2.3 Digital-right trading system A digital-right trading system is a system that logically manages a set of digital-rights RS ={<I1, P1, H1>,..., <In, Pn, Hn>} (*1) and protects them from being modified or reproduced except as results from the following three transactions: issue, transfer, and redemption: (*1) Note that this does not imply that RS is stored physically in a centralized database. For example, an implementation may store them in distributed smart cards carried by each holder, 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 <Ii, Pi, Hi> and adds it in the RS with the issuer's intention. Transfer: A transfer transaction is the action that rewrites the tuple of <Ii, Pi, Hi> (in RS) as <Ii, Pi, Hj> (i<>j) to reflect the holder Hi 's intention. Redemption: There are two types of redemption transaction: presentation and consumption. A presentation transaction is the action that shows the tuple of <Ii, Pi, Hi > (in RS) to reflect the holder Hi 's intention. In this case, the ownership of the digital-right is retained when the digital-right is redeemed, e.g., redemption of licenses or passports. A consumption transaction is the action that deletes the tuple of <Ii, Pi, Hi> (in RS) to reflect the holder Hi 's intention. The ownership of the digital-right may be voided or the number of times it is valid is reduced when the digital-right is redeemed, e.g., redemption of event tickets or telephone cards. Note that one or more issue, transfer, and redemption transaction(s) can be executed as part of the one IOTP purchase transaction. Ko Fujimura [Page 4]
Internet Draft Requirements for Digital-Right Trading February 2000 3. General requirements on DRTS A digital right trading system 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 alternation, 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 to handle 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 digital-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 Digital-right MUST not be counterfeited. Only the issuer can initiate an issue transaction. (d) Preventing alteration Digital-right MUST not be altered during circulation except for the transfer transaction in which the digital-right holder is rewritten. Only the holder can initiate a transfer transaction. (e) Preventing duplicate-redemption Digital-right MUST not be redeemable once it has been consumed (as the result of a redemption transaction). Only the holder can initiate a redemption transaction. (f) Preventing reproduction Digital-right MUST not be reproduced while in circulation. (g) Non-repudiation It SHOULD not be possible to repudiate the issuance, transfer, or redemption of a digital-right when it is transferred or sold. (h) Ensuring privacy Current and previous ownership of digital-right SHOULD be concealed. Ko Fujimura [Page 5]
Internet Draft Requirements for Digital-Right Trading February 2000 (i) Trust manageability If diverse types of digital-rights are put into circulation, it would be difficult for users to judge whether a digital-right can be trusted or not. To support such a judgment, a trust management system that automatically verifies the trust of digital-right SHOULD be supported. 3.3 Ensuring practicality (j) Scalability No centralized broker who sells all types of digital-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 DRTS efficiently. Many applications of digital-rights, e.g., event ticket or transport passes, require high performance, especially when the digital-right is redeemed. (l) Simplicity It SHOULD be possible to implement DRTS 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. Requirements on DRDL To satisfy the diverse requirements placed on DRTS (see above), we believe that a digital-right definition language that realizes various digital-right properties should be introduced. This approach makes DRTS application independent. In this section, we mainly discuss how Promise P of the digital-right <I, P, H> can be defined in DRDL. 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 1 Validity control: Depending on the type of the digital-right, the invalidation (collecting) method that is executed when the digital-right is redeemed may differ. 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. 2 Transferability control: Some types of digital-rights require transferability. The language MUST be able to specify if a digital-right can be transferred. Ko Fujimura [Page 6]
Internet Draft Requirements for Digital-Right Trading February 2000 3 Circulation control: Depending on the type of the digital-right, various circulation requirements or restrictions must be satisfied while in circulation [F99], for example, only qualified shops can issue particular digital-rights or only a certain service provider can invalidate (collect) particular digital-rights. The language SHOULD be able to specify such circulation requirements. 4 Anonymity control: Different types of digital-right will require different levels of anonymity. The language SHOULD be able to control the required level of anonymity. 5 Understandability: The terms and description of a digital-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. 6 State manageability: Some types of digital-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. 7 Composability: Some types of digital-rights consist of several sub-rights, which may be issued separately from the original rights typically because the digital-rights are issued by different organizations or issued at different times. The language MAY support compound digital rights comprised of multiple sub-rights. 4.2 Syntax 1 To achieve consistency with other related standards shown below, the syntax of the language MUST be based on XML. 2 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 1 The language MUST provide the parameters necessary to establish security. Security requirements, however, mainly follow DRTS requirements described in Section 3 rather than DRDL requirements. 4.4 Efficiency 1 The digital-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 MUST enable the efficient definition of digital-rights. 4.5 Coordination 1 The language specification SHOULD be consistent with the following specifications: a Internet Open Trading Protocol v1.0 [IOTP] b XML-Signature [XMLDSIG] Ko Fujimura [Page 7]
Internet Draft Requirements for Digital-Right Trading February 2000 c Extensible Markup Language (XML) Recommendation [XML] 5. Requirements on DRTP Requirements for the digital-right trading protocol (DRTP) will be discussed in a separate document or future version of this paper. 6. Q & A - Is it possible to implement a DRTS using digital certificates? If transferability is not required, a digital-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 are changed during the transfer, i.e., the signature is broken. Additionally, online DB checking is required to prevent duplicate- redemption. - What is the difference from digital-cash? DRTS must handle various types of rights, such as gift certificates, coupons, or loyalty points unlike a digital cash system that handles only currency. Additionally, digital-rights are issued by different issuers. - Is it possible to ensure digital "property" rights? It is possible, since digital property rights can be considered as a kind of digital-right. DRTS, however, would need to be extended by adding some protected rendering system that would regenerate the original works securely. 7. Security Considerations Security issues are discussed in Section 3.2 and 4.3. 8. Acknowledgments T.B.S. 9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IOTP] The Internet Open Trading Protocol, David Burdett et al. See RFCxxx. This document is currently in the RFC editor queue. Also see http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0- protocol-07.txt. Ko Fujimura [Page 8]
Internet Draft Requirements for Digital-Right Trading February 2000 [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. [MF99] K. Matsuyama and K. Fujimura, "Distributed Digital-Ticket Management for Rights Trading System", 1st ACM Conferences on Electronic Commerce, November 1999. [XML] Extensible Mark Up Language, A W3C recommendation, http://www.w3.org/TR/REC-xml. [XMLDSIG] XML-Signature Core Syntax and Processing, A W3C Working Draft, http://www.w3.org/TR/xmldsig-core/. 10. 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-8329 Email: fujimura@isl.ntt.co.jp Ko Fujimura [Page 9]
