Subject: Digital-Right Definition Language Requirements

From: Ko Fujimura <[email-masked]>
Date: Wed, 13 Oct 1999 21:07:08 +0900

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: [email-masked]  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: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]