A Multi Purpose Web-based Contractual Management System

A Multi Purpose Web-based Contractual Management System

SHARIL TUMINUniversity of Bergen

IT DeptP.O. Box 7800, 5020 Bergen

[email protected]

SYLVIA ENCHEVAStord/Haugesund University College

Faculty of Technology, Business and Maritime SciencesBjørnsonsg. 45, 5528 Haugesund

[email protected]

Abstract: A Web-based multi purpose contractual management system can provide support to contractual processworkflows for different types of contractual process of unilateral, bilateral or multilateral contracts. These pro-cesses can be done on-line i.e. Web-based without the need for all actors to be synchronously present with respectto both time and space. Different contractual processes of initialization, negotiation, agreement, signing (witness),and archive are managed within the application securely by analyzing data-flow between actors, ushering actors toperform their duties in a timely manner and employing appropriate cryptographic techniques on every step of theway. The implementation must deliver a management system that provides operational properties of authenticity,privacy, trustworthy, reliability, verifiability, and linkability.

Key–Words: Contract, Contract Management, Applications security, Secure Web-based Application, Secure Work-flow Modelling, Applied Cryptography

1 IntroductionSince early time in the history of mankind, men ne-gotiated, agreed and bound to contractual agreementsin the matter of properties exchange or promises offuture services.

Figure 1: Kushans contract for a sale of land 527 A.D.(front side)

In a collection of Bactrian document from ancientAfghanistan [16] is a piece of Kushan’s contractual

document, shown in Figure 1, for a sale of land, writ-ten down as early as 527 A.D.

One can clearly see that the document was wit-nessed and sealed by no less then five persons. Acopy of the original text was written, tightly rolled,tied with string, and sealed with five bullae on the topof the seen document. The back of the sale document,shown in Figure 2, shows signatures of the witnessesto the respective seals. Presumably, the sealed copycould then be opened in the presence of a judge incase of a future dispute.

Figure 2: Kushans contract for a sale of land 527 A.D.(back side)

Generally speaking, a contract is a legally bind-ing agreement between two or more parties by whichrights are acquired by one or more to act or forbear-ance on the part of the other or others. A person canact on the behalves of a group of people, organization,

WSEAS TRANSACTIONS on INFORMATION SCIENCE and APPLICATIONS Sharil Tumin, Sylvia Encheva

ISSN: 1790-0832 819 Issue 6, Volume 7, June 2010

cooperation or enterprise. A contract is to be agreedupon. In case of disputes at a later time, a record of theagreement is to be kept and can be used as evident forresolving conflicts. So, a contract is finalized whenthe content of the contract is agreed and the recordof the agreement is accepted trustfully by all concern-ing parties. Any framework for contract management,digital or otherwise is to promote this trust.

The goal of this paper is to propose an open-ended, multi purpose Web-based Contract Manage-ment System (CMS) for deployment where contrac-tual processes can be done between actors using Web-based applications as assertive actions and emails asevent triggers. Any registered user can initiate a con-tract procedure. Anyone with an email account any-where can register to the system. Any of the registeredusers can be used as a witness. This proposed frame-work for on-line contract management will providethe support of contract process flow without the needfor the different related actors within the process to besynchronously present with respect to both time andspace. Virtual meetings are done by message passingvia email or Web-based drop-box areas and actionsare executed or triggered for assertion by applicationsin a timely fashion dictated by rule based process flowdirectives.

A contract can be of a different type depending onthe number of participating parties. There can be one,two, three or more interested parties, Figure 3.

Figure 3: Contract Types

Therefore a contractual process can be typed asthe following three types:

1. unilateral - e.g. a will, a testament,

2. bilateral - e.g. a buying and selling agreement,

3. multilateral - e.g. a project team distributionagreement of roles, responsibilities, and resourcedivisions.

Different types of contractual process define dif-ferent types objects and attributes, both contract spe-cific and domain specific, and these are contract-coreobjects and contract-core attributes, and related tothese contract-core are domain-specific objects anddomain-specific attributes. For a particular contract,these objects and attributes together with contractmeta data of hashes and digital signatures will be usedto produce a finalized contract document in what wecall a contract synopsis. A contract synopsis is repre-sented in XML (Extensible Markup Language).

