Model for separation of duties in issuance of digital bearer certificates
also known as, the Systemics collaborative mint arrangement

This paper assumes the reader is familiar with digital bearer certificates (DBC), the history of such ventures as Digicash, Cybercash and Millicent, and more recently, metals-backed currencies such as GoldMoney and e-Gold.  Basically, a DBC is an encrypted and/or signed data file, that is a sort of warehouse receipt for some valuable thing such as currency or gold, the ownership of which is registered in an issuance server someplace.  Beyond that, there are a number of models by which DBCs are transferred (spent) from one party to another.

The model describes five roles, which form a generalized framework for the establishment of internal control over various risks to users of DBCs.  It is offered as a potential starting point for discussion of more rigorous regimes of internal control, capable of achieving robust digital cash within webs of trust both within central issuance servers and decentralized P2P communities of issuers.

This model disregards DBCs having no issuer, since data itself is meaningless without a redeemer of last resort.  This model is is a trust model which focuses on the Issuer, as the first mover, the redeemer, and the sole "executive" in control of creation of DBC. 

Here is a high level overview of the 5-role model: 

At the bottom of this page, please review the draft contract between Issuer and the Mint Trustee in an actual issuance (PicoIPO).  Below, is a UML sequence diagram of the duties of the Mint Trustee (me. )

When the other guys clarify exactly what their duties and procedures are, I will be happy to produce additional UML diagrams. 

