Theft deterrence protocol

NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... Please leave suggestions on the talk page.

This is a basic antitheft client/server protocol for FRS. It is expected that this protocol is temporary to a degree: we expect to have a more featureful management system at some point in the future. The primary goal of this protocol is to deploy something "good enough for now" that will allow us to upgrade to a revised featureful protocol at a later date, with the benefit of some experience with the upgrade system. At various points in the discussion below, we will flag features which are expected to be deprecated, replaced, or fleshed out later.

Antitheft client request

The antitheft client (OATC) will send periodically send requests to the canonical antitheft server. It is recommended that OATC send a request if (antitheft lease expiration time + time of last request) / 2 is earlier than the current time. This guarantees an server outage must last longer than (lease time / 2) in order to effect clients.

The client requests and responses are standard HTTP/1.1 in order to allow them to pass unmolested through the greatest varienty of (stateful) firewalls, NATs, and proxies.

The client request is:

POST /antitheft/request HTTP/1.1
Host: antitheft.laptop.org
Authorization: OLPC-hashcash <hashcash>
Content-Type: application/x-www-form-urlencoded  

<form contents>

The 'Authorization' line is optional, but may trigger a 401 response if omitted. The response will have the following form.

 HTTP/1.1 401 Hashcash required.
 WWW-Authenticate: <oatc-bits> <oatc-nonce>

The authorization line mitigates DoS attacks. The '<hashcash>' element should be a version 1 hashcash stamp with the resource string equal to <oatc-nonce> and the bits field greater than or equal to <oatc-bits>.

If required, the hashcash should be checked before the form contents are accepted. A limited-size buffer may be used for the first recv on the stream to enforce this, so extra headers (or re-ordered headers) should be avoided.

The form contents are encoded according to their content type. The fields are:

serialnum

the serial number of the laptop

version

the URI identifying the currently-running version on the laptop (or hash?)

stream

an opaque string identifying the "upgrade stream" to which the user has subscribed themself. Note that future upgrade servers may ignore this field in favor of central management

nonce

delegated

a hint -- see the delegation response for more information