XML Ticket:
Generalized Digital Ticket Definition Language

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
1This depends on the specific ticket. This table only shows the tendency for the ticket types.
Table I. Properties of Specific Ticket Types

Traditional digital ticket systems were developed for each application. However, we believe that a generalized digital ticket system is necessary for the following reasons:

  1. A ticket processing system includes a ticketing system, ticket wallet, ticket examination system, and the implementation cost of these components becomes expensive if a system must be developed for each individual application. For example, it is impractical to develop an individual system for an application that issues only 20 tickets.
  2. It is desirable for users to manage various tickets using a common "ticket wallet" that provides a uniform and collected view as a real physical wallet, in which cash, credit cards, ID cards, and various tickets are stored together.
  3. New network businesses such as revocation, packaging, and safety deposit box services can be run if any ticket can be managed uniformly. If the format and protocols for digital ticket circulation depend on the ticket, it would be difficult to run these businesses successfully.

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.

Generalized Digital Ticket Definition Language


As a result of our investigation on diverse physical tickets, we identified the following requirements for the generalized digital ticket definition language:

The language must support a composite ticket that comprises multiple sub-tickets. There are many cases when a sub-ticket must be issued separately with the original ticket typically because the tickets are issued by different organizations or issued at different times.
State manageability
The language must support the defining of properties whose values dynamically change while in circulation, e.g., payment, reservation, or approval status. Note that it is difficult to allow these changes in a signed document.
The language must support the defining of the meaning of the ticket. If the service or task that a ticket guarantees is objectively understood by the buyer and seller before conducting a transaction, it will reduce the number of disputes resulting from misunderstanding of the meaning of the ticket.
The language must enable the efficient defining of a ticket, since it might be stored in a smartcard or other devices with restricted memory. Longer definitions also cause longer data transfer time, which might not be acceptable. For example, redemption of event tickets or transportation passes requires high performance.
Circulation controllability
The language must provide the parameters needed to allow flexible circulation control. As shown in Table I, the anonymity, transferability, and redemption method of the ticket must be specified in the ticket definition. Additionally, it is desirable to support more advanced requirements, e.g., tickets can be circulated within the registered members of a group or only qualified shops can issue tickets.
The language must provide the parameters needed to achieve security. The digital ticket system must support a facility for preventing duplicate redemption similar to a digital cash system. It requires an online currency checking system or tamper-proof devices such as a smartcard as well as digital signature technologies.

XML based approach

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 composite ticket can be defined using XML links. A composite ticket in which sub-tickets are distributed over the Internet can also be implemented easily. This facility is useful especially for tickets that are often revoked and when online checking is required.
State manageability
The state-transition properties of a ticket can be uniformly defined by attaching a value change ticket to the restriction-specified incomplete link, which we describe in the following section and in [2].
We can define the meaning of a ticket using RDF and RDF schemas, which are layered on XML. This will make searching for tickets over the Internet much easier.
By circulating the link to contents such as ticket images or contract details instead of defining the contents on the tickets themselves, the size of the ticket can be reduced. The link can also provide up-to-date information over the Internet. For example, an event ticket may include a link to the place where the event will be held after it was postponed due to rain or something else.
Circulation controllability & Security
XML is a generic language designed to describe any structured data and thus any parameters necessary to control ticket circulation can be defined. Establishing control parameters or security parameters, which are necessary to satisfy these requirements, do not significantly influence the language as a ticket processing system. Details regarding this issue will be presented in [3].

Digital Ticket Examples

Digital Ticket

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:

  <Ticket typeID="eventTicket" ticketID="001234">
    <IssuerID fingerprint="..."/>
    <OwnerID fingerprint="..."/>
    <View resource="http://ticket.ntt.co.jp/ticket1.gif"/>
      <Place>Boston Symphony Hall</Place>

Restriction-specified incomplete link

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.

  1. The ticket type identifier of the description must be "valueChange", which is a system-defined ticket type.
  2. The ticket instance identifier of the description must be "123456".
  3. The issuer of the description must be (1st owner's id).

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:

  <Ticket typeID="eventTicket" ticketID="001234">
    <IssuerID fingerprint="..."/>
      <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)/>
    <View resource="http://ticket.corp.com/ticket1.gif"/>

Attached description:

<SignedDescription ID="001">
  <Ticket typeID="valueChange" ticketID="123456">
    <IssuerID fingerprint=(1st owner id)/>
        <CurrentValue fingerprint=(2nd owner id)/>
        <NewValue resource="#002"/> ;; Incomplete link
        <Restriction typeID="valueChange" ticketID="884422">
          <IssuerID fingerprint=(2nd owner id)/>


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].


  1. R. D. Brown, "Digital Signatures for XML", IETF Internet Draft, January 1999.
  2. K. Fujimura and Y. Nakajima, "General-purpose Digital Ticket Framework", 3rd USENIX Workshop on Electronic Commerce, August 1998, pp. 177-186. http://www.usenix.org/publications/library/proceedings/ec98/fujimura.html
  3. K. Fujimura, Hiroshi Kuno, Masayuki Terada, Kazuo Matsuyama, Yasunao Mizuno and J. Sekine, "Digital Ticket Controlled Digital Ticket Circulation", to appear.
  4. Y. Nakajima and K. Fujimura, "The XML Ticket Specification", unpublished manuscripts.
  5. XML Schema Requirements, The World Wide Web Consortium, Note, February 1999, http://www.w3.org/TR/NOTE-xml-schema-req