Requirements for the Client software

Wallets

Types

1. SOX2
2. DBS

• E-gold
• ecash
• DBS-Y

Storage

The storage of DBS tokens and SOX receipts must be atomic and reliable. It is not clear how to do this in Java yet, but that does not change the requirement!

The requirement might be met by either of the following:

• by having secure atomic storage onto the local disk, or
• by replicating data over the net on virtual drives.

Basic Actions

1. Management ownership entities (accounts) with the following sub-actions:
   • Create new
   • Read existing
   • Close and transfer all value.
2. Creation of payment and clearance of payment. The Wallet and Applications should facilitate the re-spending of any transaction as a test of the system (this requirement also derives from licensing conditions).
3. Import / Export of text-format value.
4. Display of sub accounts: completed and pending transfers, and in and out transfers (this applies to all wallets).
5. Consolidated balance display.
6. Applications protocols.

Management of ownership entities

Presentation

Text Value transfer

Output

1. source account
2. target account (optional)
3. amount
4. item
5. expiry date (depends on wallet) (sensible default)

The payment should be converted to ASCII armour or MIME (preferably the latter?) and displayed on a cut&paste-enabled dialog.

The user is now instructed to C&P the message into an email (for example).

Input

An option in a similar place to the above output mechanism should pop up a C&P-enabled dialog. The user is instructed to paste the email (for example) into the dialog and click ok, etc.

The presentation layer then strips off the armouring or MIME, determines which wallet to send this message to, and calls the API for the wallet to process the message.

Messages

Sub Accounts

Consolidated Balance Display

A strong requirement is that the user is shielded from the minor differences in nominally simmilar assets. That is, the individual balances of two items in derivative e-gold should be consolidated into one balance on this current display. However, this consolidated balance should be obviously different from a pure, non-mixed balance. I.e., bold or italic or coloured.

Context within which Client operates

Value Context - Ricardian Contracts

• A text contract that includes details of the value relationship between the Issuer and the Holder of instruments.
• A signature in that contract that affirms the Issuer's good intentions.
• A message digest (hash) that identifies the contract uniquely.
• Details of servers and PKI, generally held in a separate file.

1. Read all current contracts held in the contract directory.
2. Make the contracts accessible, indexable on:
   • Hash - one contract returned per hash.
   • Common currency unit name (USD, NLG, EUR, etc). Many contracts returned by base currency unit.
   • All contracts - return list of hashs.
3. Add a new contract from a file or URL (later).
4. Check signatures on contracts, based on keys in PKI context
5. Display contracts in text form - contract browser - to user.
6. Display appropriate information on other displays. E.g., for a currency, the symbol ('$') is extracted and used as the balance symbol.

PKI Context

Specific PKI facilities needed:

1. Add public key to keyring.
2. Extract key according to key id.
3. Check signature on hash.
4. Generate canonical hash from document (Ricardian contract).

There is an assumption that X.509 should be used, and Diffie Hellman key exchange and ElGamal public keys should be used. RSA may be supported.

In practice this means that signatures are self-identifying, and the code can accept a signature of either type. It should generate signatures according to the specifications in the Ricardian contract or the SOX file.

Server Context

The location of the SOX file is identified in the Ricardian contract by a URL.

Later versions of the code should be able to handle multiple locations of the SOX file for replication purposes.

Environment and Conditions

• Many issuers.
• Many issues with each issuer.
• Issuers handling different protocols (wallets).
• Payment for zero - must be the same as a value payment.
• Payment to self - ditto.
• Negative balance - must handle maths correctly and not throw exceptions, etc.

The Applications

Purchasing

1. Only one class of user - Wallet must include both selling and purchasing halves.
2. can receive a payment and store it on safe storage in an automated fashion (this is the merchant-wallet).
3. no identifying information (of either party) is required to make a payment.
4. no particular requirement to allow the identification of the payer or the payee, but obviously a useful feature....
5. must be able to create a non-revocable payment.
6. shielded from the distinction between different contracts issued in the same unit of account...

Trading

Management

Platforms

• Servlet client providing interface over web.
• Standalone client on user PC
• Specialist client in dedicated NC-like box, where we control the configuration for security reasons.