Different types of contract will have different dis-creet stages. Stages are arranged in an ordered se-quence. The system will track these sequences andinform all concerned parties about the status of a cur-rent stage. The currently active actors at a particularstage will be ushered to perform certain imperative ac-tions using Web-based applications.

Most contracts will pass through the stages in thefollowing sequence:

S1 - Initialization

S2 - Negotiation

S3 - Agreement

S4 - Signing (witnessing)

S5 - Archive (after sealing)

Depending on which type of contractual processshown in Figure 3, the stages of the process will fol-low the sequence shown in Figure 4.

Figure 4: Contractual process workflows



The unilateral contractual processes will skip S2and S3, and will effectively have workflow sequence{S1, S4, S5}. For fixed priced buying and selling, inthe bilateral contractual processes S2 will be skippedand will have workflow sequence {S1, S3, S4, S5}.The multilateral contractual processes are more com-plex and will have all workflow sequence {S1, S2, S3,S4, S5}. It can also happen that there are loop-backsfrom S3 to S2, and will effectively have workflow se-quence {S1, {S2, S3}+, S4, S5}, in such cases.

The contract management system needs to facili-tate users in 1) initialization phase (Initialization); 2)intermediate phase (Negotiation and Agreement); and3) finalize phase (Signing and Archive).

In the case of unilateral contract, the system willprovide similar services as given by a notary pub-lic officer. The Negotiation and Agreement are notneeded for unilateral contract. One service that is notconnected directly to wills or testaments but is sim-ilar in its processes is related to notarial documents(signed and witnessed notices) of any kind. This typeof contracts are useful for attaching timestamps andwitnesses on any type of documents, f.ex. a scientificpaper. Both bilateral and multilateral contracts willhave to go through Negotiation and Agreement.

Essentially, actors in the contractual procedureare having different roles with different responsibil-ities and duties. These roles are; 1) initiator, 2)provider, 3) consumer, 4) witness and 5) archiver.These actors are actively involved in the differentstages mentioned above. We will discussed these ac-tors with their corresponding roles and duties in moredetail in Suction 2.1.

The design, development and deployment of aWeb-based multi purpose contractual managementsystem (W/CMS) must deliver a management systemthat provides operational properties of:

1. P1 - Authentication

2. P2 - Privacy

3. P3 - Trustworthy

4. P4 - Reliable

5. P5 - Verifiable

These operational properties will be discussed insome detail in Suction 2.2. For the time being it isenough to say that these operational properties defineconstraints on actors of the system to uphold the se-curity level needed for a contractual management sys-tem.

2 Background

2.1 Actors’ Roles and Responsibilities

There are five types of human actor identified in theW/CMS directly related to the roles they assumed inthe system. They are labeled as follows:

� - Initiator, which also will act as intermediary,coordinator, and overseer.

� - Provider, for example seller and benefactor.

� - Consumer, for example client, buyer and ben-eficiary.

� - Witness, a witness will put signature on acontract.

� - Archiver, an archiver will put a seal on a con-tract in the fine stage of a contractual process.

Figure 5 shows relationships of actors, objects,actions and states. Actors are collected into threetypes of groups, 1) system operators group�M; 2) ac-tive users group �A; and 3) passive users group �P.An actor belongs to a set of users of the system �.

Figure 5: Conceptual CMS use-case

In order to be a user, a person needs to be reg-istered to the W/CMS. Each user is given a unique



Table 1: Contract type vs Number of Witness

Contract type � or � �(min) �(max)

unilateral 1 1 2

bilateral 2 2 2

multilateral ≥ 3 0 0

username and a password during the registration pro-cess. The username and password will be used forauthentication during the subsequent interactions withthe system.

Each user in the system will be given a pair ofkeys, one public Kpub and the other private Kprv.The W/CMS will utilize the public-key cryptogra-phy for the process of; 1) encryption/decryption; 2)sign/verify; and 3) blind/unblind, more on this in Sec-tion 3.1.

