w/cms: open-ended web-based contract management system

W/CMS: Open-ended Web-based Contract 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: On-line contract management framework provides support to contract process flow without the needfor all actors to be synchronously present in respect to both time and space. Different contractual processes aremanaged by the application securely by analyzing data-flow between actors, ushering actors to perform their dutiesat a timely manner and employing appropriate cryptographic techniques on every step of the way. The implemen-tation 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 Workflow Modelling, Applied Cryptography

1 Introduction

Generally speaking, a contract is a legally bindingagreement 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,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-endedWeb-based Contract Management System (CMS) fordeployment where contractual processes can be donebetween actors using Web-based applications as as-sertive actions and emails as event triggers. Any reg-istered user can initiate a contract procedure. Anyonewith an email account anywhere can register to thesystem. Any of the registered users can be used asa witness. This proposed framework for on-line con-tract management will provide the support of contractprocess flow without the need for the different relatedactors within the process to be synchronously presentwith respect to both time and space. Virtual meetingsare done by message passing via email or Web-baseddrop-box areas and actions are executed or triggeredfor assertion by applications in a timely fashion dic-tated by rule based process flow directives.

A contract can be: unilateral - f.ex. a will, a tes-tament, bilateral - f.ex. a buying and selling agree-ment, or multilateral - f.ex. a project team distribu-tion agreement of roles, responsibilities, and resourcedivisions.

Different types of contracts define different typesobjects and attributes, both contract specific and do-main specific, and these are contract-core objects andcontract-core attributes, and related to these contract-core are domain-specific objects and domain-specificattributes. For a particular contract, these objects andattributes together with contract meta data of hashesand digital signatures will be used to produce a final-ized contract document in what we call a contract syn-opsis. The contract synopsis is represented 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 - Negotia-tion, S3 - Agreement, S4 - Signing, S5 - Archive (aftersealing).

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 will

Proceedings of the 9th WSEAS International Conference on APPLICATIONS of COMPUTER ENGINEERING

ISSN: 1790-5117 87 ISBN: 978-960-474-166-3

provide 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. The implementation mustdeliver a management system that provides opera-tional properties of 1) authentication; 2) privacy; 3)trustworthy; 4) reliable; and 5) verifiable.

2 Background

2.1 Actors’ Roles and Responsibilities

There are five types of human actor identified in theW/CMS. They are labeled as follows: � - Initiator,which also will act as intermediary, coordinator, andoverseer; � - Provider, for example seller and bene-factor; � - Consumer, for example client, buyer andbeneficiary;� - Witness; and � - Archiver.

Figure 1 shows relationships of actors, objects,actions and states. Actors are collected into threetypes of group, 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 �.In order to be a user, a person needs to be registeredto the W/CMS. Each user is given a unique usernameand a password during the registration process.

The username and password will be used for au-thentication during the subsequent interactions withthe system.

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 both

Figure 1: Conceptual CMS use-case

Table 1: Contract type vs Number of WitnessContract type � or � �(min) �(max)

unilateral 1 1 2

bilateral 2 2 2

multilateral ≥ 3 0 0

at 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 provide theW/CMS with supporting documents, conduct negoti-ations and actively agree to the final agreement of thecontract. Potential witnesses, Wk ∈ �, k ∈ [1, l],Wk ,P j will be invited to be witnesses and sign a finalizedagreement. A witness will sign a particular contractblindly or otherwise, depending on the privacy con-straint of the contract. We propose a witness policyplan 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-


ISSN: 1790-5117 88 ISBN: 978-960-474-166-3

ties:P1 - Authenticity: Only registered users are recog-

nized by the system. Users are authenticated prior togranting access to the system. Only eligible users withauthorization corresponding to theirs roles are able toaccess certain parts of the system. Users activities arelogged.

P2 - Privacy: Access to each contract synopsisis controlled by graded privacy level of 1) public, 2)semi-public, 3) semi-private, and 4) private. At apublic level, some or all components of a particularcontract synopsis are accessible by anyone interested.At a semi-public level, some or all components areaccessible only by users of the system. At a semi-private level, some or all components are accessibleto � ∪ � ∪�. Lastly, at a private level, only � ∪ �are granted access to all components of a particularcontract synopsis. Each component can be individu-ally marked as either public or private. The W/CMSprovides many different combinations of access con-trols. When there are conflicts in authorization, thecontract synopsis level takes precedent over the indi-vidual components access flags.

