At Home with John and Debbie

v. 0.2 - Draft 2
v. 0.3 - Draft 3 - 2004-06-15 - Clarified purpose of friendly names. Lots of bold type.
v. 0.4 - Moved into Wordpress. Minor updates for 2009. How to Read.  2009-07-12

Background

In 2003 demand for tickets to the Glastonbury festival, combined with the selling power of Internet auction sites, resulted in tickets being resold at vast prices, and a general feeling that genuine customers had missed out on tickets because of bulk buying by touts.

Organisers made clear their opinion that resold tickets worked to the detriment of the festival: making tickets unattainable by the less well off, and benefitting touts instead of the charitable beneficiaries supported by the festival.

In 2004 an attempt was made to prevent the bulk buying and reselling of tickets through a variety of measures:

• No more than two ticket purchases were allowed per customer
  address
• Each ticket was issued to a named individual
• Identification was to be verified at the gate

In the weeks running up to the festival, a great deal of consternation was evident among festivalgoers:

• Some received tickets printed with erroneous personal details
• Some objected to, or could not provide the stated ID
  requirements, having no bank account, passport or driving license
• Others observed that valid forms of ID (such as bank statement)
  could easily be forged, or given by a tout to a buyer.

For 2007, a preregistration scheme was initiated. This scheme provides for photo ID printed on tickets. Privacy concerns persist. A lost ticket can prevent someone who has paid from being able to enter the festival.

This document proposes a scheme by which non-transferrable tickets may be sold and verified, without the flaws of the 2004 or 2007 scheme. The scheme is not only applicable to music festivals, and could be used for
any event where high demand and low availability encourages unwanted ticket touting.

How to read this document

Although the scheme is simple, it can sometimes be difficult to see the wood for the trees, if you start from the beginning and see all the details. You may prefer to start with the “Scenarios” section towards the end, to see how the scheme would appear to a customer, before reading from the beginning to get the full details.

Or, if you just want to leap right into the nitty gritty, just keep reading.

Requirements

For the scheme to succeed, it must achieve all of these aims:

1. Each ticket sold must be assigned to a specific individual at time of purchase
2. It must be impossible to transfer a ticket to another individual at any time after purchase
3. Information collected about individuals must be kept to an absolute minimum
4. Requirements for proof of identity must be such that as many people as possible can easily provide
   them
5. A ticket holder must be able to obtain a refund, allowing the organisation to sell their access to the event to another buyer
6. The process must be visibly fair to the buying public
7. The process must not make assumptions about the buyer’s status - e.g. customers may not have access to the Internet, have a bank account, etc.
8. The process must be cheap to implement

Scope

This proposal addresses only the requirements stated above. It does not concern itself with the problem of large-volume sales of a scarce commodity — a situation also experienced by Glastonbury
Festival organisers in 2004 and in all subsequent years, which led to severely overloaded Web and telephone sales systems.

(N.B. I believe that the loads experienced by the Glastonbury ticket booking Web Site in 2004 were entirely predictable, and I further believe that building a service to handle such a load is entirely achievable. The organisation that manages this will be able to boast that they sold 100,000 tickets in 5 minutes. — but I have drifted outside the scope of this document).

However, these issues were never far from the author’s mind, and it is believed that the proposal presents no aspects that would stand in the way of improving the sales experience for customers.

Proposal

Pre-Registration

Pre-registration provides an opportunity for potential customers to supply a reliable means to verify their identity: a photograph of their face.

Prior to tickets becoming available for sale, potential buyers are given the opportunity to pre-register. Pre-registration services are provided at no charge (costs will be covered by ticket sales).

Pre-registration entails submitting a passport-style photograph and a friendly name to a database. In exchange, the customer is given a customer number.

The friendly name is merely a label that may be used by the customer to recognise their number later on: for example a first name (”John”), or a nickname (”Smiler”). The friendly name is only for the convenience of the
customer, since it will later be used as a way to distinguish between tickets without referring to hard-to-read customer numbers. For this reason, friendly names are not required to be unique, nor are they required to match any “real world” identification.

Pre-registration services may potentially be offered in a number of concurrent ways:

• Via the World-Wide Web.
  It is envisaged that this would be the most popular method. Users upload a picture using their Web browser, and are provided with a customer number instantly
  • Note that although requirement 7 states that we must not assume Internet access, the vast majority of people can use the Web in some way even if not in their home — e.g. using a cybercafe, library etc.