Both initiators � and archivers � belong to theW/CMS managers groups, � ∪� = �M . They man-age the human side of the W/CMS and do all manualprocesses concurrent to the automatic processes de-fined in the system.

An initiator Ii ∈ �, i ∈ [1, n] is naturally a trustedoperator in the W/CMS. Her work is to initializeall pertinence contract-core objects, domain-specificobjects and their related attributes. The initiator isprompted into action by a request done by an activeuser of the system.

Within an extend of a contract forming process, auser is either active or passive, and can never be bothat the same time, �A ∩ �P = Ø . Both providers� and consumers � belong to the active user group.While witnesses � belong to the passive user group,� ∪ � ∪� ⊆ �. Within a contract forming instance,a provider or a consumer can not also be a witness.All active users Pi ∈ �, i ∈ [1,m] need to providethe W/CMS with supporting documents, conduct ne-gotiations and actively agree to the final agreementof the contract. Potential witnesses, Wk ∈ �, k ∈[1, l],�k , � j will be invited to be witnesses and signa finalized agreement. A witness will sign a particularcontract blindly or otherwise, depending on the pri-vacy constraint of the contract. We propose a witnesspolicy plan as shown in Table 1.

For multilateral contract, there is no need of anexternal witnesses, where the active members of thecontract themselves serve as witnesses. In this pro-posal, we make the assumption that the witnessingprocess incur significant cost to the contract formationprocesses, in terms of risks, economy and efforts.

2.2 Operational Properties

As mentioned in passing in Section 1, in order toachieve security and quality criteria, thus promoteusers’ trust toward the system, the proposed W/CMSmust perform with the following operational proper-ties:

P1 - Authenticity: Only registered users Ui ∈ �are recognized by the system. Users are authenticatedprior to granting access to the system. Only eligibleusers with authorization corresponding to theirs rolesare able to access certain parts of the system. Usersactivities are logged.

P2 - Privacy: Access to each contract syn-opsis is controlled by graded privacy level of 1)public, 2) semi-public, 3) semi-private, and 4)private. At a public level, some or all componentsof a particular contract synopsis are accessible byanyone interested. At a semi-public level, someor all components are accessible only by users ofthe system. At a semi-private level, some or allcomponents are accessible to � ∪ � ∪ �. Lastly,at a private level, only � ∪ � are granted accessto all components of a particular contract synopsis.Each component can be individually marked aseither public or private. The W/CMS provides manydifferent combinations of access controls. When thereare conflicts in authorization, the contract synopsislevel takes precedent over the individual componentsaccess flags.

P3 - Trustworthy: All user, �, are real peo-ple and no two or more users belong to a singleperson. All contracts documents marked with privateflags are stored in an encrypted forms and onlyauthorized users can access and decrypt them. Adetailed history of a particular contract synopsis atany stages is given to �A at any time. The invariant�A ∩�P = Ø is diligently checked by � for each �committed to a particular contract synopsis.

P4 - Reliability: It is not possible to fake signatureon a contract. Each private key Kprv is protected byuser’s password whereby only the owner can makeuse of them. Private keys are stored securely in thesystem and no one can misuse them, even personswith system managers permissions, Ui ∈ �M. Onlyvalid witness Wk ∈ �, k ∈ [1, l],�k , � j for aparticular contract is allowed to sign as a witness.

P5 - Verifiability: Individual person involvedwith a particular contract is able to independentlyverify any signature within the contact of the contract.



All activities pertinence to the contract forming pro-cess were log, every piece of items will be connectedwith timestamped events in the events history ofa particular contract. At the closing phase of thecontract both the contract synopsis and events historywill be signed and sealed by the archiver� and storedin a save storage area or an off-line media for examplean encrypted CD (compact disk).

2.3 Design Principles