P3 - Trustworthy: All user, �, are real peopleand no two or more users belong to a single person.All contracts documents marked with private flagsare stored in an encrypted forms and only authorizedusers can access and decrypt them. A detailed historyof a particular contract synopsis at any stages is givento �A at any time. The invariant �A ∩ �P = Ø isdiligently checked by � for each � committed to aparticular contract synopsis.

P4 - Reliability: It is not possible to fake signa-ture on a contract. Private keys are protected by users’password whereby only the owner can make use ofthem. Private keys are stored securely in the systemand no one can misuse them even persons with systemmanagers permissions. Only valid� for a particularcontract is allowed to sign as a witness.

P5 - Verifiability: Individual person involved witha particular contract is able to independently verifyany signature within the contact of the contract. Allactivities pertinence to the contract forming processwere log, every piece of items will be connected withtimestamped events in the events history of a particu-lar contract. At the closing phase of the contract boththe contract synopsis and events history will be signedand sealed by the archiver� and stored in a save stor-age area or an off-line media for example an encryptedCD (compact disk).

2.3 Design Principles

Effective design connects acting to thinking which inturn connects implementation to formulation. To be

effective a design need 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 contractmanagement, must above all, be usable, adaptable,and manageable. The system users interfaces andwork flows must conform to users needs and expec-tations, logically laid out and simple to understand.There should not be any ambiguities. Regulationsregarding different aspects of contract making willchange with time, so the system needs to adapt to thecurrent regulatory demands. To be agile and respond-ing to changes, the system and its subsystems need tobe managed with manageable interfaces. Therefore,in this paper we propose an open-ended Web-basedcontract management system guided by these five de-sign principles: Q1 - Usability, Q2 - Adaptability, Q3- Scalability, Q4 - Interoperability, Q5 - Manageabil-ity.

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.

Figure 2: W/CMS Subsystems use-case

From the conceptual use-case diagram of Fig-ure 1 and the three phases mentioned in Section 1, theworking model of the W/CMS can be decomposedinto three separate subsystems as shown in Figure 2,which represents a simplified version of process flowschematic of the whole system.

2.4 Contract Making Process Flow

Different human actors and their interactions with thesystem are clearly labelled in Figure 2.

The three main subsystems are 1) users manage-ment; 2) contracts formalization; and 3) contracts fi-nalization. They are modeled to be distributed, coop-erative and loosely coupled independent subsystems.To promote higher security level, these subsystems are


ISSN: 1790-5117 89 ISBN: 978-960-474-166-3

designed to be operational and administrative inde-pendent of each other. System management responsi-bilities 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 RSA[8] public 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, coor-dinator and users. The production of the contract syn-opsis is done when agreement is reached by all parties.All parties will be asked to sign the contract synopsis.

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 signatureson 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 3. Thesealed contract package and the blog are encryptedand then securely stored.

Figure 3: Contract Signatures Hierarchy

3 Supporting Tools

3.1 Cryptographic Tools

The proposed system employees three simple, wellknown and widely used cryptographic tools. They are1) symmetric-key encryption implemented in Blow-fish [9]; 2) public-key encryption implemented inRSA [3] public-key cryptography; and 3) crypto-graphic hash functions implemented by SHA [2] hashalgorithms.

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 communication between two persons, one se-cret key is enough, but for more than two, say fourpersons, then six keys are needed and everyone musthave three keys each. In fact for n persons, the totalnumber of keys needed are n!/2 × (n − 2)! and eachneed to 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 [8] is the most well knownand widely used cryptographic system in today’sdigital world. RSA supports non-symmetric-keycryptographic 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:-


ISSN: 1790-5117 90 ISBN: 978-960-474-166-3

Signing - ζsigsignature, s = ζsig(Kprv, m)

Verification - ζververify, 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 [4]. 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 - λunblind

unblind, s = λunblind(Kpub, ψ, bs)Verification - ζver

verify, v = ζver(Kpub, s)

Please refer to RFC3447 [3] for a more de-tailed discussion on Public-Key Cryptography Stan-dards (PKCS) #1 v2.1 by RSA Laboratories.

3.2 Software Tools

The system is implemented as a multi-tiers Web-basedapplication, built using free and open source software.The users using their Web browsers will interact withan Apache [1] Web server using HTTPS (HypertextTransfer Protocol Secure) communication protocol.The programmable environment and the middlewaresare written in Phython [6]. The back-end database isimplemented using SQLite [5].