• Using the postal service.
  A customer sends their photograph and a stamped, self addressed envelope. An agency scans the picture, submits it to the database, and sends a customer number back in the self-addressed envelope.
  • It is envisaged that very few customers would choose to use this method, however it must be available in order to meet requirement 7.
• At local shops.
  Record shops or ticket shops may choose to provide pre-registration services to visitors, either for a nominal fee or as a way to lure customers into their establishment. This would involve little more than capturing an image from a digital camera then operating the Web site on the customer’s behalf.

For each pre-registered customer, the organisers store only:

• A digital photograph
• A customer number
• A friendly name

Notably, details such as real name, address, birthday, bank details etc. are not required.

Pre-registration need not be performed by the person identified.  A person buying tickets as a gift may pre-register the intended recipient of the gift, as long as they have a photograph of that person.

Pre-registration does not commit the customer to any purchase, nor does it provide any guarantee that the pre-registered individual will get a ticket. There is no limit on the number of pre-registrations.

Once created, a pre-registration record cannot be revised or deleted. If a customer decides they would prefer a different photograph, for example, they must pre-register again, and will be given a new customer number.

The customer number is created by the system, and is unique to each preregistration. Because it may be dictated over the phone, typed or written into forms, or miscommunicated in other ways, it should be created in such a way as to be algorithmically verifiable. Credit card-style “check digits“ provide a means to do this.

To defend against tampering with the database, the customer number is partially constructed from a cryptographic hash of the photograph in its final stored form (i.e. after any resizing or compressing that may
be performed). The entire database, or individual records may therefore be checked for tampering at any time. Note that any recompressing or other processing of photographs after the pre-registration phase would have the effect of losing this ability to verify the database.

Ticket Ordering

Tickets may be ordered by various means — e.g. Internet, phone, ticket office: the precise mechanics of the ordering process are beyond the scope of this document.

At the point of purchase, as well as the normal information required to buy a ticket (means of payment, delivery address etc.), the buyer must supply a customer number for each ticket bought, on the explicit understanding that the ticket is intended for the person who’s photograph is tied to that number. 

Tickets may not be bought without a customer number. It is the buyer’s responsibility to
provide correct customer numbers. Although customer number check digits are verified at this point (to protect against mis-transcribed numbers), the seller does not verify the buyer using their photograph at this point. Indeed the buyer does not need to be an eventual ticketholder — tickets may be bought as gifts, for example.

Each ticket order has a ticket number. Hence at the end of the ticket sale process, the event organisers have a database containing tuples: ticket number, customer number, photograph.

Notable features of the system include:

• The process is amenable to distributed delivery: blocks of tickets may be allocated to agencies without compromising security
• There is a requirement for validating that each customer number provided corresponds to a genuine pre-registration.
  • Validation may be performed asynchronously (orders are checked at some time after sale, customers are contacted to correct errors). This would suit a sales interface where synchronous checking would have a derogatory effect on capacity.
  • Alternatively, validation may be performed synchronously (customer numbers would be checked at time of sale, invalid orders are not accepted). This would suit a sales environment where capacity was not an issue.
  • In either case, this is not a check that the customer number matches a specific person, merely that any photograph is registered to the customer number

Cancellation

At any point prior to the event (or some arbitrarily decided deadline), a buyer may cancel their ticket. At this point their ticket number is marked invalid, the customer’s money is refunded, and a new ticket number is made available for sale.

Ticket Provision

This system requires only that each ticket bears a ticket number. There is no requirement for expensive
fraud prevention measures on tickets. Tickets may be supplied as tangible paper slips, but the system is equally amenable to “e-tickets” wherein the customer is provided a number to print or write down.

If printed tickets are used, there is no requirement to print the ticketholder’s photograph on each ticket (this would violate requirement 8: cheap implementation). It may increase efficiency at the event gate if printed tickets are supplied with ticket numbers in machine readable format e.g. a barcode.

Whether physical tickets or e-tickets are provided, the friendly name of the ticketholder is used as a means for customers to conveniently allocate tickets in a group booking scenario. This is the only purpose of friendly names. If a group booking contains duplicate friendly names, the customer must correctly allocate the tickets using the customer number instead.

Event Entry

It is at the event gates that ticketholders are validated against their pre-registered photographs.