Effective design connects acting to thinking which inturn connects implementation to formulation. To beeffective a design needs to be guided by some designprinciples. These principles provide the designers andthe implementers with a base line on which the prod-uct as a whole is aiming to achieve when it is put intoproduction. Thus the system that facilitate the con-tract management, must above all, be usable, adapt-able, and manageable. The system users interfacesand process workflows must conform to users needsand expectations, logically laid out and simple to un-derstand. There should not be any ambiguities. Reg-ulations regarding different aspects of contract mak-ing will change with time, so the system needs toadapt to the current regulatory demands. To be agileand responding to changes, the system and its subsys-tems need to be managed with manageable interfaces.Therefore, in this paper we propose an open-endedWeb-based contract management system guided bythese five design principles:

Q1 - Usability

Q2 - Adaptability

Q3 - Scalability

Q4 - Interoperability

Q5 - Maintainability

It goes without saying that these five design prin-ciples must include and implement the five opera-tional properties mentioned earlier in Section 2.2.

From the conceptual use-case diagram of Figure 5and the three phases mentioned in Section 1, the work-ing model of the W/CMS can be decomposed intothree separate subsystems as shown in Figure 6, whichrepresents a simplified version of process workflowsschematic of the whole system.

The design principles will help developers,installers and maintainers respectively to develop,deploy and maintain the propose W/CMS. Thesuccess of any Web-based system, very much de-pending on how closely these design principles are

Figure 6: W/CMS Subsystems use-case

followed under modelling and design phase of thedevelopment. Here we provide a short summary ofissues which we meant to be pertinence to the fivedesign principles:

Q1 - Usability: Users are the primary reasonwhy a system ever get built, deployed and main-tained. Any system under consideration must aboveall put users requirements as its prime motive forexistence. In a Web-based application, users to thesystem will interact with it using Web browsers.The look and feel of Web pages can be codedusing HTML (HyperText Markup Language), CSS(Cascading Style Sheets) and JavaScript. It is a factthat different Web browsers interpret all HTML,CSS and JavaScript codes differently. To be usefulWeb pages must behave consistently regardless ofwhat type Web browsers are being used. Anotherimportant issue related to usability is error andexception management. Both users and systemerrors should be handled properly with end users inmind. All fatal and non-fatal failures due to database,inter-communication, and system exceptions shouldbe traps and handled meaningfully.

Q2 - Adaptability: Legislature changes allthe time. The same is true to technology. The system



in production, often needs to be redeveloped andredeployed in response to necessary changes. Thereare choices to be made from the very beginningto which tools and architectural models on whichthe production system will be based on, in order tosupport adaptability principle. Subsystems are madeto be open-ended and in conformation to widely usedstandards. To achieve a high level of adaptability, thesystem should be modular both in development anddeployment, by employing independent and looselycouple operational units.

Q3 - Scalability: As the system become widelyknown and has to cater to more users than the initialstage, the scalability will become an issue that need tobe addresses. How well the system can be scaled up isvery much dependent on the underlying architecture.For instance, multiple servers can be deployed tosupport increasing demands. If a system can bedecomposed into independent subsystems, as theW/CMS can be logically and practically split intothree parts as shown in Figure 6, then three differentservers can be employed to deploy the collectivefunctionalities of the whole system. Certain functionscan also be served from multiple servers, when acompletely centralized control is not needed duringday to day operations. Late data synchronisations canbe done as a part of standard routines.

Q4 - Interoperability: A system does not ex-ist on an island, entire of itself; it needs to co-existwith its operational environment. It needs to ac-commodate existing systems and future systemswithin its parent organization and any collaboratingorganizations. Its ecosystem could be far reachingand was not perceived at initial instalment, howeverthe success of survival can very well depend on howwell it is able to communicate with other independentsystems. Most often, the possibilities of introducingmiddle-ware is the only practical way to tackle theproblem of interoperability. In order to do thisdeveloper-maintainer needs the ability and interest tounderstand externals systems. Standardization canhelp a lot.

Q5 - Maintainability: Web pages and forms,operational codes and codes library, and data modelneed to be maintained in response to all the demandsincurred by all the above. Choice of tools andtechnologies are important. Object oriented pro-gramming techniques and open source technologieswill provide maintainer of a system with a betterlevel of maintainability than unstructured codingand legacy technologies. Simple design based onwell understood and stable framework will greatly

contribute to system maintainability. To reduceoperational surprises due to bugs, development andtesting processes must be done in parallel. Wheneverpossible a sandbox environment to the productionsystem should be provided.