Meantime, the following is one evidence relied upon by the Mint trustee. This is a balance sheet report from the Issuance server which is operated by the operator.  The hash values illustrate that Issuance server knows any particular Webfunds client instance, such as the Webfunds hash identity of the Mint and Manager.  Once the Mint and Manager person accept their roles, their accounts on the Issuance server are "switched on" at the server to give them special powers nobody else has: the Mint person can create unbalanced entries out of nothing, using Webfunds client.  If anybody other than Mint (SHA#98e...) tried to create a payment with Webfunds, in excess of their balance in their Webfunds wallet (value of instruments he has been  paid), they would of course be rejected by the issuance server.   Manager's special powers includes being able to receive payments  invented by Mint.  Money invented by Mint can only be given to Manager.  Server software does not allow Mint to make any payments to anybody other than Manager. 

Systemics Issuance Server
Trial Balance
Issuer: PicoIPO SHA:e7897df4fea3375ba1de4b0f13e91891988d8bf8

Here is another evidence relied upon by the Mint trustee. The Mint confirms that real metal has been bailed into the warehouse (the Repository) as backing for the PicoIPO DBC:

Here is what the Mint Trustee's desktop looks like after creating a DBC data file with the WebFunds program in the first window, and depositing the payment into my own wallet.  Nobody else could do this act, except the WebFunds instance identified by the Issuance Server as that of the Mint Trustee.  If anybody else tried to create a payment in excess of the money in their wallet, they would get an error message.  (The Issuance Server also will NOT allow the Mint Trustee to make any payment to anybody whatsoever, other than the Manager within the 5-role model, i.e. the Manager of the minting process.) 

Draft Contract

1.  This is an agreement between PicoIPO Ltd (the "Issuer") and
Todd Boyle (the "Mint").

1.a  The date of this agreement is .......



2.  Mint agrees to the following:

2.a  Mint will create a WebFunds account specially set aside
     for the creation of float.

2.b  Mint will duly notify the Issuer, and thus the Operator,
     of the account's details, generally by sending a zero payment.

2.c  Mint will only create float as per instructions from the
     Issuer.

2.d  Mint will write payments for the generation of float
     only to the instructed manager's account.

2.e  On receipt of instructions, Mint will compare the request
     to the terms and conditions of the named Ricardian Contract as a
     sanity check.

2.f  payments sent back to the Mint for the purpose of retiring
     float will be returned to the Mint account.



3.  Issuer agrees to the following:

3.a  Issuer will instruct Operator to set the Mint account as
     capable of creating float.

3.b  Issuer will send signed instructions for creation of
     float, including target account of Manager.

3.c  All instructions will be sent in accordance with the
     Ricardian Contracts so named.



4.  Both sides agree that

4.a  The users are a part of the auditing process, and are encouraged
     to participate.

4.b  In general, the relevant auditing information is to be made public.


5.  In compensation, the Issuer will ....


Signed,

Todd Boyle                                Bob Nugent,
Mint                                     for PicoIPO.

Below this line under construction. Don't go there.

1.  RM/ODP Use Cases between Issuer, Mint trustee, Manager, Repository, and server Operator

Terms of reference: 

Instrument - the digital bearer certificate signed and/or encrypted in a file, named for whatever thing is represented by the Ricardian Contract encrypted within the DBC file.  For example, within the context of DBC issuance, "gold" might be a DBC or digital warehouse receipt for real gold.  Specifications and definitions of Ricardian Contracts are at  http://www.systemics.com 

Instrument Ledger - the double-entry accounting system which is maintained by an Issuance Server in order to keep track of outstanding DBCs for a particular Instrument. 

a.  Use case: Operator creates an instrument  in an Issuance Facility 

Community:

Actor:  Issuer	Actor:  Operator	Actor:  Application
as role:  initiator of an instrument	as role:  instrument issuance host	as role:  system

Goal/Postcondition 
A new instrument ledger has been created inside the Issuance Facility. 
The new instrument ledger contains no transactions.
Operator has admin rights to the new instrument ledger in the Issuance Facility owned by the Operator.
The new blank instrument ledger implements the initial default instrument ledger definition requested by the Issuer, i.e. either the internal default of Issuance Facility design i.e. a blank instrument and chart of accounts, or alternatively, for example, 
 - an instrument ledger definition provided by the Application the Issuer is using, for example, specifying the instrument, national currency and/or a vertical industry chart of accounts required by the Issuer's Application or community, or 
 - a custom an instrument ledger definition containing particular currency structure, chart of accounts, periods, or other options desired by the Issuer. 

Roles 
Operator as owner of an Issuance Facility 
Issuance Facility as system 
Application as system 

Preconditions
A standard Issuance Facility exists and is running in a computer, maintained by a Issuer.
Issuer has a software application capable of connecting to the Issuance Facility in the SOX protocol, such as WebFunds application. 
Issuer has used the client software application to enter the necessary currency or instrument name, or optionally, prepared a custom instrument definition. 

Steps
Optionally, the Issuer composes a custom instrument definition, containing for example, a chart of accounts, etc. using any editor before starting to create an instrument in Issuance Facility.
Issuer connects with the Issuance Facility using some piece of software. 
Issuer invokes the function provided in the Issuance Facility for creating one or more new currencies.
Issuer supplies the instrument name and other information required to create an instrument(s)
Issuer executes the function of the Application designed for the purpose of sending these parameters and information to Issuance Facility and invoking the Issuance Facility  function to create an instrument(s).


Trigger 
The trigger is when a function is executed within the client application such as a clicking on a CREATE button at a GUI, which invokes the "Create Instrument"  function on the Issuance Facility's user interface.

Main Success Scenario
A new instrument was created by Issuance Facility.
Issuer's employee logins in successfully upon his first effort using the Issuance Facility using some client application.
Issuer's application works immediately upon its first effort connecting programmatically, with the Issuance Facility to use instrument interfaces.
The design or implementation of the Issuance Facility imposed no unnecessary requirement for any technical skill, accounting skill, or expenditure of time or labor by any Issuer or Issuance Facility owner to get the blank instrument started up.

Extensions 
Test Specification 
Open Issues 

b.  Use case: Issuer creates an instrument within an Issuance Facility Provider (IFP): 
      Community:

Actor:  Issuer	Actor:  Issuance Facility Provider (IFP) owner
as role:  subscriber	as role:  publisher

Goal/Postcondition 
Issuer has admin rights to one or more new blank currencies in Issuance Facility Provider (IFP).
The new blank instrument contains no transactions.
The new blank instrument(s) implement one of two options: the internal default of Issuance Facility design i.e. a blank instrument and chart, or an instrument definition requested by the Issuer, such as the following examples. 
 - a default instrument definition provided by Issuance Facility Provider (IFP) for example, having default national currency or a vertical industry chart of accounts, or,
 - a custom instrument definition containing particular instrument structure, chart of accounts, periods, currencies, and other options desired by the Issuer. 

Roles 
Issuer as subscriber, creating a new instrument. 
Issuance Facility Provider (IFP) owner as publisher, creating and granting admin rights to a new instrument. 

Preconditions
A IFP satisfying the business and technical etc. requirements of the Issuer exists. 
A standard Issuance Facility exists, running in a computer, owned by a IFP.
Issuer wants to start using the Issuance Facility Provider (IFP) to maintain an instrument. 
A communications channel exists between Issuance Facility Provider (IFP) and the Issuer sufficient to pass administrative control of the instrument from the Issuance Facility Provider (IFP) to Issuer, and exclude unauthorized access, etc. 
A user interface such as a browser or dedicated client, is provided by the IFP for the purpose of collecting the instrument name and optionally, the instrument definition from the Issuer and pushing these data into the IFP's Issuance Facility.

Steps
Issuer contacts owner of the Issuance Facility Provider (IFP) by some means and establishes the rights to use the IFP, for example, by paying the IFP. 
Issuer connects with the Issuance Facility Provider (IFP) as administrator, using some piece of software, for example, a browser, or accounting application provided by the Issuance Facility Provider (IFP).
Issuer invokes the function provided by the client application Issuance Facility Provider (IFP) for creating one or more new currencies.
Issuer supplies the instrument name required to create an instrument(s), and other information optionally allowed to create an instrument(s)
Issuer executes the function on the user interface provided by the Issuance Facility Provider (IFP) designed for the purpose of sending these parameters to Issuance Facility and for  invoking the Issuance Facility  function to create an instrument(s).
Issuance Facility Provider (IFP) owner responds by creating one or more new currencies in the Issuance Facility.
Issuance Facility Provider (IFP) returns success or failure acknowledgement to its client application inside the IFP
The IFP application hurls an HTML page or other response to the browser or other client operated by the Issuer.

Trigger 
The trigger is when a function is executed within the client application such as a clicking on a CREATE button at a GUI, which invokes the "Create Instrument"  function on the Issuance Facility.

Main Success Scenario
Blank instrument was created and provided by Issuance Facility Provider (IFP) owner.
Issuer's employee logins in successfully upon his first effort using the Issuance Facility Provider (IFP).
Issuer's application works immediately upon its first effort connecting programmatically, with the Issuance Facility.
The design or implementation of SOX compliant Issuance Facility imposed no unnecessary requirement for any technical skill, accounting skill, or expenditure of time or labor by any Issuer or Issuance Facility owner to get the blank instrument started up.

Extensions 
Test Specification 
Open Issues