Digital ticket
From Wikipedia, the free encyclopedia
 |
This article needs additional citations for verification. Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (January 2007) |
 |
This article or section may contain original research or unverified claims. Please improve the article by adding references. See the talk page for details. (January 2007) |
 |
The tone or style of this article or section may not be appropriate for Wikipedia. Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions.(January 2007) |
Much like the online banking, digital tickets, which represent the digitalization of rights to claim goods or services, are becoming popular recently. In addition to original tickets, digital tickets are easier to be transported and managed. Moreover, they are likely to cost much less than the physical ones. However, due it's digital character, extra attention is needed on security, copyability and privacy issues for the digital ticket
Contents |
[edit] Definition
A digital ticket is a virtual instance of ticket, which need to satisfy the following properties: non-copyable, transferable and represents a certain value that could be redeemed. A more precise definition is given below.[1]
Let O be a ticket owner, I be a ticket issuer and P be a promise to the ticket owner. A ticket is defined as SignedI (I, P, O), where the phrase "SignedI" means that the entire block is signed by the issuer's digital signature.
[edit] Application examples
There are many examples for which digital tickets could be used, including the following:
- A flight ticket from Amsterdam to Edinburgh
- A concert ticket of Michael Jackson
- 3 months license of Norton 360
- A car's receipt
[edit] Criteria
A digital ticket must fulfill the following criteria:
- Secure (unable to alter or counterfeit)
- Portable (physical independence)
- Off-line capable
- Wide acceptability
In order to have the ticket generally accepted, some level of trust is needed.
- User-friendly
Besides the criteria mentioned above, there are still several features that should be concerned, such as anonomity, transferability and repetitive usability. In addition, another three requirements are also important for digital tickets, they are:
- Viewable
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.
- State manageable
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.
- (De)Composable
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.
[edit] Ticket methods
The life circle of a digital ticket looks like this: the ticket is first issued by the service provider or issuer. The ownership of a ticket may change after it was issued. This can be done by transferring the ticket. Both issuer and owner of ticket might view the status of the ticket. Finally, it should be redeemed by the current owner at the service provider.
[edit] 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:
- Issuer
- Promise (Details are defined in upper layers)
- Owner
- Transferability
- Number of times to be consumed
- Valid period
- View
- Issuer's signature on above
Layer 2
Ticket properties defined by each industry
Layer 3
Ticket properties defined by each issuing company or individual
[edit] Transfer
Depending on the purpose of the ticket, it can 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.
[edit] Redeem
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.
[edit] View
Whether the ticket could be viewed 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 redeeming. The view could be achieved by properly designed hardware.
[edit] Implementing the digital ticket
In order to make an implementation of the digital ticket system, a combination of two paradigms can be used. On one side there's the account-based system, which relies on central storage and network connections. On the other side there's the smartcard-based system, depending on decentralized storage to store and transfer the ticket.
[edit] Account-based system
In an account-based system for tickets the rights of the tickets are managed in accounts[2]. 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 big efforts that need to be done to store all the accounts for both the users and the service provider
[edit] 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.
[edit] 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.
[edit] 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.
[edit] Smart card-based system
In smart card-based systems, tickets are stored on a smart card and are being circulated around different smart cards, by putting two smart cards in a specific reader and complete the transaction. The smart card itself takes care of the calculations that need to be done for safe transferring.
[edit] Storage
As mentioned, the tickets are stored on the different smart cards. The smart cards can be provided by both the users and the service providers. The performance of the 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.
[edit] 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. Also this makes it hard for different service providers to share a smart card.
[edit] Prevention of duplicate redemption
The 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.
[edit] See also
[edit] References
- ^ Fujimura, Ko; Nakajima, Yoshiaki (1998). "General-purpose Digital Ticket Framework". Proceedings of the 3rd USENIX Workshop on Electronic Commerce: 177-186, USENIX.
- ^ Matsuyama, Kazuo; Fujimura, Ko (1999). "Distributed digital-ticket management for rights trading system". Proceedings of the 1st ACM conference on Electronic commerce: 110-118, Association for Computing Machinery.