The Python programming environment is used asintegrating middleware between the Web server front-end and the database back-end. Some of the impor-tant Python packages used to implement the systemwere 1) mod python - live-programmable module toApache; 2) Crypto - cryptographic libraries; 3) xmlr-pclib - XML-based RPC (Remote Procedure Call); 4)tlslite - SSL v3 (Secure Sockets Layer) and TLS v1(Transport Layer Security) libraries; and 5) standardPython libraries for examples - SocketServer, Base-HTTPServer, sqlite3, base64 and binascii.

4 System

As mentioned earlier in Section 2, the W/CMS can bebroken down into three logically separate subsystems

as shown in Figure 2. Building on top of these de-compositions, the proposed system will support thesemain operational functionalities as shown in Table 2.

Table 2: Fuctional decomposition of W/CMS subsys-tems

Subsystems Web user interfaces Utility functions

Users W1 registration U1 userRegManagement U2 keyGen

W2 loginW3 changePwd U3 keyReset

Contracts W2 login (*) S1 userSessionFormalization S2 authorization

W4 contractReq C1 contractInitW5 contractNego C2 blogUtilW6 contractAgre C3 signingUtil

C4 finalizeContracts W2 login (*) S1 userSession (*)

Finalization S2 authorization (*)

W7 contractWitn C5 verifyingUtilW8 contractClose C3 signingUtil (*)

W9 reportReq R1 reportR2 archiveR3 cleanUp

These functions are of five types 1) Web-basedinterfaces - W?; 2) user management - U?; 3) sessionand access controller - S?; 4) contract managementutilities - C?; and 5) report, archive and cleanup - R?.

Under the registration interface W1 a person willbe asked to provide email address. The system willinitialize a user in the database and send an activationcode to the provided email address. Using this activa-tion code the person will be able to provide the sys-tem with her choice of username and password. Thiswill then trigger U1 which will register user data intothe database. The U1 will in turn trigger U2 whichwill produce a pair of public and private keys for thenewly registered user. The private key is encryptedusing Blowfish encryption with the user’s password asthe secret key. The public and encrypted private keysare then securely stored in the system database. Thesystem will then create a user package, which is anencrypted message package containing user data andthe keys, and send this message via email to the userfor 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 anew password together with the user’s user package.The system will then execute U3 which will decryptthe user package and extract user data and private key.If the user data is valid then the system will re-encryptthe private key using the new password and store them


ISSN: 1790-5117 91 ISBN: 978-960-474-166-3

into the database.To make use of the facilities provided by the

W/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 initiator � for submitting request and ap-proving 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) toinitialize a new database with all the contract objectsand attributes, all participating actors�A and�P, and2) to create all the necessary scaffoldings for the newcontract 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 blog Web environment andalert the � and if necessary the witnesses�. By us-ing the interface W6 the � will function as witnessto the contract synopsis by first verifying the signa-tures using C5 and then sign using C3. Likewise thearchive � will put her seal by signing using C3 tothe already witnessed contract synopsis. All impor-tant data particular to the contract will be archived by� by invoking R2 and their traces are deleted usingR3. A standard report is produced by R1 and send viaemail to all �A as a receipt.

5 ConclusionA significant portion of this paper is devoted to con-ceptual discussion on Web-based Contract Manage-ment system. We identified three possible types ofcontracts. With a two step user-case diagrams we pro-pose a system model on loosely coupled system ofthree main subsystems. We provide a table showingfunctional components of these subsystems. Thesefunctions are further classified into a logical purposes.All these functions are implemented as modules in ourprototype implementation of 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 otherand 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 mix-and-match.

References:

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

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

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

[4] Chaum David, Blind signatures for untraceablepayments, Advances in Cryptology - Crypto ’82,Springer-Verlag pp. 199-203, 1983.

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

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

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

[8] R. Rivest, A. Shamir & L. Adleman, A Methodfor Obtaining Digital Signatures and Public-KeyCryptosystems, Communications of the ACM,21 (2), pp. 120-126, 1978.

[9] B. Schneier, The Blowfish Encryption Algorithm.http://www.schneier.com/blowfish.html,2009 (last accessed).


ISSN: 1790-5117 92 ISBN: 978-960-474-166-3

w/cms: open-ended web-based contract management system

Documents