2.4 Contract Making Process Flow

Different human actors and their interactions with thesystem are clearly labelled in Figure 6. The three mainsubsystems are:

1. Users Management

2. Contracts Formalization

3. Contracts Finalization

They are modeled to be distributed, cooperativeand loosely coupled independent subsystems. To pro-mote higher security level, these subsystems are de-signed to be operational and administrative indepen-dent of each other. System management responsibil-ities will be given to three non-collaborative teams.These managers will not share administrative secretsand systems’ data.

The users management subsystem manages userregistration. A new user will be given a unique user-name and a self-chosen password, and a pair of RSApublic and private keys. The private key is pro-tected by the user password using a symmetric-keyencryption. The meta data and private key are alsosymmetric-key encrypted by the subsystem and sendover to the user for safe keeping. The user needs toprovide this piece of encrypted text block whenevershe changes her password later on.

The contracts formalization subsystem is the bulkof W/CMS. Each contract is initialized when the re-quest is approved by system managers. Each contractwill be given a standardized individual database. Allcontract data and contract documents will be storedin the database. The negotiation will be conductedamong persons related to the contract in an environ-ment similar to a blog. All events are logged to thisblog by the system software, system managers, co-ordinator and users. The production of the contractsynopsis is done when an agreement is reached by allparties. All parties will be asked to sign the contractsynopsis.

The contracts finalization subsystem constitutesthe finalizing processes for the closing phase of a con-tract. Witnesses will be called by the archiver to verifythe contract synopsis and all participating parties’ sig-natures. The witnesses will then put their signatures



on to the contract synopsis. The archiver will thenverify the contract synopsis, all participating parties’signatures and all witnesses’ signatures, before clos-ing the blog and sealing the contract by putting hersignature to the whole contract synopsis and signa-tures. The signing hierarchy is shown in Figure 7. Thesealed contract package and the blog are encryptedand then securely stored.

Figure 7: Contract Signatures Hierarchy

3 Supporting Tools

3.1 Cryptographic Tools

The proposed system employees three simple, wellknown and widely used cryptographic tools. They are:

1. symmetric-key encryption implemented inBlowfish [13],

2. public-key encryption implemented in RSA [4]public-key cryptography,

3. cryptographic hash functions implemented bySHA [3] hash algorithms.

Blowfish symmetric-key encryption uses a singlesecret key. This key is used for both encryption anddecryption.

Blowfish Encryption scheme:-Encryption βenc:

ciphertext, c = βenc(Ksec, m)

Decryption βdec:plaintext, m = βdec(Ksec, c)

Inverse transformation:m = βdec(Ksec, (βenc(Ksec, m)))

Symmetric-key cryptography is not practical forsecure communication between many persons due tokey distribution and key management problems. Forprivate communications between two persons, one se-cret key is enough, but for more than two, say fourpersons, six keys are needed and everyone must havethree keys each. In fact for n persons, the total num-ber of keys needed are n!/2 × (n − 2)! and each needto keep n − 1 keys.

The utilization of public-key cryptography willsolve these problems since each person needs onlyto have a pair of keys, namely the public and privatekeys. The public key Kpub is readable by all interestedparties while the private key Kprv is kept secret andonly known to the owner.

A public-key cryptographic system dependsheavily on computational complexity theory andnumber theory. RSA is the most well known andwidely used cryptographic system in today’s digitalworld. RSA supports non-symmetric-key crypto-graphic schemes for 1) encryption/decryption; 2)sign/verify; and 3) blind/unblind.

RSA Encryption scheme:-Encryption - ξenc

ciphertext, c = ξenc(Kpub, m)Decryption - ξdec

plaintext, m = ξdec(Kprv, c)Inverse transformation:

m = ξdec(Kprv, (ξenc(Kpub, m)))

RSA Signature scheme:-Signing - ζsig

signature, s = ζsig(Kprv, m)Verification - ζver

verify, v = ζver(Kpub, s)Inverse transformation:

m = ζver(Kpub,(ζsig(Kprv, m)))