Each gate requires a computer with the ability to display the approporiate photograph when presented with a ticket number. This may be acheived using a network connection to a central database, or by copying the entire database to each machine. Depending on circumstances, the device used could be a desktop computer, a portable computer or a handheld device.

The ticketholder presents their ticket at the gate. The ticket number is entered or scanned into the computer, and the corresponding photograph is displayed. If the ticketholder bears a reasonable likeness to the photograph, they are admitted to the event.

Ticket numbers may be ‘ticked off’ to prevent multiple admissions to lookalikes using the same ticket number. This would provide a disincentive to people sharing their ticket number - only the first person to use it would gain admission. Alternatively a lightweight paper ticket could be used alongside this scheme.

Scenarios

Scenario 1

Anne and Ben plan to attend the event together. Anne has access to the Internet and photographs of herself and Ben on her computer.  Several months before tickets go on sale, Anne visits the pre-registration Web site, and uploads both pictures using her Web browser. Along with each picture, Anne provides friendly names: “Anne” and “Anne’s fella”, which Anne finds amusing. In return she gets two customer numbers: 08396666 and 02135336.

When the tickets go on sale, Anne again uses her Web browser. The order form requests that she enter a customer number for each ticket ordered. Anne also provides a delivery address for the tickets, and pays for the transaction using a Visa card.

Some time later, Anne and Ben’s tickets arrive by post. Each is printed with a ticket number. Anne’s ticket is printed with her friendly name: “Anne”, and Ben’s ticket is printed with “Anne’s fella”. This amuses Anne no end.

On the day of the event, Anne and Ben take their tickets to the gate. The staff member at the gate processes each ticket, verifies that Anne and Ben resemble the pictures that appear on the screen, and admits them to the venue.

Scenario 2

Catherine does not have access to a computer and does not have a bank account. She knows she would like to attend the event, so she gets a passport photograph taken in a Post Office photo booth, and sends it along with a stamped self-addressed envelope to the pre-registration service. She writes her friendly name on the back of the photograph: “Katy”.

A week later Catherine’s self-addressed envelope comes back to her, containing a slip of paper reading:

Thank you for pre-registering for our ticket sale. Your friendly name is “Katy” and your customer number is “63610894″.

When tickets go on sale, Catherine calls her friend Dan, who she knows is buying tickets, and asks him to buy hers too. “I’ll pay you back when my wages come. You’ll need my customer number though: it’s 63610894″.

Dan orders a number of tickets over the phone, including Catherines. For each ticket he orders, he is asked for a customer number.

Some time later, the tickets arrive. Dan meets Catherine and gives her the ticket marked “Katy”.

On the day of the event, Catherine’s ticket is processed just as Anne and Ben’s were in scenario 1, and she is allowed into the festival.

Scenario 3

Evan notices that tickets for the event are going to be in high demand, so he plans to buy several tickets and sell them on eBay for a profit.  He reads in the press about the pre-registration scheme, and pre-registers several times, planning to revise the pictures when he resells the tickets.

Evan buys a number of tickets from an agency, providing a customer number for each one.

Before placing his advert on eBay, Evan investigates the process for changing the photograph on a pre-registration. He is disappointed to discover that no such process exists. Evan is left with no alternative
but to ask for a refund and cancel his tickets.

Implementation Considerations

An adequate colour JPEG head and shoulders image is approximately 12 KB in size.  120,000 such files (Glastonbury’s current ticket capacity) would take approximately 1.4 Gigabytes - easily fitting onto even the
smallest capacity hard drives and memory cards on the consumer market today. Other stored information specified in this proposal is of insignificant size.

A typical commercial Web hosting service would be able to supply adequate performance and capacity for pre-registration.

It should be made clear to customers that there is no advantage in racing to pre-register early, in order to spread the load over a sensible period. The web hosting services already used by the organisation may well already be suitable for the task.

Agencies / shops performing pre-registrations would require no more than a low-spec PC with
an Internet connection and a low-spec digital camera, estimated total price £300. A dedicated machine would
not be required and many establishments would already own a suitable machine.

At 2009 prices, a £100 handheld device at each gate would be sufficient.

Feedback

Please email feedback and questions to john.hartnup@gmail.com. I hope to address any objections and clarify anything that doesn’t make sense in future revisions of this document.

© John Hartnup 2004, 2009 - The author permits anyone to implement the ideas in this document without restriction.