SOX

SOX is a payment protocol that is implemented within WebFunds as a value manager. It consists of a request layer over an encryption layer. Requests go from client to server, and replies back from the server to the client.

Requests have these characteristics:

reliable - idempotent (repeatable and unique)
extensible - add your own
secure - employs CIA: Confidentiality, integrity, authentication

In its last active form, each request was signed by RSA and encrypted over AES-128 using SDP1.

Reading

Documentation is a little scattered. Here's some from the various Systemics' sources:

Overview is Gary Howland's original paper on the protocol. Whilst the concepts have changed little, this paper is in need of an update. SOX FAQ Is a collection of frequently asked questions from Systemics.

Executive Summary quickly describes the core features of the protocol.

Others

Capabilities

Jeroen van Gelderen asks whether SOX is capabilities done in hard-coded crypto? A serious analysis is needed to answer that question.

Capabilities by public Key Encryption by Jed Donnelley. Also see his "Internet capability model."

PKI / CAs

SOX employs no classical PKI architecture. Each key is generated on the client and then registered with the server. Authentication of the key to the server more or less happens when transactions occur, so the authentication is done peer-to-peer. This makes it like OpenPGP's web of trust concepts. Hypothetically, it could be tuned to use a CA like CAcert.org but in all likelihood we would have to add a layer or indirection so the PKI did not slow down the crypto.

Terms

Start with the Executive Summary, above. Here are some other terms not covered there.

account is primarily a public and private key pair created by the SOX Client. The private key is kept secret and the public key can be registered with the SOX Server, thus making the account the unit of authentication.

item is a SOX value identifier (byte array), literally, the field in the SOX payment or the SOX sub account that identifies value type. As far as the SOX protocol is concerned, this can be anything; as far as the current implementations goes, it is the identifier for a Ricardian contract.

subaccount is the unit of work. It sits at the intersection of the account and the item. In general, with a standard payments implementation, it might consist of the item, and a database relationship containing any receipts collected, and state of any pending transactions.

Note that most documentation assumes that SOX is used for a payments protocol; this is not necessarily a limitation, and SOX is also being used for at least one other application, being RTGS trading, which shares similar requirements to payments applications.

Also, see Design for some additional definitions for the whole space in which SOX is used.

Back to Index.