Digital ticket

A digital ticket is a virtual instance of a ticket which represents the digitization of rights to claim goods or services.[1]

Criteria

A digital ticket must fulfill the following criteria:

In addition, another three requirements are also important for digital tickets, they are:

The terms and description of the service should be objectively understood by both the service provider and consumer or owner, so the value of the ticket can be determined. Moreover, this is an essential property to trace the digital ticket.
Tickets may also have a payment status, i.e., paid or unpaid, and/or reservation status, e.g., waiting list, reserved, or canceled. The status may be changed dynamically. In addition, the ticket ownership can be rewritten when the ticket is transferred. However, it is difficult to allow these changes while still guaranteeing security.
Combining two or more tickets is sometimes required to obtain a service or one ticket may comprise several parts. For example, a travel ticket can comprise an accommodation ticket and a plane ticket or a car rent ticket.

Besides the criteria mentioned above, there are still several features that should be concerned, such as anonymity, transferability and repetitive usability. [2]

Lifecycle

The ticket is first issued by the service provider or issuer. The ownership of a ticket may change after it was issued, by transferring the ticket. Either the issuer or owner of ticket might view the status of the ticket. Finally, it is redeemed by the current owner at the service provider.

Creation

From creator's point of view, each digital ticket has certain structure, this could be expressed in a multilayer architecture depicted as follows:

Layer 1

Common ticket properties that do not depend on the ticket type:

Layer 2

Ticket properties defined by each industry

Layer 3

Ticket properties defined by each issuing company or individual

[3]

Transfer

Depending on the purpose of the ticket, it may be transferred. During the transfer process, the ticket should be visible to both parties involved. After the transfer process is done, the ownership of ticket has changed. The history of transfer should be recorded in either the ticket itself or the central database.

View

Ability to view the ticket is important to both the service provider and the owner of the ticket. The owner needs to know what his ticket actually is and the service provider needs to verify the ticket during redemption. The view could be achieved by properly designed hardware.

Redemption

A digital ticket always has certain value that could be redeemed at service provider. Normally after redeeming, the ticket is cleaned. Some tickets work for a period, and will only be deleted after this period. In the special case when the ticket isn't given away after redeeming, it is called a pass.

Implementation

In order to make an implementation of the digital ticket system, a combination of two paradigms can be used. The first is the account-based system, which relies on central storage and network connections. The second is the smartcard-based system, which uses decentralized storage to store and transfer the ticket.

Account-based system

In an account-based system for tickets, the rights of the tickets are managed in accounts.[4] Ticket changes in accounts can be made by communicating with a so-called account manager through a network. The trust in these systems can be seen from the service provider's and user's perspective, in which the former generally manages the whole system. This leads to an imbalanced trust relationship. Two other disadvantages of these systems are the need for protection of accounts against malicious users and the relatively large efforts that need to be done to store all the accounts for both the users and the service provider.

Storage

Generally, the storage and maintaining tasks of the account are assigned to the service provider. This leads to costs and efforts on his side. In some cases these systems could be shared by different service providers, but a need to make general agreements remains. Since the service provider normally has full control over the accounts, tickets could be deleted or altered and after that refuse to fulfill the service the initial ticket stands for.

Authentication

Typically ID and password are used in account-based systems to authenticate a user. This does not prevent fraud by the service provider. Several digital-cash systems deal with this by having a secret key generated at the user's PC, which remains out of hands of the service provider. This, however, is not sufficient when tickets are redeemed at the real service provider.

Prevention of duplicate redemption

Since the account management is completely in control of the service providers, unwanted actions such as copying tickets can easily be detected and traced back by them.

Smart card-based system

In smart card-based systems, tickets are stored on a smart card and are circulated by putting two smart cards in a reader and completing the transaction. The smart card itself takes care of the calculations that need to be done for safe transferring.

Storage

Tickets are stored on the smart cards. The smart cards can be provided by both the users and the service providers. The performance of current smart cards is limited, which makes asynchronous trading difficult. Different service providers are likely to use different standards, which makes it mandatory to have a different smart cards for different kinds of tickets.It is very useful to passengers.

Authentication

A secret key can be implemented in the smart card, which makes it possible to carry the card around and redeem a ticket without using a network connection. When the service provider distributes and issues the private keys on these cards, fraud from malicious service providers is still an issue. This also makes it hard for different service providers to share a smart card.

Prevention of duplicate redemption

Storage is generally maintained by the service provider. The smart card needs to be protected against multiplication. However, if the system is broken security is completely lost.

See also

References

  1. ↑ Fujimura, Ko; Nakajima, Yoshiaki (1998). "General-purpose Digital Ticket Framework". Proceedings of the 3rd USENIX Workshop on Electronic Commerce. USENIX. pp. 177–186.
  2. ↑ Fujimura, Ko; Nakajima, Yoshiaki (1998). "General-purpose Digital Ticket Framework". Proceedings of the 3rd USENIX Workshop on Electronic Commerce. USENIX. pp. 177–186.
  3. ↑ Fujimura, Ko; Nakajima, Yoshiaki (1998). "General-purpose Digital Ticket Framework". Proceedings of the 3rd USENIX Workshop on Electronic Commerce. USENIX. pp. 177–186.
  4. ↑ Matsuyama, Kazuo; Fujimura, Ko (1999). "Distributed digital-ticket management for rights trading system". Proceedings of the 1st ACM conference on Electronic commerce. Association for Computing Machinery. pp. 110–118.

External links

This article is issued from Wikipedia - version of the Thursday, June 26, 2014. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.