The blinding factor ψ is only known to themessage owner. Blind signature is useful whenanonymity is important [2]. Using blind/unblind, asignee can sign the message without knowing what itcontains.

RSA Blind Signature scheme:-Blind - λblind

blind, b = λblind(Kpub, ψ, m)Signing - ζsig

signature, bs = ζsig(Kprv, b)



Unblind - λunblindunblind, s = λunblind(Kpub, ψ, bs)

Verification - ζververify, v = ζver(Kpub, s)

A more detailed discussion on Public-Key Cryp-tography Standards (PKCS) #1 v2.1 by RSA Labo-ratories is presented in RFC3447 [4]. Other interstingworks in that area are shown in [5], [6], [7], [11], [17],[18], and [19]. Their application in systems support-ing eGoverment models is presented in [8], [9], and[15].

3.2 Software Tools

The system can be implemented as a multi-tiers Web-based application, built using free and open sourcesoftware. The users using their Web browsers will in-teract with an Apache [1] Web server using HTTPS(Hypertext Transfer Protocol Secure) communicationprotocol. The programmable environment and themiddlewares are written in Phython [10]. The back-end database can be implemented using SQLite [14].

The Python programming environment is used asintegrating middleware between the Web server front-end and the database back-end. Some of the importantPython packages used to implement the system were:

1. mod python - live-programmable module toApache,

2. Crypto - cryptographic libraries,

3. xmlrpclib - XML-based RPC (Remote ProcedureCall),

4. tlslite - SSL v3 (Secure Sockets Layer) and TLSv1 (Transport Layer Security) libraries,

5. standard Python libraries for examples - Sock-etServer, BaseHTTPServer, sqlite3, base64 andbinascii.

4 System

4.1 System Components

As mentioned earlier in Section 2, the W/CMS canbe broken down into three logically separate subsys-tems as shown in Figure 6. Modelled from these de-compositions, the proposed system will provide thesemain Web user interfaces as shown in Table 2. Then,building on top of these Web interfaces, the sys-tem will support these main operational functionali-ties as shown in Table 3. Utility functions are cou-pled directly to Web interfaces. The codes that imple-

ment these Web interfaces and the utility functions aregrouped into five groups:

1. Web-based interfaces - W?

2. user management - U?

3. session and access controller - S?

4. contract management utilities - C?

5. report, archive and cleanup - R?

Table 2: Web interfaces decomposition of W/CMSsubsystems

Subsystems Web user interfaces

Users W1 registration

ManagementW2 login

W3 changePwd

Contracts W2 login (*)

FormalizationW4 contractReq

W5 contractNego

W6 contractAgre

Contracts W2 login (*)

FinalizationW7 contractWitn

W8 contractClose

W9 reportReq

All user interface functions are labelled with W.The function W2 (login) is shared between all threesubsystems. Behind each W? are utilities functions.Whenever an interface is used by a user, these utilitiesfunctions will get invoked, for example;

W2→ (S1, S2)

(W6, W8)→ C3

These are just a top-level view of the proposedsystem. There are much more functions in theW/CMS than the ones listed in Table 2 and Table 3.



Table 3: Functional decomposition of W/CMS sub-systems

Web user interfaces Utility functions

W1 registration U1 userReg

U2 keyGen

W2 login S1 userSession

S2 authorization

W3 changePwd U3 keyReset

W2 login (*) S1 userSession

S2 authorization

W4 contractReq C1 contractInit

W5 contractNego C2 blogUtil

W6 contractAgre C3 signingUtil

C4 finalize

W2 login (*) S1 userSession (*)

S2 authorization (*)

W7 contractWitn C5 verifyingUtil

W8 contractClose C3 signingUtil (*)

W9 reportReq R1 report

R2 archive

R3 cleanUp

4.2 System Operational Descriptions

Under the registration interface W1 a person will beasked to provide email address. The system will ini-tialize a user in the database and send an activationcode to the previously given email address. Usingthis activation code the person will be able to pro-vide the system with her choice of username andpassword. This will then trigger U1 which will reg-ister user data into the database. The U1 will inturn trigger U2 which will produce a pair of publicKpub and private Kprv keys for the newly registereduser. The private key is encrypted using Blowfish en-cryption with the user’s password as the secret key,Kb f

