Ko Fujimura, Yoshiaki Nakajima, and Jun Sekine
{fujimura, yoshiaki, sekine}@isl.ntt.co.jp
NTT Information Sharing Platform Laboratories
The World Wide Web provides an information delivery infrastructure for various types of digital contents used in daily life. Payment infrastructures such as digital cash, micropayments, and encrypted credit cards have also been established. However, no digital medium or infrastructure that prevents duplicate redemption and enables the trading of various rights, much like paper tickets, has been established yet. We are thus developing a generalized digital ticket system that can circulate any type of rights. A digital ticket is a digital medium that guarantees certain rights of the ticket owner and it includes software licenses, resource access tickets, event tickets, plane tickets, etc. To circulate various types of digital tickets using a common ticket processing system, we proposed a general-purpose digital ticket framework, in which a ticket is circulated by interpreting ticket properties such as anonymity, transferability, and the redemption method, specified in the ticket itself using the XML based Generalized Ticket Definition Language [2].
| Ticket types | Anonymity1 | Transferability1 | Redemption method supported1 | |
| Consume | Present | |||
| Event ticket | Yes | Yes | Only once | Yes |
| Plane ticket | No | No | Only once | Yes |
| Lottery ticket | Yes | No | Only once | - |
| Ticket for car wash | Yes | Yes | Only once | - |
| Telephone card | Yes | Yes | Specified times | - |
| Digital cash | Yes | Yes | Specified value | - |
| Software license | No | Yes | - | Yes |
| Transportation pass | Yes | No | - | Yes |
| Gate card | No | No | - | Yes |
| Driver's license | No | No | - | Yes |
Traditional digital ticket systems were developed for each application. However, we believe that a generalized digital ticket system is necessary for the following reasons:
This paper presents requirements of the Generalized Digital Ticket Definition Language and describes how these requirements are resolved by using XML or RDF. This paper also presents issues on XML digital signature uncovered when designing and implementing the digital ticket definition language in XML.
As a result of our investigation on diverse physical tickets, we identified the following requirements for the generalized digital ticket definition language:
We adopted XML as the base language of the Generalized Digital Ticket Definition Language, since we can satisfy the above requirements as described below.
A digital ticket (or ticket) is defined as an assertion that an issuer specified in <IssuerID> promises the ticket owner specified in <OwnerID> a promise specified in <Promise> with the digital signature specified in <Signature> as illustrated hereafter. Additionally, four properties, the ticket type identifier, ticket instance identifier, validity conditions, and image of the icon displayed in a ticket wallet, are specified by typeID, ticketID, <Validity>, and <View>, respectively. These properties are necessary for the ticket processing systems. Note that properties needed to control circulation are omitted in this example.
An event ticket example:
<SignedDescription>
<Ticket typeID="eventTicket" ticketID="001234">
<IssuerID fingerprint="..."/>
<OwnerID fingerprint="..."/>
<Validity>
<NumberOfTimes>ONCE</NumberOfTimes>
<ValidPeriod>2001-10-03</ValidPeriod>
</Validity>
<View resource="http://ticket.ntt.co.jp/ticket1.gif"/>
<Promise>
<Place>Boston Symphony Hall</Place>
<Seat>H24</Seat>
</Promise>
</Ticket>
<Signature>...</Signature>
</SignedDescription>
Although, no changes are allowed in a signed document, some tickets have properties in which values must be changed while in circulation, e.g., payment, reservation, or approval status. To allow these changes to occur securely, we introduce a technique called a restriction-specified incomplete link [2].
As shown in the following example, a restriction-specified incomplete link is defined in <Variable> that includes three sub-elements: <CurrentValue>, <NewValue>, and <Restriction>. The value of <Variable> is interpreted as the description located at the destination of the link specified in <NewValue> if the description is instantiated and satisfies the restriction specified in <Restriction>. Otherwise, the value of <Variable> is interpreted as the contents of <CurrentValue>, in which we state that a description is instantiated if the description is located at the destination.
In this example, a restriction-specified incomplete link is applied to the <OwnerID> property and its value is interpreted as (1st owner's id) if the description referred to as #001 is not attached, otherwise the value is interpreted as (2nd owner's id). In this example, three types of restrictions on the description to be attached are specified.
The ticket instance identifier is used to establish the relation between the property that is referred to and the referred description. The identifier should be generated by a hash or randomize function to be unique. A short identifier is used for readability in this example. Note that the ticket instance identifier is generated before the attached description is instantiated.
As shown in this example, any property can be changed as far as the original description allows in a generic and mechanical way. This technique can be applied to any XML signed document circulated in an enterprise or among enterprises as well as a digital ticket.
Original description:
<SignedDescription>
<Ticket typeID="eventTicket" ticketID="001234">
<IssuerID fingerprint="..."/>
<OwnerID>
<Variable> ;; Restriction specified incomplete link
<CurrentValue fingerprint=(1st owner id)/>
<NewValue resource="#001"/> ;; Incomplete link
<Restriction typeID="valueChange" ticketID="123456">
<IssuerID fingerprint=(1st owner id)/>
</Restriction>
</Variable>
</OwnerID>
<Validity>
<NumberOfTimes>ONCE</NumberOfTimes>
<ValidPeriod>2001-10-03</ValidPeriod>
</Validity>
<View resource="http://ticket.corp.com/ticket1.gif"/>
<Promise>...</Promise>
</Ticket>
<Signature>...</Signature>
</SignedDescription>
Attached description:
<SignedDescription ID="001">
<Ticket typeID="valueChange" ticketID="123456">
<IssuerID fingerprint=(1st owner id)/>
<Value>
<Variable>
<CurrentValue fingerprint=(2nd owner id)/>
<NewValue resource="#002"/> ;; Incomplete link
<Restriction typeID="valueChange" ticketID="884422">
<IssuerID fingerprint=(2nd owner id)/>
</Restriction>
</Variable>
</Value>
</Ticket>
<Signature>...</Signature>
</SignedDescription>
In this section, we summarize our proposals to be discussed at the workshop and present issues on the XML digital signature that were found in designing and implementing the XML Ticket.
We believe that the XML Ticket specification should be standardized in W3C to establish a digital medium that prevents duplicate redemption and that enables the trading of various rights similarly to paper tickets. Additionally, the ticket transfer protocols or other related specifications should also be standardized in the future.
Usually, the signature algorithm, digest algorithm, or other attributes of digital signatures are common within the tickets of the same ticket type. It is redundant to describe these static attributes in each ticket since specifying these attributes in the schema definition (or ticket type definition) can reduce the size of a ticket. It also reduces the data transfer time by distributing the schema definition in advance. We, therefore, believe that the XML signature specification should allow definition of these attributes on a digital signature in the XML schema definition [5].
If XML DSig does not support direct signature as proposed in Signed XML [1], a ticket should be defined in two separate parts, i.e., the package element to be signed and the signature element. This increases the overhead of description, e.g., the link between the separate parts, digest value, and their tags. The ratio of the overhead is not negligible for a small XML document such as a ticket, which can be defined in less than 1 KB. This makes it difficult to implement into applications in which tickets must be carried in a smartcard or in which high performance is required such as in the transportation field.
A X.509 based PKI forces the processing system to support ASN.1 encoded certificates. This makes the processing system more complicate and expensive. Public key certificates are also a type of signed document and can be described as a signed XML document. It is desirable to standardize XML based public key certificates. Public key certificates represent a type of a digital ticket as well, and we propose to use it as such. We will present details of this scheme in [3].