The Ticket Service

We propose to provide a “ticket service”. Its job is to issue tickets, verify previously issued tickets, and record when tickets have been used. It has three entry points, all presumably available as URL’s:

1. GetTicketKit: this has no parameters, and returns a ticket kit.  A ticket kit contains a ticket and (optionally) a challenge.  A ticket is a short string (e.g. 256 bits), containing a sequence number, expiry time, and a secure hash of these. Think of it as a line of hex digits that you can pass around in an application-dependent fashion.. All outstanding tickets are known to the ticket server (identified by serial number).  A ticket kit can contain a challenge (or a link to one). There can be quite a variety of challenges (we either provide a choice, or the request specifies a desired form of challenge.)  Examples of suitable challenges include a Turing Test (as in Yahoo account creation) or a semi-hard function to compute (as in the original anti-spam proposal). The challenge isn’t tied to any particular future use of the ticket. In particular, it’s not tied to an email message or recipient.
   
   If the ticket kit contains a challenge, the caller must first produce a challenge solution (e.g. the word from Yahoo’s Turing Test, voice recognition of some low-grade audio, or the value of the semi-hard function). The caller must apply this response in order to validate the ticket.
   
   If the ticket kit does not contain a challenge, then the enclosed ticket is pre-validated.  This might happen if a previous ticket had been refunded (see below).
    
2. CancelTicket: the parameter is a ticket. The server verifies that the ticket is valid, timely and not previously canceled, and records the fact that it has been used, and returns “OK” to the caller.
    
3. RefundTicket: the parameter is a ticket.  The server validates the ticket and checks that it has been canceled, but not refunded.  If so, it marks the ticket as refunded and credits the party to whom it was issued.  The originator's next GetTicketKit operation will return a valid ticket that doesn't require a challenge.

We know how to implement such a server very efficiently. Think in terms of a single PC servicing 10K requests/second, limited only by its communication bandwidth. We would of course use some fault-tolerance technique to avoid single points of failure.

This service can now be used in a variety of scenarios, for example:

1. Account creation for entities like Hotmail, Ebay, or Yahoo
2. Robot prevention for things like surfing Ebay’s web pages.
3. Spam control.

There are several scenarios for spam control. Most naively, when someone new sends me email, my mail server stashes it away and sends a bounce containing a link to the ticket server. The sender receives the bounce, gets a ticket kit, solves the challenge, and sends the resulting ticket to my mail server, together with the ID of the relevant email message. My mail server takes the ticket, calls the ticket server to mark the ticket as having been used, and frees the email message into my inbox. I probably add the sender to a safe-list.

A more advanced user might acquire valid tickets ahead of time and include a ticket with each outgoing email message, to avoid the danger of a bounce message.

If such a service became popular, we could straightforwardly sell tickets for real money or by contractual agreement. This might be convenient for legitimate, large-scale mail senders.  However, the act of selling tickets conflicts to some extent with the ticket server's primary functionality of deterring spam.  Therefore, we have focused our attention on non-monetary schemes.

Undoubtedly, there would in due course be an issue about such a service being run by any one organization. This should be fixable in the usual way, by having a Ticket Server Federation. The end-user of a ticket would choose to trust some particular incarnation of the ticket server, but it would be fine if there were other ticket servers too. The (small number of) tickets servers would trust each other because of corporate contractual agreements. A user could get a ticket from any ticket server and send it to any end-user. The end-user sends the CancelTicket request to a server whom the user trusts, and that server forwards the request to the appropriate originating ticket server. There are of course some obvious optimizations of this flow, to avoid excessive message traffic.