Introduction?
What is SOX?
SOX is a protocol that presents cryptographically secure capabilities from client to server. Each capability has to be designed into SOX, for maximum security. SOX is distributed normally with a payments capability. Trading and messaging extensions have also been perfected.
What SOX Doco is there?
More information on SOX accounts is found in the Issuer FAQ, and more on the SOX protocol itself on the SOX Page.
How does it work?
In a nutshell, SOX implements a device that can contain value and be securely passed around. Basically, that's all we ask of any payment system, but of course that simple description hides a wealth of complexity. We will first talk about the container of value, and then we will talk about moving the value around.
In a SOX system, there are two major individuals, the Issuer and the User. The User owns value and the Issuer assists by settling that value.
The User and the Issuer have a relationship that is based on a public and private key pair (here's a quick description of public key cryptography). For example, Alice (a User) generates the key pair, and registers it by sending the public key to Trent (her Issuer). Between the two of them, Alice can now move value around the system by using her secret key. Trent accepts her instructions because he can see that they were authorised by the holder of the private key.
This is Alice's SOX Account
Internally, we call the combined arrangement a SOX Account. At a user level, this is often described is often referred to as an account, but that's only an approximation.
How do I pay?
Let's ignore bootstrapping, and imagine that we are already flying. Alice and her account have lots of value. Alice can now send the account off to someone else, or can transfer some value to another person's account, or can write out an instruction and send that to another person. The SOX model is extremely flexible, and methods of transferring value can be tailored to requirements.
When Alice needs to pay a merchant, then it is likely that an instruction is the best method, and this is the method used by the WebFunds software.
In contrast, when off-line transactions take place, a direct transfer is more likely, and this is what the automated servers use, because this results in fewer problems in trying to contact Alice when she is not connected.
Alternatively, Alice can send a new account to Bob, her friend. This means that the transaction is more private, as the Issuer does not get directly involved, but it also means that Bob has no assurety that Alice has destroyed her copy of the account, so would have to roll it over into a new account regardless.
An alternate method would be to use a token money method. These methods are experimental only and are not discussed further here.
How Does SOX Work?
What is a SOX account?
SOX accounts are public key pair arrangements between client and servers that are capable of providing strong authentication. The arrangement is held jointly between the Issuance Server and the user's client application. These accounts are light-weight in that they can be created at will and disposed of when no longer needed.
In practice, WebFunds uses SOX to create an account:
- Client application creates a public key pair.
- Client registers the public key of the pair with a SOX server as a SOX account.
The only action available to a raw SOX account is to check for mail. The mailbox facility provides for a reliable server-to-client communications channel.
The most common form of SOX account is a Ricardo payments account, which adds a deposit request to the above, and an accounting model. This is often called a SOX account as well.
What is the Mailbox?
Each SOX account has a mailbox as an integral part of the SOX protocol.
Items in the mailbox such as receipts must be collected and signed for with SOX requests. In this way, packets are delivered securely to each account owner. Therefore all parties to the transaction hold the same data, a philosophy that reduces problems.
How does the Mail Work?
The mail request is one of the fundamental requests (register is another). For example you can have a SOX account that does not do payments (the ones registered at the Exchange are such as they do trading instead) but you cannot have a SOX account without a mailbox.
The sequence is as follows...
When the client launches a mail request, the mail in the mailbox is returned as a big array to the client.
The client deals with all the mail - securely. It is responsible for saving it securely on its hard drive, using normal database techniques. How it "deals with" the mail depends on the type of mail item - if it is a transaction receipt, then the receipt store gets updated and (maybe) the displayed account balance gets changed.
Then, when dealt with, the client creates a signature for each piece of mail that it has dealt with. It launches the mail request again but this time it includes the signatures for each piece of mail it has dealt with.
The server, when it receives a mail request that includes these signatures, will delete all mail that is signed for. It then goes on to find any mail that is left in the mail box and returns that.
So, there are two actions: get mail, and sign for mail. For optimisation reasons, these actions are wrapped into the same request, called simply a mail request. This way, the client is able to simply set up a loop that gets & signs & gets & signs...
There is no administrative need to monitor or look at the mailbox - proper client and server implementations will follow the protocol and deliver the mail securely.
If a piece of mail does not get delivered or signed for, then that is a bug. If this occurs regularly, then the account will fill up, and the SOX server should block the account until the bug is resolved.
If someone were to fiddle with the client - always possible - and refuse to "sign for mail" then that is also a bug. Again, the SOX Server should flag a warning or block the account or some such.
The design of the mailbox part is no afterthought. Mail is a critical piece of the SOX protocol, it is the secure backchannel to the (remote and disconnected) user. As part of our requirements are to securely deliver a receipt to the user (derived from the high level requirement of the user and server sharing the same data) then we must have a secure back channel. As the protocol is fundamentally a pull or request model (that is aligned to the unreliability of the net) we must implement the mailbox over that model.
How Does Ricardo Work?
The Ricardo Accounting Model
The Ricardian Contract, above, identifies the form of asset, and the contract itself is identified by a canonical message digest (or, hash, for short).
The Ricardo accounting model extends the basic SOX cryptographic relatiobship to create a value account held jointly between the (SOX) Issuance Server and the user's client application.
What is a sub-account?
In each account is a single sub-account available for each asset - each Ricardian Contract. Within Webfunds, any contract can be added to an account if WebFunds has the contract in its ContractBrowser.
Within each sub-account is a set of transactions, transferring value from one account to another. The existance of a transaction is evidenced by a receipt that contains a valid request signed by the payer, and is in turn signed by the Issuance Server.
There are no balances stored in the core Ricardo system. Following accounting principles, the receipt is evidence of the transaction, so for a balance display, the software simply counts up the amounts of the transactions, on demand.
Transfers
A transfer occurs between two SOX accounts. The WebFunds client has the ability to create a payment that can be either deposited immediately, or sent to another party.
Consider a payment written by Alice, and intended for Bob. When that Bob receives the payment, he can deposit it via his WebFunds client. WebFunds wraps the payment into a Deposit Request and sends that to the Issuance Server.
The Issuance Server will check the payment for correctness, including the following:
- signed by payer,
- corecctly targetted to payee,
- sufficient funds in account of payer,
- not expired,
- etc, etc.
Once validated, the Issuance Server will issue the transaction in the form of a signed receipt. That receipt will be returned back to the depositor, Bob, directly, and will also be placed into the mailbox of both payee and payer, Alice and Bob.
How are the Receipts Delivered?
Receipts must be collected and signed for with SOX requests, just like anything delivered via the mailbox. In this way, receipts are delivered securely to each account owner, and a shared database of receipts is achieved. Therefore all parties to the transaction hold the same data, a philosophy that reduces problems.
When Bob deposits a payment to Alice, above, he can sign for the receipt immediately, as he already has it from his deposit reply. For Alice, she must request any new mail, extract and save the receipt securely in her account, and then sign for it so that the Issuance Server can take it out of the mailbox.