[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
Subject: Digital-Right Definition Language Requirements
As I talked at the Oslo meeting, I believe that a digital-rights
management facility will satisfy wide-range of the business requirements
on the IOTP transactions. In the purchase transaction, for example, many
merchants want to issue loyalty points and/or redeem digital coupon
for sales promotion. It also enables to provide flexible payment scheme,
e.g., pay per unit of time or pay in advance.
The below text is my first proposal for the Digital-Right Definition
Language Requirements. This is very early stage draft and any comments
are welcome.
HTML Version see:
http://info.isl.ntt.co.jp/flexticket/DRDL-requirements.html
Best regards,
Ko
-----------------------
Digital-Right Definition Language (DRDL) Requirements
Working Draft 1999-October-13
1. Introduction
This document presents the design principles, scope, and 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 the specification-compliant Digital-Right
Trading System (DRTS). This document includes the language-related requirements.
Protocol-related requirements will be presented in a separate document.
2. Definition of Digital-Right
A digital-right is a digital representation of the right to claim the services
or goods described in itself. A formal definition of digital-right is as
follows:
Let I be a digital-right issuer, O be a digital-right owner, P be
the issuer's promise to the digital-right owner, and V be the
validity that confirms whether it is valid. The digital-right is
defined as the 4-tuple of (I, P, O, V).
Note: A digital-right is generally required to provide integrity and
non-repudiability and these requirements can be achieved by
implementing it as a digital certificate, i.e., Signed_I(I, P, O, V),
where the phrase "Signed_I" means that the entire block is
signed by the issuer's digital signature. A digital-right, however,
can be transferred or punched, and then O or V are changed, i.e.,
the signature is broken. We, therefore, assume that the DRTS
provides a facility to manage owner and/or validity states for each
digital-right using an online validation checking system or tamper
resistant devices (for offline capability).
Examples of P are as follows:
- Two loyalty points are added to the card. If you collect 50 points, you'll
get one free. (Loyalty points)
- Take 10% off your total purchase by presenting this card. (Membership card)
- Take 50% off your total purchase with this coupon. (Coupon)
- The bearer can access "http://..."; for one month free. (Free ticket for
sales promotion)
- The bearer can download 20 image files in the server "ftp://...";. (Coupon
ticket)
- Seat number A-24 has been reserved for "a-concert" on April 2. (Event
ticket)
A digital-right is delivered by the following three principal transactions:
issue, transfer, and redemption:
Issue
An issue transaction is the action in which the issuer (or deliverer)
assigns the ownership of a digital-right to the consumer.
Transfer
A transfer transaction is the action in which the consumer (or deliverer)
transfers the ownership of the digital-right to another consumer.
Redemption
A redemption transaction is an action in which the consumer redeems all or
part of the digital-right to a service provider (or merchant when the
digital-right is used as a payment method); depending on the redemption
transaction and the digital-right, the digital-right may be invalidated or
the number of times it remains valid for may be reduced. Other more complex
schemes may be supported.
The issue, transfer, and redemption transaction can be done as a part of the
IOTP purchase transaction. [Detail mapping to IOTP model will be studied and
described.]
3. Scope of the specification
This specification must describe the following items:
1. Objective of the specification.
2. How a digital-right is defined:
a. Structure of the definition.
b. Contents of the digital-right, in other word, what the digital-right
promises.
- Basic properties, which must be defined regardless of the
application, e.g., issue date or valid period.
- Application properties, e.g., seat number or flight number. They
differ with the type of the right, and are beyond the scope of this
specification. However, "how" such application-specific properties
are defined, is within the scope of the specification.
c. Control information which is necessary to control the issue, transfer,
and redeem transactions, e.g., whether transfer is allowed or who can
redeem the digital-right.
3. The basic concept and model.
a. A digital-right delivery model, necessary to understand the
specification, should be described, although the detail delivery
protocols are beyond scope of the specification.
b. Trust model. It describes how digital-right can be trusted.
c. Relation to other specifications, e.g., IOTP or xmldsig.
4. Formal Grammar (BNF and DTD).
5. Examples of the definition.
4. Requirements
This section describes requirements on DRDL. Mandatory items are designated as
"must," optional items are designated by "may." Items that are optional but
recommended are designated as "should."
4.1 Semantics
1. Validity control: Depending on the type of the digital-right, the
invalidation (punching) method which executed when the digital-right is
redeemed is different. 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 and when validity is modified.
2. Transferability control: Some types of digital-rights require
transferability. The language should be able to specify if a digital-right
can be transferred.
3. 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.
4. Circulation control: Depending on the type of the digital-right, various
circulation requirements or restrictions must be satisfied while in
circulation, for example, only qualified shops can issue particular
digital-rights or only a certain service provider can punch (invalidate)
particular digital-rights. The language should be able to specify such
circulation requirements.
5. State manageability: Some types of digital-rights have properties the values
of which may be changed dynamically while in circulation, e.g., payment
status, reservation status, or approval status. The language may support the
definition of such properties.
6. Machine-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.
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 to define any application-specific
properties, e.g., seat number, flight number, etc. A schema definition
language that can be translated into application-specific DTDs may be
needed.
4.3 Security
1. The language should provide the parameters necessary to establish security.
This is true not only for digital signatures, but also for preventing
duplicate redemption; both of which are required for the digital rights
trading system.
2. 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.
The language may provide the parameters necessary to support such judgement.
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]
c. Extensible Markup Language (XML) Recommendation
d. ... [TBD]
5. References
[TBD]
o---------------------------------------------------------o
o Ko Fujimura Email: fujimura@isl.ntt.co.jp o
o---------------------------------------------------------o
o NTT Information Sharing Platform Labs, Security Project o
o 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN o
o Tel: +81-(0)468-59-3814 Fax: +81-(0)468-59-8329 o
o---------------------------------------------------------o
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
Powered by eList eXpress LLC