Requirements

Issuer

Core

Accounting

1. Register an identifier.
2. Mailbox facility that returns messages to owner.
3. Under each identifier, many subaccounts in named items.
4. A subaccount includes a list that references transactions.
5. A transaction is an item/value/data tuple between two accounts.
6. Each transaction will optionally generate signed receipts for the mailbox.

Coin DB

1. Takes a string.
2. Attempts to store it.
3. Store succeeds if not present, otherwise fails.
4. Returns results - success or fail.
5. Once stored, the strings stay stored. i.e., checkpoints and logs.
6. Should be as fast as network access.
7. Interface can handle batches of coins, with all or nothing and return good and bad individually.

Crypto Server

1. API delivers these services:
   1. Return signature S on packet P with signing key K (where K implies the signature algorithm used).
   2. Return signature S on hash H. (Might be same as above.)
   3. Check signature S on packet P.
   4. Authenticate signature S on hash H. (Might be same as above.)
   5. Encrypt number N with Public Key K1
   6. Decrypt number N with Private Key K2
   7. Generate random number (session key).
2. The API is idempotent for signature operations - that is a packet P that is passed for signing twice should return the same S.
3. The server may cache packets and signatures for a short period of time (e.g. hours).
4. The server may provide logging and diagnostics, more as a debugging aid; there is no audit need.

Note that the remote server must be protected from unathorised access. This is not the job of the server, but of the whole system architecture and a higher layer protocol.

Does Kerberos provide a framework for this?

Note that the authentication API does not cover symmetric ciphers as these are fast.

Identity DB

It must be reliable...

Protocols

1. Confidentiality
2. Integrity
3. Authentication
4. Nonrepudiation by client (signature on transfer)
5. Carriage of (SOX) signed transfers
6. Protocol element for registration. This step may include
   • Negotiation of session CIA.
   • Negotiation of paramaters.
   • Issuer time syncronisation.
7. Protocol element(s) for value movement.
8. Protocol element for collection of mail.
9. Carriage of other instruments such as tokens with bearer. This implies that some or all of the protocol elements include multiple dialogues - implying state. For example, Coin withdrawal is a 3 part protocol.

Wallets

Storage

1. private keys,
2. receipts (for SOX),
3. tokens (for token systems).

General

DB

SOX

Clients

E-Gold System

1. There are multiple Reserve Institutions.
2. E-gold can be atomically transferred by users between Reserve Institutions as well.
3. Reserve Institutions should be legally distinct entities, geographically and jurisdictionally distributed.
4. Reserve Institutions must be auditable by to ensure successful execution of contractual obligations to holders of E-Gold.

Issuer

1. manage value based on Ricardian contracts. A Ricardian contract is a contract that is identified by the hash of a signed, formatted file that includes all technical and business details of the contract.
2. A CMCF can take deposits? but is this the same as the issuance of own debt?
3. A CMCF can make loans.
4. A CMCF can securitize the issue of small borrowers.
5. A CMCF must be able to create multiple currencies, preferably on the fly.
6. Must be capable of publishing the complete balance sheet for a currency.

DigiGold

1. negotiable,
2. branded (as DigiGold),
3. fractionally reserved,
4. redeemable in e-gold,
5. redeemable according to contract,
6. suitable audited for redemption performance,
7. unit of account is oz-e-gold,
8. may be cleared through third party CMCFs,
9. meant to be used as a currency,
10. should not be defradable. This means probably accounts are not temperable by the CMCF (tamper-resistant hardware or distributed).

Transactions

DigiGold X

1. Provide non-repudiable receipts,
2. checkable by at least a TTP or the client,
3. atomic, and therefore idempotent and cancellable,

E-gold X

1. push - in that the payer must initiate,
2. payer must authenticate,
3. transactions are not roll-backable,
4. and therefore, authentications must be strong.
5. available both to humans and programs (web and API interfaces),
6. accounting supports transactions costs and other statistical methods (e.g. balance).
7. capable of being costless for designated accounts and/or transactions.

1. Provide non-repudiable receipts,
2. checkable by at least a TTP or the client,
3. atomic, and therefore idempotent and cancellable,

CMCF X

deposit of DigiGold and E-gold. This is standard accounts.

The User

The Purchasing Application

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) is required to make a DigiGold payment.
4. no particular requirement to allow the identification of the payer, 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...

The DigiGold Wallet

1. balance in any given unit of account,
2. consolidated asset value,
3. history of digigold transactions may be provided,
4. There must be at least one wallet choice that keeps history, and one choice that does not, (either options or distinct software),
5. Uses Ricardian contracts.
6. Open Software.
7. CMCF is only required to live up to
8. Wallet must take appropriate security measures to ensure protection of assets and records. (Appropriate is implementor-dependant.)
9. Wallet may request authentication of some form from client.
10. Wallet needs to provide stream output and input for export and import of values.

The Client

1. balance in individual contracts.
2. shields the user from differences between similarly-backed instruments where possible.
3. consolidated asset value in groups of assets and combined assets.
4. history of digigold transactions may be provided,
5. Must provide choice of history on or off. (I.e., stores audit trail on or off.)
6. Should include:
   • some authentication method.
7. Should be capable of handling multiple wallets.
8. Raw application included in all clients is export and import of value in ascii data message.

Auditing

1. Size of Reserves held at E-Gold.
2. Quantity of issued certificates against those reserves.

Redemption

1. There must be a separate method of DigiGold-to-E-Gold redemption.

Random