prv = βenc(pwd,Kprv). The public key Kpub and en-crypted private key Kb f

prv are then securely stored inthe system database. The system will then create auser package, which is an encrypted message pack-age containing user data and the keys, and send thismessage via email to the user for safe keeping.

A registered user can change her password at W3by providing the system with her email address andactivation code. If the system recognizes the givendata the system will then request the user to submit the

old password and a new password, together with theuser’s user package. The system will then execute U3which will decrypt the user package and extract userdata and private key. If the user data is valid then thesystem will decrypt the Kb f

prv using the old passwordand re-encrypt the private key using the new passwordand store them into the database.

To make use of the facilities provided by theW/CMS, users must first authenticate themselves atW2. The two utility functions associated with W2are S1 and S2. The S1 manages users sessions of allcurrently authenticated users. Each user-session con-tains all necessary information about a particular cur-rent session, in particular the user current authoriza-tion and permissions. User-session is directly relatedto session Web-cookie.

The W4 provides Web interface to a contract re-quester and an initiator � for submitting request andapproving for a new contract, respectively. Wheneverthe request is approved, the initiator � must check thatthe provided initial contract data is complete and cor-rect. Related to W4 is C1. The purpose of C1 is

1. to initialize a new database with all the contractobjects and attributes, all participating actors �A

and �P, and

2. to create all the necessary scaffoldings for thenew contract management work.

The contract negotiation will be done in an Webenvironment similar to a blog at W5. The initiator �will function as coordinator and a mediator. All �A

will be given access to contact database and environ-ment. When agreement is reached by all�A, the �willcoordinate the signing and the finalization of the con-tract using the W6. Related to W6 is C3, the signingutility function. When the contract synopsis is pro-duced, an event is triggered on C4.

The C4 will close the contract blog and alert the� and if necessary the witnesses �. By using theinterface W6 the � will function as witness to thecontract synopsis by first verifying the signatures us-ing C5 and then sign using C3. Likewise the archive� will put her seal by signing using C3 to the alreadywitnessed contract synopsis. All important data par-ticular to the contract will be archived by � by in-voking R2 and their traces are deleted using R3. Astandard report is produced by R1 and send via emailto all �A as a receipt.

5 ConclusionA significant part of this paper is devoted to concep-tual discussions on Web-based Contract Management



system. We identified three possible types of con-tracts. With two step user-case diagrams we proposeda system model on loosely coupled system of threemain subsystems. We provide a table showing func-tional components of these subsystems. These func-tions are further decomposed into utility functions thatare logically grouped. All these functions are imple-mented as modules in our prototype implementationof the system.

A combination of cryptographic hash functions(SHA), symmetric-key (Blowfish) and and public-key(RSA) cryptographic tools provided by hashlib andCrypto modules in Python made it possible to easilyimplement hash calculation, encryption/decryption,sign/verify and even blind/unblind. There are sev-eral different cryptographic tools provided by Pythoncryptographic libraries.

For the purpose of providing one database percontract, the SQLite database is more than adequate.Connectivity between Web front-end to SQLite back-end database using sqlite3 is robust and easy to utilize.Blob data type is very useful for storing binary docu-ments. Each SQLite database is implemented as regu-lar file in the operating system, so the whole databasecan be encrypted as any regular file. Other databasesystems may be used instead.

All the software tools used to implement areopen-source and free. The model provides an imple-mentation structure which is open-ended in the sensethat different tools can be freely mixed-and-matched.

How the proposed system measures up against the1) Usability, 2) Adaptability, 3) Scalability, 4) Inter-operability, and 5) Maintainability criteria mention inSection 2.3?

The answers are definitively, ‘yes’ - it measuresup well, on all counts. It is usable since the systemis Web-based. Web-based interfaces are well knownto nowadays average computer users. It is adaptablesince the system is made up of open software com-ponents. Any new functionality can be incorporatedeasily. Subsystems can be implemented on differentservers to provide scalability.

