This specification is concerned with transactions between accounts and the associated administration, enquiries and reports. It is not concerned with off-line transactions involving tokens such as notes, coins or virtual equivalents enabling use of similar, different or same currencies by parties not holding accounts. This specification being concerned with core architecture does not address user-interface issues.
1.2 Copyright, Distribution and Disclaimer
2. Introduction to MRS architecture
3. Naming convention and services
3.2 Registration and form of names
3.3 Name to address lookups
3.4 Form of server address
3.5 Form of server name
3.6 Contact names
3.7 Name service
4. Functional description of programs
4.1 MRS Transaction Server (MTS)
4.2 MRS User Client (MUC)
4.3 MRS Administration Client (MAC)
4.4 MRS Audit Server (MAS)
4.5 Recommended coding and licensing standards
5. Required message formats and content
5.1 Requirements common to all MRS messages
5.2 Acknowledgement records
5.3 Report request and delivery records
5.4 System audit request records
5.5 Registry administration records
5.6 System administration records
This program specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
A copy of the GNU General Public License is available from the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA, or from their website .
An accounting mechanism for multiple currencies may also be used for the recording and preparation of users' private accounts should they so wish, and for non-monetary accounting e.g. of the locations of items of equipment belonging to a community association or shared between members of such.
A LETSystem Registry provides this service in accordance with the LETSystem Design Manual.
ii. A process i.e. the actions performed by a instance of this program operating on a set of input and account data and producing output.
A functional description of the MTS program is provided in section 4.1.
A functional description of the MAS program is provided in section 4.4 .
Functional descriptions are available for the MAC program in section 4.3 and for the MUC program in section 4.2 .
a. The existence of choice within a proliferating and diversifying range of private and community currencies and arrangements such as community way charitable fundraising, customer loyalty points etc.
b. that the electronic and systems infrastructure needed to support such diverse currencies and arrangements will be expensive to develop, operate and maintain,
it follows that there exist evolutionary advantages to implementations which support multiple currency systems sharing the same network and administrative infrastructure, terminals and smart cards etc.
This infrastructure comprises distinct entities, but has no place for rigid boundaries except as may be determined by legal, ethical and practical constraints. This specification arises from the consideration that successful infrastructure will be based on the following principles:
* there will exist no single point of failure or control
* data processing and administration are decentralised as far as possible, consistent with cost, manageability and data integrity.
* Where hierarchically managed authority is unavoidable as with domain naming and the allocation of finite network address ranges this is delegated operationally to the most local level consistent with good working practices.
* scalability is unlimited technically except by the existence of finite network addressability and cost of access.
* initial processing nodes will be cheap enough so that anyone with the requisite technical knowledge to manage a reliable database service can set one up.
The initial working prototype (MRS version 1) was implemented on the Internet (which is itself based on the above architectural principles), however, as with the IETF Internet Protocols the MRS architecture is also capable of being implemented using separate private or public networks.
MRS transaction servers (MTSs) will support multiple currencies and some currencies will need support from multiple MTSs. To ensure wide area access, accounts need to be located on a server and transactions will be routed according to registry name. Hence there are routing advantages in transacting all accounts relating to a registry on the same named transaction server whichever currency system these accounts may be part of.
The fact that a particular MTS is likely to support all accounts for one or more registries also follows from the consideration that the registry must remain a point of contact with its users in order to create or maintain the necessary tokens, passwords or keys used for identification and authentication purposes, such that limits to the number of accounts serviced by a registry are likely to be imposed by human user-support considerations which determine a maximum registry capacity. At the time of writing this limit seems likely to be less than the carrying capacity of transaction servers or fault-tolerant, high-availability clusters responding to the same global name for transaction routing purposes. It also follows that with the likely carrying capacity of a server being greater than that of a registry, transaction servers will be expected to support multiple registries.
If the opposite were to become true, i.e. that a need were to emerge to support more named MTSs than administration centres issuing unique IDs, this difficulty could very easily be resolved (without breaking the proposed naming and routing architecture) by the registry splitting its list of IDs amongst a number of its own internally administered subdomains within the higher level registry name.
The alternative approach to architectural design of a multi- currency multi-registry network would be to associate (the processing of transactions and accounts concerning) particular currencies with particular servers. Consider the likely need to operate professionally-managed community currencies for city regions with millions of accounts carrying perhaps hundreds of millions of transactions daily (in addition to the parallel use of very many more much smaller user-managed currencies). The consequent association of single currencies with single server complexes as centralised economic failure points for whole regions would inevitably attract patterns of corporate management functionally and organisationally inconsistent with the design objectives stated above.
This architectural design is consequently based on the consideration
that community currency users will primarily be serviced through multi-currency
handling registries. It follows that network services will be registry
centric as opposed to system centric.
There is however no particular reason why registries, systems and servers need share the same namespace, so for example the same name might conveniently be used by a MTS, the registry it serves and the currency system used by all of its users for paying cost of registry service within the terms of its common members' agreement, though a resource conflict would occur if 2 systems or registries or servers attempted to share the same name.
Names must comply with IETF RFC1035 to enable use of existing DNS server and resolver programs and libraries.
The following global lookups are needed (reason): REGY --> MTS_ADDRESS (where to send local/remote acks etc.) SYSTEM --> MAS_ADDRESS (where to send ack copies for audit) MTS_ADDRESS --> MTS_CONTACT (who to inform if MTS not responding) MAS_ADDRESS --> MAS_CONTACT (who to inform if MAS not responding) DOMAIN --> MDNS_CONTACT (administrative contact for domain)Global lookups will be maintained through the MDNS service.
Local lookups on MTS server (reason): admin@REGY --> REGISTRY_CONTACT (regy contact/authentication) id@REGY --> ONLINE_USER (online user contact/authentication) REGY --> SYS1, SYS2 ... SYSN (list of systems for which registry services some or all accounts)The list of systems and online user details are maintained by the registry administrator. The registry contact/authentication details are maintained by the MTS administrator.
Local lookups on MAS server (reason): SYSTEM --> SYSTEM_CONTACT (system auditor or contact)
SYSTEM --> BLANKET_AUTHORISATION (blanket authorisation for system users) SYSTEM --> REGY1, REGY2 ... REGYN (list of registries handling accounts for system)The system auditor/contact data is maintained by the MAS administrator. The list of registries and blanket system user authorisation data are maintained by the system administrator. Blanket authorisations determine the level of data access by system users of each others' data. Values for authorisations are 0 - none, 1 - account balances only, 2 - balances and turnover data, 3 - all data.
a. IP address
This requires registration of a well-known service and associated port number for the MRS client-server packets. (Not yet supported.)
b. IP_address:port_number (Not yet supported).
Forms a. and b. are commonly used for Internet client-server networked application bindings while form c. may be used for MRS implementations using email as the packet transport. This specification is intended for initial test implementation using form c.
a. processes transactions involving payments into and out of accounts for registry users directly serviced. It either communicates with another MTS handling the account for the other party to a payment, or if both payer and payee accounts for a particular transaction are on the same MTS it processes both.
b. sends details of completed or failed transactions to the transaction initiator and MAS for the system.
c. handles administrative requests concerned with the creation and removal of user accounts and setting of debit limits on systems within which these are used.
d. responds to requests concerning account balances.
e. authenticates the originator of all such transactions and requests and verifies the validity of the request, or rejects such if invalid.
f. maintains account balance and turnover data, and other data as is required to maintain transactional integrity on account balance and turnover data and to authenticate and verify transactions and requests.
For the purposes of this specification, the minimum requirements are as follows:
a. ability to convey information identifying party requesting payment or information to a MTS or MAS and information authenticating this identity.
b. ability to request payment from payer (purchaser) to payee (vendor) on a given system to a MTS and receive responses indicating success or failure of such requests.
c. ability to request and receive payment verification data on a particular system account to a MTS. In the case of a LETSystem account this data will take the form of an account balance and turnover data. Note that such a request may be authenticated by a different MTS from that containing the requested data. In this event it will be forwarded from the authenticating MTS (which maintains the requesting users' account) to a authorising MTS (which maintains the requested data) and which responds directly to the requesting MUC.
d. ability to request audit information from MAS servers, (via authenticating MTS servers).
e. ability to display and/or print responses to the above requests.
a. To carry out user registration work, creating user accounts for all systems to be used on the registry MTS.
b. To upload user authentication details such as passwords and public keys and on-line user return addresses to the MTS servers.
c. To enable users to authorise others to make payments from their accounts (e.g. in respect of direct debits or to enable their accountants or account managers to make payments on their behalf), by registering these authorisations with the MTS serving the registry.
d. The MAC will maintain a list of systems on the MTS for which the registry is willing and authorised to maintain accounts.
e. The MAC will also be able to display the responses from the MTS server indicating success or failure of these requests.
f. A MAC must also contain all of the features described in 4.2 for a MUC.
a. maintaining the list of registries on the MAS willing and authorised to service user accounts for each system.
The MAS will:
a. receive, secure, acknowledge receipt and verify data concerning all transactions on one or more serviced currency systems.
b. Compare both halves of each transaction to ensure MMS and MSS parts are consistent.
c. Inform the system contact in the event that inconsistencies are detected.
d. Provide reports containing details of all transactions and system summary data for audit purposes on request to authorised users.
In line with its audit function the MAS has no operational involvement over how individual acknowledgements are processed.
Portability: Programs should be written portably, using standardised features of languages supported by multiple compilers, interpreters, platforms and vendors, in order to minimise the difficulties of porting code between different platforms.
Modularity: A modular approach should be adopted to standardise interfaces between core processes and different user interfaces and data transport protocols.
Reusability: Publication of source code ensures that software can be reused and avoids programmers having to redo what has already been done. Use of the GNU Public License (GPL) is recommended for this purpose.
Security: Open peer group review of code security and integrity also
requires publication of source code, see also http://www.opensource.org/
This specification provides the minimum data formats needed to ensure messaging integrity; i.e. to ensure that distributed transactions can be completed based on a known level of server and network availability. The requirement to ensure message authentication and confidentiality is however seen as changing, with very little security of these kinds needed in an experimental environment not currently exposed to technically sophisticated attack but where an increasing requirement exists as digital representations of increasing financial values are carried over the proposed network. This standard provides a framework for increasing levels of security to be implemented together with backwards compatibility to enable more and less technically developed parts of the proposed network to communicate with each other.
Where encryption is used to protect the confidentiality of data in transit this document currently describes the format of message contents prior to such encryption and following associated decryption. When confidentiality encryption standards are agreed this document will be extended to include relevant data exchange formats.
a. Whether encryption is carried out to ensure confidentiality,
b. the data transport protocol used, for example message contents may need to be delimited using start and end identifiers or tags from protocol or implementation specific data preceding or following the message body (e.g. email headers and footers).
c. whether message contents need checking against digital signatures or checksums.
In general tags and records used to control this encapsulation will precede or follow the information being encapsulated and will be removed prior to further processing on message receipt. This includes records containing data used to verify message contents which will be removed from the core contents prior to verification of such contents. For example a signature record containing a checksum is not considered part of the message content from which this checksum was calculated and which the checksum will be used to verify.
and will be followed by a single text record containing the text:
Other message transport protocols: Not yet defined.
record_type_3,transmitting commas\c encoded as \c
record_type_4,transmitting newlines\n encoded as \n
record_type_5,transmitting backslashes\\ each encoded as \\
If present signature record(s) will precede the message body they are used to authenticate and will be processed in sequence starting with the first, each being removed in turn before being used to authenticate the rest of the message body from which they are removed, which will include any following signature records in the sequence not yet processed.
For the lowest level of authentication only the sender signature type is required in order to assert the identity of the message sender. As implementations of this standard are developed and new methods become available it is anticipated that definitions of signature methods and data will be included and refined within future revisions of this document.
The authentication methods used will depend upon the state of transaction server development and agreements between server operators, registries and users about authentication requirements. Providing for alternative authentication methods within message standards allows for the progressive upgrade of software with backwards compatibility between different versions.
Signature records will use the following format:
where "signature" is the record type,
method is a word referring to the authentication method used taken from the values: SENDER, CKSUM, CHKORIG, PASSWD ... etc. as described below, and data is a field containing the checksum, password, key requiring knowledge of password, or digital signature etc. depending on value of method. Data is not yet fully specified for all suggested methods; where unspecified a description of data purpose is given.
Authentication methods making use of this record may include:
CKSUM; This method involves use of a checksum transferred with message to validate that message contents as received were not accidentally corrupted.
SENDER; This signature record is used to assert message sender and program type and by itself provides no security. Data consists of 3 fields:
i. SENDER TYPE which must be one of the following words: MUC, MAC, MTS, MAS and
ii. the sender identity, which will be of the form ID@REGISTRY in the case of type MUC, admin@REGISTRY or admin@SYSTEM for type MAC, NAME.OF.SERVER for types MTS and NAME.OF.SYSTEM for type MAS.
MSGID; This method is used to exchange a unique message ID which may be referred to later in handshake records required by the CHKORIG signature method.
CHKORIG; This method indexes a protocol dependent handshake method such as dialback, reverse DNS lookup etc, confirming connection is coming from a known originator address to determine message origin. CKSUM and MSGID signature records must precede this record if this method is used. If so further validation and processing of the message will be deferred until handshake records have been exchanged successfully with the message originator. The data related to this method is the name of the message transfer protocol to be used for exchanging handshake records, e.g. email, UUCP, dialback, IP socket etc which together with the sending_server MSGID data are used to reference a previously assigned network address or dialback number etc. with which to exchange handshake records.
PASSWD; The data used with this method is an unencrypted plaintext password. This provides an elementary degree of security within a network environment in which it can be assumed that messages are transported confidentially.
CRYPTKEY; This method is used to send a one-way encrypted key which can be calculated from message contents and a key known by message sender and receiver but not transmitted as part of the message. The message receiver will recalculate and compare this key and will only accept the message as valid if received and recalculated keys match. The data part of this method (key) is generated through use of a one-way function such as Unix crypt or similar on a string function combining checksum and password.
PK; This method involves the use of public-key encryption to create a digital signature transferred with messages which the signature is used to confirm. This method enables message senders to be authenticated without requiring transmission of any shared secrets. Full implementation of this method in an open-source context is dependent upon the availability of technically viable libraries with minimum licensing and other legal restrictions, see section 8 of the GNU task list .
The record format is as follows:
from_server is the DNS style name of the server sending the handshake record.
cksum is the validated checksum signature of message being checked, (see signature,CKSUM above).
msgid is the identity of message being checked or confirmed (see signature,MSGID above).
word is CHECK if this handshake is sent to check origin of a previous message, TRUE if sent to confirm a handshake CHECK record and FALSE if the CHECK record cannot be confirmed.
Where stage can take values send and reply and timestamp is the number of seconds since 1 Jan 1970 as obtained using standard Perl and C libraries. Receipt of a ping,send record will be responded to using a ping,reply record.
General purpose: signature, handshake, ping
Acknowledgement: ack1, ack2, ack3, ack4, ackr2, ackr3
Request report: rqrp1, rqrp2, rqrp3, rqrp_error, balance, turnover, detail
Audit request: arq1, arq2, arq3, au_error, au_bal, au_turn, au_detail
Registry administration: add_acc, mod_acc, del_acc, rprt_acc1, rprt_acc2 add_ou, mod_ou, del_ou, rprt_ou1, rprt_ou2 add_auth, mod_auth, del_auth, rprt_auth1, rprt_auth2 add_sys, del_sys, rprt_sys1, rprt_sys2
System administration: add_regy, mod_regy, del_regy, rprt_regy1, rprt_regy2
Signature records will precede other records if present and will be in the order they are processed. A handshake or ping record if present will be the only record in the message. Other records will follow signature records. Header records (rqrp3 and arq3) will precede the other report records to which these refer, the number of which (num_recs) will be present as a field within the header record.
Fields common to more than one type of ack record include:
ack_id: a decimal sequence number identifying the acknowledgement in connection with the originating registry. e.g. 123456 . This number will be positive for a normal acknowledgement, the amount of which is added to aggregated turnover data for both payer and payee. However if a previously cleared acknowledgement is repudiated or reversed this will be achieved by resending it (from the server which originated the original transaction) with its ack_id number preceded by a minus sign and the original amount reversed and deducted from aggregated turnover data for both payer and payee. The need for a unique ack_id in connection with the originating registry implies a sequential allocation of ack_ids by the MMS process or thread for a particular registry.
from_registry and to_registry: are DNS style domain names uniquely identifying the originating and responding registries. e.g. se.cov.uk
from_id + to_id: are alphanumeric identifiers uniquely identifying payer and payee within their respective registries. e.g. RIK
system: is A DNS style domain name uniquely identifying the currency or set of accounts between which direct transfers of funds is possible. e.g. childcare.hours.sa.cov.uk
amount: is a decimal integer optionally preceded by a minus sign and optionally followed by a period followed by between 1 and 3 decimals.
date: is a date, format YYYY/MM/DD .
details: may be a text description of transaction or other data carried with the acknowledgement, e.g. a customer number used within a payee account-reconciliation system.
reason is a code indicating the reason for rejection. The following reason codes are suggested:
1 to_id unknown here or has not opened account on system 2 to_registry unknown here 3 system unknown here 4 signature verification failure 5 payment exceeds predefined limits 6 invalid data 7 unauthorised payment
Note that ack_id and date are generated by the MMS sending this record.
In the event of intermittent server or network failures, identical ack2 records may need to be sent repeatedly in respect of the same acknowledgement until an ack3 record is received or the transaction is timed out, in which event it will need to be completed or rewound manually. The decision to time out is made by the ack3 sender.
Identical ack2 records may also need to be sent to the MAS for the system repeatedly until an ackr2 record is received or the effort to inform MAS is timed out, in which event the MTS operator and system contact will be informed.
accept_or_reject contains the word accept or the word reject. reason will be OK for accepted records or the reason for rejection.
Identical ack3 records may need to be sent more than once in response to identical ack2 records in the event of intermittent network or server failures either until the ack3 is received by the MMS or until the MMS sending the ack2 records times the transaction out.
Identical ack3 records may also need to be sent to the MAS for the system repeatedly until an ackr3 record is received or the effort to inform MAS is timed out, in which event the MTS operator and system contact will be informed.
new_balance is the balance on the account after the acknowledgement has been accepted - in the case of ack4 rejects the value of this field is not used or meaningful. Accept or reject fields and reason codes for rejected acknowledgements are as for the ack3 record.
a. by a user checking their own account and requesting a statement or balance data on one or more than one system,
b. or by another authorised user in connection with systems allowing such disclosure within their members' agreement in order to enable users to verify each others' accounts to promote appropriate use,
c. or by an accountant authorised by the user for the purpose of presenting accounts for tax or other reporting requirements.
The rqrp1 record requesting such data is sent from the MUC to the MTS for the user's registry able to authenticate the identity of the user requesting this data.
The MTS in receipt of the rqrp1 request will either allow or refuse it based on whether the identity of the user requesting this data can be correctly authenticated. If allowed further processing will be intermediated using data as specified in a rqrp2 record, either locally if the user about whom the request is made is local to the MTS or otherwise by sending this rqrp2 record to the MTS holding relevant balance, turnover and details data able to answer this request. (If authentication is not successful reasons for refusal will be communicated directly to the requester using a message containing a rqrp3 header and rqrp_error records).
The requester id and requester registry fields will be obtained from a signature,sender record contained within the message containing the received rqrp1 record. Requester address to which the rqrp3 response will later be communicated will be derived from requester id and requester registry. (This implicitly restricts balance data to be sent only to the address previously registered for requester in order to keep this enquiry more secure and straightforward. This restriction may at some stage need to be selectively lifted if demands arise which can justify greater flexibility. This would be achieved through use of a separate requester_address field within the rqrp1 record subsequently transmitted using the rqrp2 records.)
The MTS receiving or processing the rqrp2 request may also allow it or refuse it based on whether the (previously authenticated) party requesting data is authorised to obtain it, either as required by a members' agreement, or by the party whose balance/account information is requested.
This MTS will send data if authorised, or communicate reasons for refusal directly to the requester using a message containing a rqrp3 header record.
id,registry: the user and registry identifiers of the account about which information is requested.
system: On rqrp1 and rqrp2 records, where the system field is set to the reserved word "all", data for all systems used by this user is requested. On rqrp3 records, the value for system will be the system, report data concerning which is headed by same rqrp3 record.
level: indicates the level of information requested. Different systems will allow different levels of disclosure to account holders. The level field contains 3 characters each of which may either be a hyphen (meaning type of data not requested) or the letter b (for balance) t (turnover) or d (for details). E.G:
b-- - Balance only bt- - Balance and Turnover data btd - Balance, Turnover data and transaction Details --d - transaction Details only.
rqr_id@rqr_regy: the user and registry identifiers of the party requesting information.
rqr_addr: information enabling transaction server to communicate requested data or reason for refusal of or inability to carry out request to party requesting data.
is_user: This field records whether or not the user requesting data is a user of the system relating to which data is requested. The MTS authenticating user requesting data may need to provide this information to the MTS authorising the request for the latter to be able to decide whether to honour it. Valid values are Y (yes) and N (no) .
num_recs is the number of rqrp_error + balance + turnover + transaction records resulting from the enquiry relating to system immediately following the rqrp3 header record.
Reason is a short explanation of the reason for allowing or refusing the information request.
amount: is the current balance in the account.
allocated: is the amount allocated to transactions initiated but not yet fully cleared; when all this amount is cleared balance will be reduced by this number.
limit: is the limit set on this account such that a transaction taking the account below this will be rejected. The reserved word "none" is used for accounts on systems without limits processed automatically by the MTS servers.
Periods are either date ranges (from_date-to_date) using format YYYY/MM/DD-YYYY/MM/DD
relating to the period for which the turnover total is accumulated or 4
digit years e.g. 1999 is exactly equivalent to 1999/01/01-1999/12/31 ,
or the word: all indicating total turnover from
when account opened to current date.
total is the amount turned over, with receipts in and payments out both made positive and added to total. Repudiated/reversed transactions are removed from turnover data for the period in which the original transaction was recorded. The number of turnover records sent will be the number normally stored for the system or available for the user (e.g. members of a system might have an agreement limiting availability of turnover to the most recent 2 years plus from the date account opened to current date).
ack_id,amount and details: are the same as on the ack2 record.
date: is when the acknowledgement cleared (i.e. when ack3 record received and processed by MMS).
with: is the ID@REGY global identifier of the party with whom the acknowledgement occurred.
new_bal: is the balance recorded on the account following the acknowledgement as on the ack4 record.
The arq1 record is sent from the MUC to the MTS used to authenticate the online user making this request. This MTS either authenticates this user and sends a arq2 to the MAS for the system or fails to authenticate.
The MAS will either honor or refuse the request depending upon whether the user is authorised to see the level of data requested. The resulting report will be sent directly to the requesting user following an arq3 header record.
Fields used in more than one record:
system: the name of the system being audited
level: is the level of information requested. E.G:
b-- - balances only bt- - balances and turnover records btd - balances, turnover records and transaction details --d - transaction details only
rqr_id@rqr_regy: the user and registry identifiers of authenticated party requesting information.
rqr_address: information enabling transaction server to communicate requested data or reason for refusal of or inability to carry out request to party requesting data.
is_user: This field records whether or not the user requesting data is a user of the system about which data is requested. The MTS authenticating user requesting data may need to provide this information to the MAS authorising the request for the latter to be able to decide whether to honour it. Valid values are Y (yes) and N (no) .
date: is the date of the report in YYYY/MM/DD format
num_recs: is the number of au_bal, au_turnover and au_detail (or error) records in the report headed.
reason is a short description of the reason for refusal or acceptance of information request.
amount: is the current balance in the account.
allocated: is the amount allocated to transactions initiated for which the MAS has received ack2 but not yet ack3 records (i.e. not yet fully cleared). When all the allocated amount is cleared balance will be reduced by this number.
limit: is the limit set on this account such that a transaction taking the account below this should be rejected by the MTS. The reserved word "none" is used for accounts on systems without limits processed automatically by the MTS servers, and "n/a" is used where this data is not present on the MAS.
date range is either from-to dates both in format YYYY/MM/DD relating to the period for which the turnover total is accumulated, or an entire years worth of data for year YYYY or the word all to indicate all turnover on account from date opened to current date.
amount is the amount turned over, with receipts in and payments out both made positive and added to total. Repudiated/reversed transactions are removed from turnover data for the period in which the original transaction was recorded. The number of turnover records sent will be the number normally stored for system audit purposes.
Fields are the same as on the ack2 record except for record type and new_bal which is the balance recorded on the account following the acknowledgement.
The term "registry administration" is used for adding, removing and modifying identification, authorisation and account facilities for registry users at the appropriate MTS server. These records will be preceded by the appropriate signature records used to authenticate the message originator.
Not all users for whom accounts are kept will be on-line. Those who are not on-line will authorise particular users who are on- line to carry out specific accesses to specific system accounts on their behalf. Return addresses and authentication keys will be maintained for on-line users. Account details and authorisations will be recorded for all users.
In order to help validate administrative requests, registry administrators will maintain a list of systems for which the registry is willing (and has been authorised by system management) to support user accounts.
del_acc records will only be processed if balance is 0.
rprt_acc1 records are sent by MAC to MTS and data for each user is returned with a rprt_acc2 record.
id,system: identification of account being added, modified or deleted (together with registry for which MAC sender id is admin). For mod_acc and rprt_acc1 records a value of "all" for id is meaningful. rprt_acc2 records use the full user identification id@registry.
init_bal: is the users initial balance. This will be 0 unless the user has traded on the system prior to transfer of system data to MRS. In other circumstances balance may only be modified through an acknowledgement.
limit: is the limit set on this account such that a transaction taking the account below this will be rejected. The reserved word "none" is used for accounts on systems without limits processed automatically by the MTS servers.
error: meaningful values for error currently understood to be either "none" or "user does not exist".
Record formats: add_ou,id,key,address mod_ou,id,key,address del_ou,id rprt_ou1,id rprt_ou2,id@registry,key,address,errorrprt_ou2 records will be returned for each online user referenced with full user identification (id@registry). Access details only need to be managed for users for whom direct MTS access facilities are provided (e.g. those with access to email or other supported messaging protocols as these are included). A user is assumed to require the use of one single key for data relating to all systems on the MRS which he or she is authorised to access.
id: identity of online user whose access details being added, modified or deleted together with registry of admin user for MAC. For rprt_ou1 records a value of "all" for id is meaningful.
key: The password, encrypted password, public key or identity of public key used by MTS to authenticate user using the signature method which is agreed and operational.
address: protocol and address to which all communications to user will be addressed. Consists of a protocol followed by a colon followed by the address using protocol. Currently SMTP email is the only protocol supported e.g. SMTP:firstname.lastname@example.org
error: meaningful values for error currently understood to be either "none" or "key does not exist".
Record formats: add_auth,id,authid@regy,system,access mod_auth,id,authid@regy,system,access del_auth,id,authid@regy,system rprt_auth1,id@registry,authid@regy,system rprt_auth2,id@registry,authid@regy,system,access,erroradd_auth records add access, mod_auth can modify only the access level and del_auth records remove access. A rprt_auth1 record is used to obtain a report of authorisation recorded by the MTS and is responded to using one rprt_auth2 record to report each relevant user authority record held.
id: identity of user authorising another to access his or her details relating to system (registry as for admin using MAC). For rprt_auth1 records reserved value of "all" for id is meaningful.
authid@regy: identity of user authorised to access details relating to system. For rprt_auth1 records reserved value of "all" for authid@regy is meaningful.
system: system for which access authority is granted. The reserved word "all" means all systems for which authorising user is currently registered now and in the future.
access: level of access authorised as follows;
read - authid@regy may obtain details of account. dd - authid@regy may debit directly from account. write - authid@regy may make payments from accounts to any user of system on behalf of id@registry. all - authid@regy authorised to read, dd and write access account.error: meaningful values for error currently understood to be
1 - none 2 - id does not exist 3 - id has no account on system 4 - unknown access level
Record formats: add_sys,system del_sys,system rprt_sys1,system rprt_sys2,system,errorfield descriptions:
system: is the unique global system name allocated to system. Use of the reserved word "all" for system is meaningful for rprt_sys1 which requests a report of systems. Each system for which a report is requested is responded to with a rprt_sys2 record.
auth: is the level of information all system users are authorised to access through members' agreement, without regard to other authorisations on individual accounts.
The following values for auth are defined: 0 - none 1 - balances only 2 - balances and turnover records 3 - balances, turnover records and all transaction details 4 - transaction details onlyerror: is returned to indicate an error condition in processing the rprt_sys1 request.
The following error codes are defined: 0 - no error 1 - system not recordedNote that authorisation details may be transferred to the MDNS service when this is developed sufficiently such that this is not thought to introduce security holes in processing this field.
The term "system administration" is used here for maintaining the list of registries authorised to service a currency system which is audited using the MAS.
Records used for this will be preceded by the appropriate signature records to authenticate the message originator.
Record formats: add_regy,system,regy del_regy,system,regy rprt_regy1,system rprt_regy2,system,numrecs regy,registryfield descriptions:
system: is the global system name for which the registry list is being
maintained. regy is the global name allocated to registry. rprt_regy1 requests
a list of registries authorised to service system. The response to a rprt_regy1
record is headed by a rprt_regy2 record, with numrecs being the number
of following regy records, each containing an authorised registry name.