From: http://www.ietf.org/proceedings/00jul/I-D/trade-drt-requirements-00.txt
Requirements for Digital-Right Trading
ID: draft-ietf-trade-drt-requirements-00.txt
-----------------------------------------------------------------------
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 , which may
be joined by sending a message with subject "subscribe" to .
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 .
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 ={,..., } (*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 and adds it in the RS with the issuer's intention.
Transfer:
A transfer transaction is the action that rewrites the tuple of
(in RS) as (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
(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
(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
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]