By using standard - HTTP, XML, XML-RPC, thesystem can inter-operate with other systems. Since thesystem is build around subsystems and modular com-ponents, it will promote maintainability under bothdevelopment and deployment.

We can not help but to admire the Kushans peoplefor their ingenuity. With simple and primitive tech-nologies they have shown us the basic principle ofcontract making. What we did is nothing more thanwhat had been done fifteen centuries ago albeit ouradvances in computers and communication technol-ogy.

References:

[1] Apache, The Apache Software Foundation,HTTP server, http://www.apache.org/,2009 (last accessed).

[2] David C., Blind signatures for untraceable pay-ments, Advances in Cryptology - Crypto ’82,Springer-Verlag pp. 199-203, 1983.

[3] FIB PUB 180-3, SECURE HASH STANDARD(SHS), Federal Information Processing Stan-dards Publication, 2008.

[4] Jonsson J., Kaliski B., Public-Key CryptographyStandards (PKCS) #1, RSA Cryptography Spec-ifications Version 2.1 RSA Laboratories, 2003.

[5] Halevi, S., Krawczyk, H., Strengthening DigitalSignatures via Randomized Hashing, Advancesin Cryptology - Crypto 2006, Vol. 4117/2006,Springer Berlin, 2006, pp. 41-59.

[6] Kelsey, J., Schneier, B., Second Preimages on n-Bit Hash Functions for Much Less than 2n Work,Advances in Cryptology - Eurocrypt 2005, Vol.3494, Springer Berlin, 2005, pp. 474-490.

[7] Kovari, B., Albert, I., and Charaf, H., A gen-eral approach to off-line signature verification,WSEAS Transactions on Computers Vol.7, No.10, 2008, pp. 1648-1657.

[8] Lin J., Yu J., and Hsu C., An Ontology-BasedArchitecture for Consumer Support Systems,WSEAS Transactions on Information Scienceand Applications, Vol. 7 (2), pp. 153-165, 2010.

[9] Malek J. A., Informative Global Community De-velopment Index of Intelligent City, WSEASTransactions on Information Science and Appli-cations, Vol. 7 (1), pp. 114-121, 2010.

[10] Python Programming Language,http://www.python.org/, 2009 (last ac-cessed).

[11] Rahman S.M.M., Masum S.M., Khan M.S.I.,Alam M.S., and Hasan M.I., A New MessageDigest Function for Message Authentication,WSEAS Transactions on Computers, Vol. 3 (5),2004, pp. 1466 -1469.

[12] Rivest R., The MD5 Message-Digest Algorithm,MIT Laboratory for Computer Science and RSAData Security, Inc, 1992.

[13] Schneier B., The Blow-fish Encryption Algorithm.http://www.schneier.com/blowfish.html,2009 (last accessed).

[14] SQLite, A self-contained, serverless, zero-configuration, transactional SQL database en-gine, http://www.sqlite.org/, 2009 (lastaccessed).



[15] Simonova S. , Kopackova H., eDocument ineGovernment, WSEAS Transactions on Infor-mation Science and Applications, Vol. 7 (1), pp.92-101, 2010.

[16] Sims-Williams N., Bactrian Doc-uments from Ancient Afghanistan,http://www.gengo.l.u-tokyo.ac.jp/∼hkum/bactrian.html, 2010 (last accessed).

[17] Stinson, D., Some observations on the theory ofcryptographic hash functions, Designs, Codesand Cryptography, Vol. 38 2006, pp. 259 - 277.

[18] Tsang-Yean L. and Huey-Ming, L., Encryptionand decryption algorithm of data transmissionin network security, WSEAS Transactions on In-formation Science and Applications. Vol. 3 (12),2006, pp. 2557-2562.

[19] Tuba M. and Stanarevic N., Relation betweenSuccessfulness of Birthday Attack on Digi-tal Signature and Hash Function Irregularity,WSEAS Transactions on Information Scienceand Applications, Vol. 7 (2), 2010 pp. 186-195.



Date post:	21-Nov-2023
Category:	Documents
Upload:	independent
View:	0 times
Download:	0 times

A Multi Purpose Web-based Contractual Management System

Documents