Dynamic and Secure B2B E-contract Update Management Samuil Angelov
Sven Till
Paul Grefen
Information Systems Group Faculty of Technology Management Eindhoven University of Technology P.O. Box 513, 5600 MB, Eindhoven The Netherlands (+31) 40 2475743
Information Systems Group Faculty of Technology Management Eindhoven University of Technology P.O. Box 513, 5600 MB, Eindhoven The Netherlands (+31) 40 2473205
Information Systems Group Faculty of Technology Management Eindhoven University of Technology P.O. Box 513, 5600 MB, Eindhoven The Netherlands (+31) 40 2475650
[email protected]
[email protected]
[email protected]
ABSTRACT Business-to-business electronic contracts provide a specification of the agreed value exchange and guarantee legal protection to companies during electronic trading relations. Important features that distinguish e-contracts from traditional paper contracts are the possibilities for automatic establishment and enactment, the more detailed e-contract content specification and the frequency of e-contract content updating. In this paper, we discuss these e-contract features and the technology requirements to which they lead. We describe two conceptual architectures for the support of updates in digitally signed e-contracts. We demonstrate that the straightforward approach is inefficient and therefore inadequate for supporting high update rates in an automated, dynamic, communication-intensive contract enactment environment. The second approach that we describe allows companies to handle e-contract updates in a more efficient and simplified manner. It introduces a new type of Trusted Third Party that can be used for the support of e-contract updates. This paper provides the required conceptual foundation for the construction of an important part of an e-contract management system.
Categories and Subject Descriptors H.4.m [Information Systems Applications]: Miscellaneous.
General Terms Management, Performance, Design, Security, Legal Aspects.
Keywords E-commerce, e-contract, e-contract management, e-contract signing, e-contract update.
1. INTRODUCTION In electronic business-to-business trading relations, companies need protection mechanisms that guarantee the proper exchange of values or the performance of compensation activities when Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.. EC’05, June 5–8, 2005, Vancouver, British Columbia, Canada. Copyright 2005 ACM 1-59593-049-3/05/0006…$5.00.
values cannot be exchanged as agreed. As in traditional business relations, electronic contracts are employed to provide a legally enforceable protection mechanism to parties. Electronic contracts (e-contracts) contain a specification of the agreed value exchange, the processes and the conditions for this exchange, and the legal protective mechanisms for the trading parties. Depending on the level of automation pursued in e-contract enactment and management, e-contracts can be seen only as digitalized paper contracts [16] (i.e., they have only a human readable representation and cannot be automatically interpreted, enacted or managed by an e-contracting system) or as a “software reification” of paper contracts [19] (i.e., they can be automatically interpreted, enacted or managed by the supporting e-contracting systems). We call the first type of e-contracting “shallow e-contracting” and the second type “deep e-contracting” [3]. In this paper, we concentrate on e-contracts used in deep e-contracting, i.e., e-contracts that have a machine-interpretable content representation and that can contain additional software related specifications required for their fully or partially automatic enactment and management. Deep e-contracting is needed in domains with dynamic business settings (e.g. market places). Furthermore, in certain domains (e.g. advertising [3]), it can lead to a shift from long-lasting and static to highly dynamic business relations. In existing research work, less attention has been paid to the differences between the content of paper and electronic contracts, and the consequences of these differences on the supporting architecture. E-contracts have two major characteristics that distinguish them from paper contracts. They have a more detailed content description and contain e-contract specific data. E-contracts require a more detailed content description, as they have to be automatically interpreted and enacted. Enactment software requires a clear, structured, and detailed description of the activities to be performed and the conditions for the contract enactment. E-contracts contain specific data due to the technological environment for their enactment. For example, e-contracts can contain parameters defining workflow data exchanged between parties [15]. These workflow data parameters will change or receive their values during e-contract enactment. As can be seen from this example, an important consequence of this e-contract characteristic is that the values of certain e-contract specific elements will often be updated during contract enactment. Handling of e-contract updates requires the appropriate support by the e-contract management system. Few efforts on the description of a conceptual reference architecture of a deep
e-contracting system exist (e.g., [18], [5], [2]). However, while these efforts take one (or both) of the e-contract characteristics into consideration, they do not pay attention to the fact that updating of e-contracts can occur much more frequently than in traditional paper contracting. In these research efforts, e-contract updates are based on the usage of a straightforward approach of changing and re-signing of the e-contract. However, this is an expensive process in terms of computing and communication. As we show in the sequel of the paper, this straightforward approach cannot address the requirements of frequent e-contract updates in deep e-contracting. In this paper, we provide a description of a conceptual architecture for the support of e-contract updates during contract enactment. First, we briefly describe the basic constructs required for an e-contract specification. Next, we discuss the specific e-contract features that distinguish them from paper contracts and the requirements that follow from them on the e-contract content and contract management. Based on the identified requirements, we describe two possible approaches for management of contract updates, viz. the “Multiple Signing” and the “Dynamic Update” approaches. The two approaches are based on existing business practices for updates of traditional paper contracts. These business practices are tailored in order to reflect the use of information systems for the support of automated e-contracts updates. For both approaches, we describe the required conceptual architectural components for their support. We show that in automated, dynamic, communication-intensive enactment e-contract relations, the “Multiple Signing” approach is not suitable for handling of e-contracting updates, while the “Dynamic Update” approach offers an efficient and simple handling of e-contract updates. In addition, we show that in the Dynamic Update approach, companies can make use of a new type of a Trusted Third Party, namely, the Trusted Updater. Trusted Updaters allow companies to completely outsource the e-contract updating process, thereby minimizing the computational and communication burden in a company caused by e-contract updates. Furthermore, Trusted Updaters increase the trust between parties during contract enactment by easily detecting and refuting fraud attempts of e-contract manipulation. By implementing the Dynamic Update approach, companies can efficiently handle e-contract updates. This approach allows companies to support the automated enactment of a high number of e-contracts and to implement and react in time to numerous e-contract updates. The paper is structured as follows. In Section 2, we discuss the e-contract specific characteristics and the consequent requirements on the e-contract content and e-contract management. In Section 3, we present the two architectures for e-contract updates and discuss their advantages and disadvantages. In Section 4, existing research work on support of e-contract updates is discussed. The paper ends with conclusions.
2. ON E-CONTRACTS In this section, first, we briefly introduce e-contracts and the basic constructs used for their content specification. Next, we show the specific features of the e-contract content in contrast to the content of traditional paper contracts.
2.1 E-contract Constructs In business relations, business contracts specify the exchange of values among business parties and the conditions for the exchange [21]. The conditions are often referred to as contract provisions. We use this general view on the contract content to define three fundamental classes of language constructs required in an e-contract specification language. A detailed description on e-contract language constructs can be found in [4]. The exchanged values between contracting parties can be products or/and services. A product is characterized by its qualities (e.g., size, weight) and quantity. A service is characterized by its qualities, quantity, as well as the steps that must be undertaken for the service delivery. Often, the exchange of a product includes the product delivery. In this case, it becomes a hybrid exchange (a product combined with a service). To define the properties of the exchanged values (qualities and quantity), data specification constructs are required. Data specification constructs allow capturing any property of the exchanged values. To define the steps for the service delivery, process specification constructs are required. To define the contract provisions in an e-contract, rule constructs that can capture the conditions for the product exchange and for the legal protection mechanisms are required. Finally, we can conclude that from the perspective of traditional paper contracts, at least three constructs are required for the specification of e-contracts, viz. data constructs, process constructs, and rule constructs. Next, we discuss the additional, e-contract specific data that must be recorded in e-contracts and its representation through the e-contract language constructs.
2.2 E-contracts: Detailed and Extended In contrast to paper contracts, where often details are omitted or provisions are vaguely defined, the e-contract content has to be specified in a detailed, clear, and formal way. This requirement follows from the requirement e-contracts to be fully (or partially) automatically executed. Without the intuition, common sense knowledge, and context adaptability of humans, an e-contract enacting information system requires a precise definition of the possible scenarios and activities to be performed, information to be exchanged, and rules to be observed during contract enactment. During contract enactment, contracting parties communicate to each other various information related to the contract enactment (“enactment information”). For example, they can inform the counterparty of a contract violation, request an update on the progress of the service delivery, request change of the delivery date, etc. In traditional paper contracts, some of the enactment information and processes are described in the contract (in the form of data definitions, or as part of provision or process specifications), whilst others are omitted in the contract content and are only performed/communicated among the parties when and if needed. In the examples given above, the specification of the event of contract violation will be included in contracts together with a number of rule and process specifications that describe the handling of contract violations, whilst the request for information on the progress of the service delivery will usually not be included in the contract though this activity will take place. The information on the progress update will be exchanged among
humans in a person to person non-formal conversation. In econtracting, due to the requirement for automatic e-contract enactment, parties must agree on the enactment information and processes during the e-contract establishment. In order to guarantee legal protection for companies from repudiation of the agreed enactment information and processes, it has to be included in the e-contract content as well. Thus, compared to paper contracts, e-contracts are extended with the enactment information and process specifications. As e-contracts are interpreted and executed by software, part of this information will be required for the operation of the e-contract enactment and management systems (e.g., the agreed communication protocol, encryption standards). Consequently, an e-contract is a more detailed and unambiguous specification of the paper contract and is extended with the process and information specifications related to the enactment of the agreement.
2.3 E-contracts: Changing In business contracting relations, it happens that companies have to apply changes to the agreed contract during its enactment. For example, a company might like to change the product delivery address stated in the contract. In traditional paper contracting, small changes are applied manually on the paper contract itself or in a contract appendix (called subsidiary arrangement or side letter). Changes that lead to significant deviations from the agreed contract lead to contract re-negotiation and re-signing. Similar to paper contracts, e-contracts can also be subject to updates. More importantly, due their nature, e-contracts can undergo updates more often than paper contracts. As we have shown, e-contracts have a more detailed and extended content than paper contracts. This leads to the need of inclusion of information that must be updated more often. For example, the explicit specification of agreed communication delay times might have to be often updated due to network changes or network unstableness. The extended and detailed characteristic of econtracts is one of the reasons why e-contracts are updated more frequently. In contrast to paper contracts that require human involvement for any change to take place, e-contracts provide the possibility for automatic e-contract updates. This stimulates the definition in e-contracts of contract elements that undergo frequent changes of their values. For example, the value of a fee for an optional service that is not included in a paper contract because of its possible variation can be included in e-contracts and updated automatically if necessary. The possibility for automated updates is the second reason e-contracts to undergo updates more frequently than paper contracts. Thus, we can conclude that during contract enactment e-contracts will change more often than paper contracts. Consequently, to address the higher number of e-contract updates, an e-contracting management system must be able to handle updates in an efficient and reliable way. In Table 1, we present two dimensions of contract updates. The first dimension is based on the predictability property of contract updates. We identify two classes of updates in this dimension, i.e., anticipated updates (updates that were anticipated during contract establishment) and exception updates (updates that were not anticipated during contract establishment). The second dimension is based on the protocol required for performing an update. In this
dimension, we distinguish four classes of updates. Free updates are those updates that can be applied on the contract content without obstructions and limitations from the counterparty. For example, a URL address stated in the contract for obtaining a negotiated resource (a web-service, a digital product) can be updated at any time by the party running the server. For the counterparty this update is of importance for the proper obtaining of the resource but it will not lead to any changes in its business processes. Rule governed updates are updates that can be applied or disallowed based on the rules provided in the contract. Acknowledgment updates are updates that require the explicit acknowledgement from the counterparty (can be seen as a one step negotiation updates). Re-negotiation updates require multi-step negotiations for a contract update. Any of these four contract update classes can be anticipated during contract establishment, and can be reflected correspondingly in the contract content. Exception updates cannot be anticipated during contract establishment and consequently their handling cannot be agreed upon in advance. Thus, exception updates can be handled solely by a one step re-negotiation (acknowledgement updates) or by multi-step re-negotiations. In this paper, we discuss all contract update classes that do not require re-negotiation (denoted with “X” in Table 1). Table 1. Contract update classes Update class
Anticipated
Exception
Free updates
X
Rule governed updates
X
Acknowledgement updates
X
X
Re-negotiation updates
--
--
In deep e-contracting, all anticipated updates must be identified and stated as such in the e-contract. Anticipated rule governed updates are accompanied by e-contract rules that can be automatically evaluated and that indicate at any point in time if the change is currently allowed. Anticipated acknowledgment and re-negotiation updates are only indicated as such and are handled appropriately by the contract management system. Exception updates are handled in an escalating manner. First they are attempted to be resolved as acknowledgment updates, and if unsuccessful they are handled as re-negotiation updates. In deep e-contracting, anticipated, not re-negotiation updates are handled automatically. Depending on the intelligence of the supporting contract negotiation system, re-negotiations can be handled manually, semi-automated, or fully automated.
2.4 E-contracts: Element Ownership In Section 2.3, we have shown that in e-contracts the value of certain e-contract elements can change. Next, we introduce the concept of e-contract element ownership. The reason to introduce element ownership is that the need for an e-contract change can be observed either by only one of the parties or by both parties. When a change of the value of a contract element is observable only by one of the parties, this
party has the responsibility for informing the counterparty for the need of an e-contract update (recall the update of the URL address example from Section 2.3). When the change can be observed by several parties, they have a shared responsibility for the detection of the need for change. By stating the owner of a data element, the parties explicitly state the empowered and responsible for the detection of the need of an update and for the update itself. Three classes of ownership of updatable contract elements exist, i.e., own contract elements, counterparty contract elements, and common contract elements. The following general rules on e-contract elements updates apply: •
Own contract elements can be changed. The element owning party is responsible for the performance of the change.
•
Counterparty owned contract elements cannot be changed.
•
Common contract elements can be changed by both parties. If disagreement occurs, respective contract dispute resolution measures are undertaken.
Thus, e-contract elements must contain information about their owner. Based on the information about the ownership of an element, a request for an e-contract change can be automatically evaluated as valid or invalid.
3. AN ARCHITECTURE FOR THE SUPPORT OF E-CONTRACT UPDATES In e-contracting, successfully negotiated e-contracts have to be electronically signed by the contracting parties. In the European Directive on electronic signatures [12], a legal framework for implementation of electronic signatures in the European Union is delivered. The framework sets requirements on electronic signatures that must be implemented for their legal recognition. Digital signatures based on public/private cryptographic keys ensure authentication (i.e., they guarantee the genuine identity of the signing party), integrity (i.e., the signed contract was not altered after its signing), and non-repudiation (i.e., they prevent the possibility for denial of the document signing from the counterparty) [23]. Digital signatures based on asymmetric cryptography (public/private keys) satisfy the requirements set in the European Directive on “advanced electronic signatures” and can be implemented for legally recognized signing of e-contracts [1]. An important observation that must be mentioned is that besides e-contracts, all outgoing communication messages have to be digitally signed as well. In this way authenticity of the originating party, integrity of the message, and non-repudiation of the message content are guaranteed. As in traditional paper contracting, in e-contracting, each party possesses a copy of the agreed e-contract, signed by all contracting parties. We call the electronic contract agreed upon and signed by all parties the Master Contract (MC). Depending on the parties’ preferences, a copy of the signed e-contract can be stored at an e-notary as well. In Figure 1, we depict the digital signatures of the MC as a striped box attached to the bottom of the Master Contract. As the number of parties does not influence the conclusions reached in the paper, for simplicity, we consider the number of contracting parties to be two. Multiparty scenarios are only briefly discussed with an illustrative purpose.
Company B
Company A MC
E-notary
MC
MC
Figure 1. Owners of a MC Similar to traditional paper contracting where any change to the contract requires its re-signing, any change to a digitally signed e-contract makes the e-contract signature invalid and requires its re-signing. This is due to the nature of digital signatures that are based on a hashed version of the document to be signed [6]. Consequently, any change in the document leads to a different hash value and makes the signature invalid. However, as we have shown in Section 2.3, e-contracts will often be subject to a considerable amount of changes during their enactment. In this section, we discuss two possible approaches to handle changes in e-contracts and the conceptual architecture for each approach. We elaborate on the advantages and drawbacks of the approaches.
3.1 The Multiple Signing Approach The first possible approach to handle a change in an e-contract is straightforward. When a change to an e-contract must be made, a party sends a request for a change to the counter party (see Figure 2 step 1). If the request is approved, the counterparty (company B) sends an agreement for the change (the two steps can be replaced by a single information message in the cases of free updates). Then the requesting party (company A) makes the change in the e-contract, signs it digitally and sends it to the counterparty (steps 3, 4, and 5). The counterparty checks if the newly proposed e-contract complies with the previous one including the proposed change, signs it and sends it to the enotary (steps 6, 7 and 8). When the e-notary receives the document signed by both parties, it verifies the signatures of the parties, signs the e-contract, and sends it to both parties (steps 9, 10, and 11). After the completion of step 11, the e-contract update is successfully completed and companies A and B can make use of the new, updated e-contract. In step 8, company B can directly send the new e-contract signed by both parties to company A, and steps 9, 10, and 11 can be omitted. However, the involvement of an e-notary is highly recommended. It protects company A from fraud attempts by company B. Omitting the e-notary allows company B to make use of the signed e-contract by company A without returning the econtract with its own signature (claiming falsely that it did send the signed e-contract). By including a clause in the e-contract that states the requirement for a signature from the e-notary as well, companies are guaranteed that an updated e-contract becomes operational only when it has been signed by all parties. Another important benefit from the use of e-notaries is that the updated econtract comes into force synchronously at both contracting parties.
Every updated e-contract explicitly states the non-validity of its predecessor. For backtracking and enactment evaluation purposes, the performed update and the time of updating are recorded in a local log at each company. The previous versions of the MC have to be stored internally as well. As in this approach every change requires the re-signing of the e-contract, we call it the “Multiple Signing” approach.
Company A MC
1. Request for change 2. Agreement for change
Company B MC
5. Send document 6. Check
3. Change
7. Sign
4. Sign
8. Send doc
9. Verify signatures
E-notary
10. Sign e-contract 11. Send e-contract
MC
Figure 2. The Multiple Signing approach In case of multiparty e-contracts with N involved parties (where N>2), the protocol for an e-contract update is analogous to the two party scenario. First, the parties have to agree on the proposed change. Next, the requesting party signs and sends the changed document to all parties. Each party has to sign the new document and send it to the e-notary. The e-notary verifies the signatures and the number of signing parties and if all parties have signed the document, it composes the final e-contract that contains the signatures of all parties, signs it, and sends it to all parties.
We focus solely on the burdens on the contracting parties, excluding the burden for the e-notary. Our assumption is that an e-notary has a dedicated infrastructure, handling effectively encryption and communication loads. In contrast, contracting parties use lighter information systems where the computational and communication load caused by e-contract updates can influence the overall system performance considerably. Next, we start with a description of the computational load imposed on the parties and continue with a discussion on the communication load. To ensure authenticity, integrity, and non-repudiation, e-contracts have to be signed using digital signatures based on asymmetric cryptography, also popular as public/private key technology. However, the process of digital signing is computationally very expensive. The digital signing activity consists of two steps, i.e., hashing of the document, and signing of the hash result. Results presented in [6] show that the time required for digital signing a document is in the magnitude of milliseconds depending on the size of the document. As for an e-contract update there will be two digital signings at each party (one for signing of the request/agreement message, and one for signing of the updated e-contract), we have to multiply the time for digital signing by two. Next, we have to add the time for the e-contract update (step 3) or for e-contract checking respectively at the counterparty (step 6), as well as the encryption of the content of the two communications originating from each party. Symmetric cryptography techniques, which are computationally much less expensive, can be used for the encryption of the digitally signed messages [23]. However, even by using symmetric cryptographic techniques the computational effort is not negligible. The time for performing message encryption and decryption is highly dependent on the used algorithm and the document (message) size. It suffices to say that it varies from milliseconds for small documents to several seconds for large documents. A detailed discussion on time required for encryption using symmetric cryptography can be found in [22]. Table 2, based on results from [6] and [22], gives the computational complexity of the signing and (de-) encrypting activities for e-contract updates and estimations about the absolute running time of these activities (where “n” stands for the size of the document). Table 2. Complexity of digital signing and (de-) encryption1
The Multiple Signing approach has one major deficiency. It imposes significant computational and communication burdens on the contract management system, especially in the management of a high number of e-contracts and/or e-contracts of large size. In total, this approach requires from both contracting parties: •
Four encrypted communication messages (the request for a change, the agreement to the request, and the sending of the signed updated documents);
•
Four digital signatures - two signatures for the new e-contract and two for the request and agreement for change (required to guarantee non-repudiation by any of the parties);
•
One change in the e-contract;
•
One e-contract checking.
Activity
Complexity and time estimations
Document hashing
O (n) ranging from µs to ms
Digital signing of the hash
O (1) in the magnitude of ms
Symmetric (De-)Encryption
O (n) in the magnitude of ms
In addition to the computational burden the system has to stand a communication burden as well (see steps 1, 2, 5, and 8 in Figure 2). The weight of the communication burden is directly 1
The complexity O (1) refers to a constant-time method. O (n) indicates a linear-time method.
related to the size of the exchanged messages and e-contracts. The time for communication activities can vary from several milliseconds to several seconds. It heavily depends on the size of the exchanged messages and the communication characteristics of the system such as available bandwidth or used network topology. Although we ignore additional computational effort required for checking, reading, and storing of e-contracts, we can conclude that the simultaneous update of 1000 e-contracts can take several seconds at each party side. While 1000 contracts is a huge number for traditional paper contracts, due to the support of micro business relations, in e-contracting this number will be common even for small businesses [3]. As an event that occurs can affect many e-contracts, we can envision the need of updating huge number of e-contracts at the same time. Thus, in the Multiple Signing approach, we can expect that in order to update all econtracts affected by an occurred event in the related e-contracts, the contract management system will be busy updating e-contracts for several seconds unable to handle the occurrence of a new change during this time. Consequently, this approach is only suitable for less contract intensive businesses, with small number of contract changes.
3.2 The Dynamic Update Approach To circumvent the need of re-signing an e-contract after every update, we propose a second approach. The approach is based on the use of a Contract Copy (CC) by each contracting party. A CC is a local (for the company) instantiation of the MC. When instantiated after the e-contract establishment, a CC is a complete copy of the MC, excluding the digital signatures of the contracting parties (see Figure 3). As the CC is not a signed document, it allows changes to be easily applied to it. In this way, when a change must be made in the e-contract, the parties can simply make the change in the CC, without the need for signing and exchanging the signed e-contract. As in this approach changes can be applied in a dynamic way, we call it the Dynamic Update approach.
apply the change on the CC (step 6). After the change has been made, the enactment and management systems can immediately make use of the updated version of the CC. Both parties locally keep the SA signed by all parties and the e-notary. As in the MS approach, the involvement of an e-notary is optional. When used, an e-notary again guarantees that both parties have signed and received the SA. It allows also synchronization of the update of the CC at both parties. In case of multiparty e-contracts, the approach is analogous to the two-party scenario. First, the update requesting party sends the unilaterally signed SA to all parties. Each of the parties signs the SA and sends it to the e-notary. The e-notary composes a SA signed by all contracting parties, signs it, and sends it back to all contracting parties.
1. Request for change Company A
Company B
2. Send signed request
CC CC CC CC
6. Change
CC CC CC CC
6. Change
MC
MC
SA SA SA SA
SA SA SA SA
3. Verify signatures MC
CC
4. Sign SA 5. Send SA
E-notary
MC
SA SA SA SA
Figure 3. The CC document
Figure 4. The Dynamic Update approach
Similar to the Multiple Signing approach, in order to apply a change on the CC, the party that wants to update the e-contract (company A) sends a request for change to the counterparty (see Figure 4). The request contains a statement for the non-validity of the last value of the element to be updated, and its newly proposed value. In correspondence to the traditional legal and business practices, we call the “request for update” message a Subsidiary Arrangement (SA). If company B agrees to the proposed change, it signs the received request and sends it to an enotary. The e-notary verifies the signatures of the two parties in the request for change (step 3), signs the request (step 4), and sends it back to both parties (step 5). As soon as the parties receive the request for change signed by the e-notary, they can
This approach has an analogue in the current business contracting practices. In certain businesses, instead of changing and resigning an existing paper contract, companies issue subsidiary arrangements (also called side-letters) to the existing contract. The subsidiary arrangements refer explicitly to the existing contract and are signed by all contracting parties that are part of the original contract. This provides the required legal protection to companies. However, e-contracts have to be easily and efficiently accessed by the contract enactment and management systems. For this reason, we add the CC document, which represents the current e-contract state in a straightforward form for processing and interpretation. Thus, the MC and the Subsidiary Arrangement have a legally protective function, while
the CC is required from an operational management perspective. An older version of the CC (if necessary) can be reconstructed by using the MC and the list of established Subsidiary Arrangements. Similar to the Multiple Signing approach, the messages are signed using asymmetric cryptography. Symmetric cryptography (being computationally less expensive) is used for the message encryption. The Dynamic Update approach is significantly less expensive in terms of computing and communication. It requires by both parties the exchange of only two encrypted and signed messages. In contrast to the Multiple Signing approach, the most computationally demanding activities of signing, checking, and encrypting the complete e-contracts are omitted. The storage requirements are smaller as well. In the Dynamic Update approach, only the Subsidiary Arrangements are stored locally, which require less storage space than the archived Master Contracts stored in the Multiple Signing approach. The communication burden caused by using an e-notary is equal in both approaches. Another important advantage of the Dynamic Update approach is the possibility to initiate the procedure of a new update while other updates are still waiting for the approval of the counterparty or the e-notary. Thus, the Dynamic Update approach allows parties to efficiently handle numerous changes in high number of e-contracts, without compromising security and trust issues, minimizing the usage of computational, storage, and network resources. The disadvantage of the Dynamic Update approach is the lack of readily available complete legally valid MC. It has to be reconstructed based on the initial MC and the applied SA. In this approach, the main challenge is to guarantee the sameness of the CC at the two parties at any moment. The first way to address this problem is to rely on the parties’ self-control for implementing the changes on the CC. In case of dispute, the MC together with the Subsidiary Arrangements can be used as a legal proof for the failure of a party to apply a change or for a fraud attempt (as all Subsidiary Arrangements and the MC are digitally signed). The shortcoming is that this scenario is only reactive to a committed fraud. The second way to address the problem is the involvement of third parties. We discuss the involvement of third parties in Section 3.4.
3.3 The Updating Components in an E-contracting Architecture In Sections 3.1 and 3.2, we have discussed two approaches for handling e-contract updates. Next, we discuss the architectural components that are required for the support of updates in each of the approaches. The presented architectural components for each approach are part of a general e-contracting architecture and they make use of a number of components of this architecture (e.g. the messaging support component). As these interactions are not of importance to the updating architecture, we do not show them in the figures. We start with the architecture for the support of the Multiple Signing approach. In the Multiple Signing approach, updates can be requested by the counter party or by an internal application, e.g., the contract enactment system, the contract management system (see Figure 5). Before implementing an update, every request for an update must be verified. Clearly, external requests for updates must be verified in order to prevent non-agreed e-contract updates.
Internal requests must be verified as well, as they can be generated by humans, who are prone to intentional or unintentional mistakes, and by various internal enactment applications, which do not necessarily have to be aware of the contract content. The verification process includes a check if the requester is an owner of the element to be updated and if the updating rules allow this update. The Verifier component supports verification of requests for e-contract updates. If the request for update is approved by both parties, the update on the MC is applied through the Updater component of the party that is the owner of the element (in case of multiple owners the update is performed by the initially requesting party). The updated e-contract is signed and sent to the counterparty. The Updater and Verifier components provide means for easy, centralized rights management for updates of an e-contract. An e-contract signed by the update requesting party is checked for compliance with the agreed change by the Checker component. If the check is successful, the e-contract is signed by the second party as well and is sent to the e-notary for legal establishment. The updated e-contract approved by the e-notary is stored locally at each party. If the parties omit the usage of an e-notary, after the new e-contract is signed by the second party, it is stored locally and is directly sent to the counterparty.
Updater
Verifier
Internal application
MC
Checker
Counterparty application
MC storage, archived MC, update log
E-notary application
Figure 5. E-contract updating architecture in the Multiple Signing approach In the Dynamic Update approach (see Figure 6), the Verifier and Updater components perform the same functions. When the Verifier component receives a request for change from the counterparty, it verifies the request and, if the request is approved, signs it and sends it to the e-notary. The e-notary signs it and sends the final SA to both parties. Upon receiving of the SA, a party stores it locally and the Updater component updates the local CC. The Checker component is not required in this approach.
Updater
Internal application
Verifier
Counterparty application
CC
E-notary application
MC& Subsidiary Arrangements
Figure 6. E-contract updating architecture in the Dynamic Update approach As can be seen from Figure 5 and Figure 6, the Multiple Signing approach, though more intuitive and straightforward, is more expensive in terms of communication and computation loads, and leads to increased architectural complexity.
3.4 The Role of Third Parties in E-contract Updates Trusted Third Parties can play various roles in the support of an e-contracting relation [18]. In the beginning of this section, an enotary has been provided as an example of a third party that can be used for guaranteeing the correct signing of updated econtracts and for storing of established e-contracts. In this section, we discuss a new role of third parties for the support of the e-contract updating process. Trusted Updater MC
Instance
Company A Request for update
Company B Verifier
CC
Updater
Update CC
CC
For companies implementing the Multiple Signing approach the TU scenario introduces less benefits, as in this approach only the Verifier component can be outsourced. This is due to the fact that the updating process must be followed by an e-contract signing using the company’s private key. As private keys are strictly confidential and cannot be shared with any other party the updating activity cannot be outsourced. There are several advantages for parties when using a TU in their relations. First, a party reduces the complexity of its own e-contract management system. The computational burden on the parties’ e-contract management system caused by e-contract updates is eliminated. The communication burden on the parties is minimized, as only one request for an update is required for the performance of a contract update on the CC of both parties. In cases of updates caused by temporal events or preceding updates, the updating of the CC can even be performed directly by the TU. Finally, it guarantees the sameness of the e-contracts on each side at any point of time as updates on the CC are performed only by the TU. An attempt for fraud by changing the CC locally by one of the parties will be easily detectable and refuted by the TU. Using a TU for e-contract updates has one main drawback. As the Verifier in this approach is outside the company boundaries, parties loose their flexibility in managing e-contract changes that deviate from those allowed in the contract. Any attempt to provide this flexibility to the parties in this approach leads to an increase in communications and makes the TU architecture less beneficial. The TU architecture has advantages for small and medium enterprises that do not have an internal business rule base, and that do not possess an advanced e-contract management system. In cases of contracting between large and small companies, a mixed approach can be considered (one company uses the services of an authorized Trusted Updater, while the large company uses its own e-contract updating system).
Update
Update
resources and the usage of specific software components are required. In cases of small enterprises these requirements can be cumbersome. Using the Dynamic Update approach, SMEs can outsource the e-contract updating procedure to a third party that we call Trusted Updater (TU). In this scenario, a party observes the need for an e-contract update and sends the signed request to the TU (see Figure 7). The TU implements on its side the Updater and Verifier components. It verifies through the Verifier if the request for update is valid according to the contract rules. If the request is valid, each party is provided with a signed by the e-notary SA and the Updater component modifies accordingly the CC on both sides.
Log & Requests archive
Trusted Updaters must be trusted by all contracting parties. Similar to other Trusted Third Parties (e.g., Certificate Authorities, E-notaries), to guarantee trust among all parties, TU have to be certified by a recognized certification authority.
4. RELATED WORK Figure 7. E-contract updating architecture with Trusted Updater In Sections 3.1, 3.2, and 3.3, we have shown that for the support of e-contract updates, significant computational and network
A number of research projects on e-contracting exist. However, the problem of handling e-contract updates has not yet been widely discussed. Next, we briefly describe three advanced research projects that have observed the need of e-contract updates. We pay special attention to the domain of Computer
Supported Cooperative Work, as well. The extensive research work on document management in this domain can be used as an incentive for the support of e-contract update management. In the CrossFlow project [13], an e-contract consists of several elements, among which parameters, cooperation support service clauses (CSS), and process specifications. Parameters contain various data related to the contract enactment. In CrossFlow, parameters can receive or change their values during contract enactment [7], [15]. Furthermore, through CSS clauses, it can be specified which attributes can be changed and the way of implementing a change in the process specification. Events that define transitions in activity states are also defined in contracts and their attributes (e.g. time of occurrence) can be updated. However, in CrossFlow, no explicit attention is paid to the architecture that is required for the support of e-contract updates. This is due to the fact that in CrossFlow the contracts serve the role of specification documents used by the enactment systems for the proper performance of the agreed processes, and not as legally protective documents. Consequently, contracts are not digitally signed and cannot be used as a legal base for the resolution of disputes. The Elemental project [10] is a continuation of the ongoing work on e-contracting at the University of Queensland and the DST Centre. In the Elemental project, the existence of contract updates during contract enactment is envisioned as well. In [20] and [17], a Business Contract Language (BCL) is proposed. One of the building elements in BCL is the value container (i.e. a contract element that contains value). If the value is fixed throughout the contract execution, these data containers are named constants. When their value can change, these are named variables. Variables can be updated during the e-contract enactment for example by rules (policies) defined inside the contract itself [20] or by external triggers and temporal events [17]. Though contract updates are mentioned in the specification of the BCL language, they are not paid explicit attention to and their handling in digitally signed e-contracts is not discussed. In the Coyote (Cover YOurself Transaction Environment) project that was carried out at IBM, e-contracts contain various parameters [8]. The value of certain parameters can change (e.g., after a completion or failure of an action specified in the contract, the price of a contract item can change). However, similar to the CrossFlow project, no specific attention is paid to the updating of the e-contracts in a legally enforceable environment. The changing and re-signing of e-contracts can be seen as a special kind of document/content management. Document management, in particular the collaborative creation and editing of documents, has been a research subject of the Computer Supported Cooperative Work (CSCW) community [11]. The focus of groupware architectures is on supporting people working collectively while located remotely from each other, and on the automated support for this process by information technology [14]. Groupware features like concurrency control, document version handling, and access rights management can be tailored for the support of e-contract updates. In the eLegal project [9], a content management system is used for the collaborative creation of e-contracts. The eLegal project is an example for the application of a special groupware system focusing on the e-contract establishment (including its digital signing). Mechanisms for changing signed e-contracts are not envisioned,
but a limited form of the Multiple Signing approach can be implemented (using the defined contract establishment functionalities for re-negotiation). However, the Dynamic Update approach presented in this paper cannot be supported by the eLegal system. We can conclude that the need for e-contract changes during enactment has been acknowledged by research. However, due to the mixture of security technologies, legal requirements, and advanced e-contracting concepts, the handling of updates in digitally signed e-contracts has not yet been addressed in any existing research work (to the best of our knowledge).
5. CONCLUSIONS E-contracts differ from traditional paper contracts in their level of detail and the rate of updating during contract enactment. In this paper, we have described two possible architectures that allow handling of updates in digitally signed e-contracts during contract enactment. The two architectures are based on two different approaches for handling e-contract updates. While the first, more straightforward approach presents the standard and intuitive solution to the problem of e-contract updates, we show that a second, more sophisticated approach can drastically reduce the computational, storage, software, and networking burden imposed by e-contract updates on the e-contracting management systems. Our conclusion is that the Dynamic Update approach presents a graceful solution to address the problem of e-contract updates in a light (computationally and architecturally) and more flexible manner. A number of protocol, and transactional problems related to e-contract updates require further attention. Handling of two simultaneous requests for an update of one common element requires the topic of protocol conflict resolutions to be addressed. Transactional support in e-contract updates requires special attention as well. Transactional support is required to guarantee a certain level of atomicity, consistency, isolation, and durability features of e-contract updates. The topic of e-contract updates is of interdisciplinary nature. Legal, business, and information technology requirements must be considered for the support of e-contract updates. Projects that investigate e-contracts from the perspective of only one of these domains (e.g., in [1] the legal perspective is dominant, while research in [13] is information technology driven) cannot clearly identify the problems in handling of e-contract updates. Projects with an interdisciplinary foundation (e.g., [10] and [9]) still do not address the full potential of deep e-contracting, and thus are not confronted with the limitations of the Multiple Signing approach. In our future work, we plan to elaborate a detailed e-contracting reference architecture for contract enactment and management. The described architecture for e-contract updates during contract enactment must be aligned with and incorporated in the general e-contracting management architecture, in order to allow fully automated contract enactment and management in dynamic business-to-business trading relations. Another important topic to be addressed is what requirements on the e-contract specification languages are set by the need for e-contract updates.
6. ACKNOWLEDGMENTS We thank Ting Wang for her participation in the discussions on this topic and her comments during the writing of the paper.
7. REFERENCES
[13] Grefen, P., Aberer, K., Hoffner, Y., and Ludwig, H. CrossFlow: Cross-Organizational Workflow Management in Dynamic Virtual Enterprises. International Journal of Computer Systems Science & Engineering, 15, 5, (2000), pp. 277-290.
[1] ALIVE project. ICT Specific for Virtual Enterprises. Project deliverable D11, 2001.
[14] Johansen, R. Groupware: Computer Support for Business Teams. The Free Press, N. Y., USA, 1988.
[2] Angelov, S., and Grefen, P. An Analysis of the B2B E-Contracting Domain - Paradigms and Required Technology. Beta Technical Report WP102, Eindhoven University of Technology, 2003.
[15] Koetsier, M., Grefen, P., and Vonk, J. Contracts for Cross-Organizational Workflow Management. In Proceedings of the 1st International Conference on Electronic Commerce and Web Technologies (London, UK, September 04 – 06, 2000). Springer-Verlag (2000), pp. 110-121.
[3] Angelov, S., and Grefen, P. The Business Case for B2B E-Contracting. In Proceedings of the 6th International Conference on Electronic Commerce: Towards a New Services Landscape (ICEC'04) (Delft, The Netherlands, October 25-27, 2004). pp. 31-40. [4] Angelov, S., and Grefen, P. Requirements on a B2B Econtract Language. Beta Technical Report, Eindhoven University of Technology, 2005. [5] Boulmakoul, A., and Salle, M. Integrated Contract Management. Hewlett-Packard Technical Report, HPL-2002-183, 2002. [6] Cheng, W. C., Chou, C.-F., and Golubchik, L. Performance of Batch-Based Digital Signatures. In Proceedings of the 10th IEEE International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunications Systems (MASCOTS'02) (Fort Worth, Texas, October 11 16, 2002). pp. 291-302. [7] CrossFlow project. Contract Model. CrossFlow deliverable: D4.b, La Gaude, 1999. [8] Dan, A., Dias, D., Nguyen, T., Sachs, M., Shaikh, H., King, R., and Duri, S. The Coyote Project: Framework for Multi-Party e-commerce. In Proceedings of Research and Advanced Technology for Digital Libraries, Second European Conference (ECDL'98) (Heraklion, Greece, September, 1998). Springer-Verlag, Berlin (1998), pp. 873-889. [9] eLegal project. Specification of ICT support tools. Project deliverable D31, 2002. http://cic.vtt.fi/projects/elegal/. [10] Elemental project. http://www.dstc.edu.au/Research/elemental-ov.html. [11] Ellis, C.A., and Gibbs, S. J. Concurrency control in groupware systems. In Proceedings of ACM SIGMOD ’89 Conference on the Management of Data, (Seattle, WA, USA, May 2-4, 1989). ACM Press New York, NY, USA (1989), pp. 399 – 407. [12] European Union. Directive 1999/93/EC of the European Parliament and of the Council on a Community framework for electronic signatures. January 19, 2000.
[16] Laurikkala, H., and Tanskanen, K. Managing Contracts in Virtual Project Supply Chains. In Collaborative Business Ecosystems and Virtual Enterprises – Proceedings of the 3rd IFIP Working Conference on Infrastructures for Virtual Enterprises (Sesimbra, Portugal, May 01 – 03, 2002), Kluwer, B.V., Deventer (2002), pp. 93-100. [17] Linington, P. F., Milosevic, Z., Cole, J., Gibson, S., Kulkarni, S., and Neal, S. A unified behavioural model and a contract language for extended enterprise. Data & Knowledge Engineering. Special issue: Contract-driven coordination and collaboration in the internet context. 51, 1 (October 2004). Elsevier Science Publishers B.V. Amsterdam (2004), pp. 5 – 29. [18] Milosevic, Z., Jøsang, A., Dimitrakos, T., and Patton, M.A. Discretionary Enforcement of Electronic Contracts. In Proceedings of the 6th International Enterprise Distributed Object Computing Conference (EDOC’02) (Lausanne, Switzerland, September 17 – 20, 2002). pp. 39-50. [19] Morciniec, M., Bartolini, C., Monahan, B., and Sallé, M. Towards the Electronic Contract. In Proceedings of the W3C workshop on Web services, (San Jose, CA, USA, 11-12 April, 2001). [20] Neal, S., Cole, J., Linington, P. F., Milosevic, Z., Gibson, S., and Kulkarni, S. Identifying requirements for Business Contract Language: a Monitoring Perspective. In Proceedings of the 7th International Enterprise Distributed Object Computing Conference (EDOC 2003) (Brisbane, Australia, September, 2003). IEEE Computer Society, (2003), pp. 50-61. [21] Reinecke, J., Dessler, G., and Schoell, W. Introduction to business – a contemporary view. Allyn and Bacon. 1989. [22] Snyder, A., and Weaver, A. The e-Logistics of Securing Distributed Medical Data. In Proceedings of Industrial Informatics. E-logistics for a fail-safe word. (INDIN 2003) (Banff, Alberta, Canada , August 21-23, 2003). [23] Thorsteinson, P., and Ganesh, G. .NET Security and Cryptography. Prentice Hall PTR, 2003.
