Business needs are nowadays frequently realized by business workflows spanning multiple organizations. Current infrastructures, such as SOA, support this trend on the implementation side. As a side effect these issues of privacy and data protection arise, because data is shipped across organizational boundaries. At the same time increased awareness about protection of privacy and IPR have lead to comprehensive contractual and legal constructs - including the information of services consumers about the ways their data is handled. We propose to solve such information requests in widely distributed workflow executions by gathering the related information during the execution and attaching it directly to the processed data. Together with the data this information is passed through the workflow and at the end it is returned to the service consumer.
Applying the paradigm of service-orientation in an organization implies the modeling of
business capabilities as independent services. A service-oriented architecture provides
standardized interfaces for the communication between services. The standardization
enables the loose coupling of services, supports the service provisioning for external
service consumers and eases the integration of external services into internal
workflows. The resulting flexibility facilitates the combination of services from different
organizations into one comprehensive, integrated workflow leading at the organizational
level to an agile virtual organization [
However, the resulting flexibility also shows disadvantages. An integrated workflow may forward confidential data (e.g. personal data or intellectual property) between organizations potentially violating concerns of privacy protection or confidentiality. Under such circumstances of flexible interworking between organizations, the importance of accounting for actions performed on data may become legally and/or contractually a highest priority.
To enforce accountability the privacy laws of some countries, e.g. all countries in the EU (as defined in Directive 95/46/EC), oblige organizations to notify about the processing of personal data (which can be described by privacy policies) and entitles natural persons to request information about the processing of their personal data (this process is called information by request). As a second case, one may consider contractual obligations about data protection between organizations. An organization that uses a web service like SalesforceTM customer-relationship management software may not want to share the data about its customers with its competitors who use the same service. Hence, a service provider may offer the possibility to retrieve data accounting information and thus to allow for some control of the data processing.
To be able to monitor agreed-upon policies the service consumer (e.g. a natural
person or another organization) may request information about the processing of his data.
The answer to this request must contain who processed the data as well as why and
how the data has been processed. This information constitutes an abstracting log of the
workflow execution. The log can be generated in different ways, e.g. by reconstructing
or by monitoring the workflow execution. In any case the service provider needs a
detailed overview of its workflows. Most frequently such an overview is lacking, even for
internal workflows. For several reasons existing logging mechanisms, like the Extended
Log File Format [
The aim of this paper is to present the actual state of work at the sticky logging mechanism. The mechanism consists of two parts: First, an architecture defining rules how to collect information about the processing of private data in distributed workflows; and second, a formalism specifying how to express the collected information. Parts of the mechanism to achieve accountability, like tamper and fraud resistance, are work in progress and will be presented in follow-up papers.
This paper is organized as follows: In section 2 we analyze general requirements for a mechanisms to collect information about the processing of private data in distributed workflows. Following the requirements we introduce the architecture in section 3 and in section 4 the formalism of the sticky logging mechanism. Then, we give a scenario in section 5 demonstrating the application of the sticky logging mechanism. Before we eventually discuss our approach and conclude in section 7, we compare it with related work in section 6. 2
In this section we present a business case where the realization of an SOA architecture includes a workflow over several organizations and we identify legal requirements. 1 This mechanism can be used in addition to standard logging mechanisms that are needed to maintain the technical functionality of a workflow environment or service.
From the business case and the legal requirements we derive some issues that arise with regard to data protection. Then, we derive technical requirements for collecting privacy-related information about data processing in a cross-organizational workflow. 2.1
The Small-Books Inc. is a book-selling company. Parts of the logistics like storing the books and packaging are done by Small-Books Inc. itself, but for shipping and payment it uses services provided by other organizations. For instance, the shipping of orders is outsourced to a logistics company named Fast-Shipping Inc.
Assume that a customer, Mr. Smith, orders books via the Web site of Small-Books Inc. To place his order he has to insert his address and credit card number. After the order is placed Small-Books Inc. possesses three instances of data related to the order: the list of ordered books, Mr Smith’s address and credit card number. As first action Small-Books Inc. uses the payment service of the credit card company. To this purpose, Small-Books Inc. passes the credit card number and the invoice value to the payment service. Then, Small-Books Inc. packages the order and invokes the delivery service of Fast-Shipping Inc. To this end, Small-Books Inc. has to copy the address to pass it as new data instance to Fast-Shipping Inc. 2.2
In the introduction, we have described why an organization must take responsibility for its way of handling of personal data. In addition it must be able to inform the person concerned about this handling. These implies the following requirements: Req1 The person concerned must be able to request or directly access the logs. Req2 The logs must identify the organizations responsible for each action performed on personal data.
Req3 An organization must not be able to deny a log entry it has made. 2.3
From the business case and above-derived requirements we may derive the following organizational issues.
Loosely-coupled Architectures: At the level of implementation, the use of a serviceoriented architecture hampers the generation of an overview. The reason is that services in an SOA are defined and implemented independently of each other. Hence, cross cutting concerns, such as logging, are hard to realize if they are not standardized at the interface level. Also, workflows can be configured in an agile manner making it difficult a posteriori to assert which organizations had accessed the data during the execution of the workflow.
Lack of Process Awareness: In order to report on previous handling of data, an
organization must be aware of and account for their internal data flows at a very
finegrained level of granularity. Such awareness and accounting at the fine-grained level
is rarely available explicitly for cross-organizational workflows, because the increased
complexity of the workflows [
Autonomy of Organizations: With organizational autonomy transparency decreases, as the autonomous organizations in general do not want their workflows to be controlled or monitored by third parties. At the level of cross-organizational workflow the issue of a lack of process awareness is further aggravated by the organizational responsibility being distributed over autonomous entities. 2.4
A technical solution for accountability must address the three organizational issues identified above. To solve these issues we demand the following technical requirements: Req4 To avoid ambiguities and to reach standardization, the logs must be formalized using a language with a well-defined semantics.
Req5 The used language must be able to express details about the performed actions, their actors, their purposes and their order. These details must have the required level of granularity.
Req6 A standardized interface is required to access and share logs between all
involved parties (see [
Req7 The logging implementation must enable an organization to create logs containing all privacy-related details.
Req8 Organizations must be able to hide process internals from third parties. Thus, both implementation and formalization must support security mechanisms. Additionally there exist other requirements, like trustworthiness of organisations. Even if those requirements are highly important for logging in general and for accountability in special, they are not considered in this work 2. 3
The above-identified issues affect the organizations ability to integrate external services in general and specifically to inform about actions performed on personal data. In the following we propose a logging architecture for distributed workflows to fulfill the above-defined requirements.
As demanded by requirement Req1, the person concerned must be able to access the
logs about the processing of its data. However, to access the logs it is essential to know
where the logs are located and how to access them. In addition, requirement Req5
demands a detailed overview of the processing of the data. To fulfill these requirements we
propose to attach all logs of a single execution of a workflow directly to the processed
data, as metadata. The logs are attached by including them into the SOAP [
After the process execution the logs are made accessible to the person concerned by means of a mechanism we call back-propagation (see below). Because the logs are attached to the associated data instances, we call this approach sticky logging. The sticky logging mechanism demands specific actions when certain events occur. In the following a short overview of these actions is given: • Creation of data instances: Each data instance gets its own sticky log starting with an entry recording various pieces of information (see section 4) about its creation. In addition, each sticky log gets its own UUID. If the created data instance contains data taken from other data instances, the source instances have to be referenced. • Processing and changing of data instances: Each processing or changing of a data instance has to be logged by means of the formalism introduced in section 4. • Copying of data instances: Each copying of a data instance is associated with the creation of a new instance of the data. To enable the back-propagation of logs and the updating of references (see below) in both sticky logs (the one attached to the original instance of the data and the newly-created one, which is attached to the new instance of the data) a reference to the other sticky log has to be made. A reference contains the UUID of the log and the identifier of the organization that possesses or receives (see passing of data instances) the data. After the data is copied further log entries are only added to the associated sticky log.
If the newly-created data instance is used for purposes other than processing by the workflow (e.g. storing in a database), an alternative method for the back-propagation (e.g. e-mail, etc.) has to be specified. This method has to be used when the normal reference needed for back-propagation becomes unusable. • Merging of data instances: To merge data instances the instances are processed (see above) with the purpose to create a new instance containing the result of the merge. The creation itself is handled like a normal creation (see above). • Passing of data instances: To pass an instance of data (or parts of it) as parameter of a service call it (or parts of it) has to be copied (see above) and then the copy is passed to the called service. With the copy the newly-created log4 is transfered, too. As mentioned before the transportation of the log is achieved as part of the SOAP message that is used to call the service and is transferred anyway.
When a service is called synchronously, the log is back-propagated by means of the SOAP answer after the execution. In contrast, if a service is called asynchronously, this has to be logged explicitly in the log of the original data instance. In addition, because the SOAP answering message can not be used for back-propagation, an alternative method for the back-propagation has to be specified in the newly-created log (see above). In both cases, the organization has to integrate the log into the one of the original data instance after receiving the log. • Deleting of data instances: Deleting a data instance does not cause the deletion of the sticky log. Instead the log has to be back-propagated. The back-propagation is reached by merging the log with the one referred by the reference specified in the log (see copying of data instances). The merging may be reached by means of 4 Because only the new log is transfered, the provider of the called service gets no insight into internals of the calling organization.
directly accessing the referred log as long as both logs are possessed by the same organization. If the referred log is possessed by another organization, the log of the deleted instance may be returned by means of the SOAP answer. This is feasible as long as the deletion occurs during the execution of a service on behalf of the organization possessing the source instance. In the case that there is no SOAP answer (e.g. because the service has been called asynchronously) the alternate method is used for back-propagation. After merging the logs, all references contained in logs of direct copies of the deleted data instance have to be updated to refer to the merged sticky log.
If the deleted instance is the last instance of a specific piece of data, the log is directly returned to the person or organization that initially created the first instance of this data. This person or organization is responsible to answer requested information to the person concerned.
Beside those actions the sticky logging mechanism makes use of signatures and encryption. The signatures are used to assure that the log is not modified by another organization on its way. For this purpose each logging entity has to sign its log entries by means of a digital signature mechanism. The encryption of logs is possible, because, if the privacy law or the contract demands it, the logs may contain confidential information about the internals of an organization. This information has to be provided to the person concerned, but should not be accessible by other organizations that transfer the log back to the person concerned. We propose to use an encryption mechanism basing on a public-key cryptography algorithm. Such algorithms allow the logging organization to encrypt the logs with the public key of the person concerned or of organizations that are allowed to access the logs. 4
To enable a semi-automated analysis of logs we specify the logs by means of a
RDFbased [
Instances of Data: Each data may have multiple instances (e.g. through copying).
Even if all instances have their own sticky logs, they have to be clearly identifiable.
This is because the logs of different instances will be combined when a data instance is
deleted (see below). To represent the instance of a data we introduce the
DataInstanceclass that has among others the following properties:
• hasUUID: A unique id that clearly identifies this data instance. To assure that the
id is unique we use UUIDs [
koblenz.de/Research/SOA/StickyLogging is accessible at http://isweb.uni
Listing 1 depicts a snippet of the log that is attached to the data instance of SmallBooks Inc. containing Mr. Smith’s address information6. In line 1 to 3 this instance is specified.
Actions on Data Instances: The actions performed on the data instances are represented by the class Action. This class has among others the following properties: • isOfKind: The kind of this action. • hasPurpose: The purpose why this action has been performed. • performedOnDataInstance: The data instance the action is performed on.
Line 4 and 7 of Listing 1 depict how Small-Books Inc. logs that an action has been performed on the data instance containing Mr. Smiths address information.
Log Entries: The class LogEntry represents one log entry. Whereas, a log entry contains the recording of all information about one single action performed on the processed data. Some of the properties of the LogEntry-class are: • hasUUID: A unique id that clearly identifies this log entry. • logsAction: The action logged by this entry.
In Listing 1 lines 8 to 10 depict the beginning of a log entry recorded by the SmallBooks Inc.
Kind of Actions: The introduced formalism builds upon the two basic actions that can be performed on data: reading and writing. These actions are subdivided into few sub categories representing different reasons causing the action. We distinguish two reasons read-actions can have: First, reading data to use it, e.g. by a service to fulfill its purpose. Second, reading data to copy it - including the copying of data to invoke another service. Although copying is a special kind of using data, we define copying as distinguished action. This is because of the specialty that a new instance of the data is created as result of the copy-action. Thus, we introduce the following classes representing these read-actions: • The class UseAction represents all read-actions that are performed on the data, beside read-actions made to copy data. • The CopyAction-class represents the read-action that is made to read the data that is to be copied.
In addition, we distinguish three reasons that cause write-actions: Writing data to create a new data instance, writing data to change an existing instance, and writing data to delete a data instance. The create-action has been distinguished from the changeaction, because during the create-action a new data instance is created while the changeaction only modifies an existing one. The write-actions are present by the following classes: • The CreateAction-class represents the action that is used to create a data instance. 6 In the following examples we use sl: as namespace for the classes and properties defined as part of the sticky logging formalism. • All actions that change the data are represented by means of the class ChangeAction. • The class DeleteAction represents the action performed to delete a data instance.
Within our business case Small-Books Inc. invokes the shipping service of FastShipping Inc. to ship Mr. Smith’s order. Therefore, it creates a new instance of the address data by means of a copy-action (see lines 3 and 6 in Listing 1). In the associated sticky logs Small-Books Inc. connects the two instances by means of the properties hasCopy and isCopyOf. In parallel Small-Books Inc. creates a new sticky log for the actions that will be performed on the copy of the address data (like Small-Books Inc. has done in lines 1, 2 and 8 to 10 in Listings 1 for the first instance). Then the new instance with its new sticky log is passed as part of the service invocation to Fast-Shipping Inc.
Purpose of Actions: Besides the kind of an action its purpose is of importance, to check if a performed action has been justified. The possible purposes of an action depend on the service and thus on its domain. For instance, actions of services of the delivery domain may have purposes like the delivery of an order, tracing of an order, etc. Thus, to enable a flexible definition of purposes, concepts defined in domain ontologies based on an upper ontology for privacy7 are used.
Line 7 of the log snipped in Listing 1 shows that Small-Books Inc. has performed the above logged copy-action for delivery purposes (dofd:DeliverOrder8).
Accountability: Fundamental for achieving accountability is the explicit
identification of the entity that performs actions on the data instance. In addition, an organization
has to be clearly associated with all log entries it is responsible for and its log entries
may not be modified or changed by another entity. Thus, we introduce the Entity-class
to represent an entity within a sticky log. In addition, the formalism demands the use of
mechanisms to sign RDF graphs like the one described in [
The lines 14 to 19 in the example in Listing 1 depict how the Small-Books Inc. identifies itself by instantiating the Entity-class and setting its properties. 01 : a d d r e s s D I 1 r d f : t y p e s l : D a t a I n s t a n c e 02 : a d d r e s s D I 1 s l : hasUUID ” a 2 6 f 4 5 8 0 −39d9 −11dc−a 3 f a − . . . ” 03 : a d d r e s s D I 1 s l : hasCopy : a d d r e s s D I 2 04 : a c t i o n 1 r d f : t y p e s l : a c t i o n 05 : a c t i o n 1 s l : p e r f o r m e d O n D a t a I n s t a n c e : a d d r e s s D I 1 7 Because of the limited space, this ontology will be introduced in detail in a technical report, which is under work. 8 :dofd is the namespace of the domain ontology for delivery. 11 : a d d r e s s D I 2 r d f : t y p e s l : D a t a I n s t a n c e 12 : a d d r e s s D I 2 s l : hasUUID ” d3020270 −3ab8 −11dc−a179 − . . . ” 13 : a d d r e s s D I 2 s l : i s C o p y O f : d a t a I n s t a n c e 1 14 : e n t i t y 1 r d f : t y p e s l : E n t i t y 15 : e n t i t y 1 s l : hasName ” Small−Books I n c . ” 16 : e n t i t y 1 s l : h a s I D ” ISIN US0001234567 ” 17 : e n t i t y 1 s l : h a s L o g g e d : l o g E n t r y 1 18 : e n t i t y 1 s l : h a s P G P C e r t i f i c a t e ” h t t p : / / s b i . de / c e r t . a s c ” 19 : e n t i t y 1 s l : S i g n a t u r e ” HrdSDFc . . . ”
5
In this section we step action-by-action trough our above-introduced business case to demonstrate the functionality of the sticky logging mechanism:
In our business case Small-Books Inc. possesses three data instances: One instance of the list of ordered books, one instance of the address data, and one instance of the credit card information. For each of these instances Small-Books Inc. creates a log. In each of these logs Small-Books Inc. identifies itself as logging entity. For all log entries Small-Books Inc. uses the above-defined semantic formalism (Req4 and Req5).
As first step Small-Books Inc. processes the order list to package the order. This use-action and its purpose (packaging) are logged by Small-Books Inc. After the packaging is finished Small-Books Inc. hands the package over to Fast-Shipping Inc. To this purpose Small-Books Inc. copies the address data and transfers it to Fast-Shipping Inc. The transfered is reached by means of the SOAP message used to call the service. Thus, a standardized way to exchange logs is used (Req6).
The copy-action and its purpose (delivery) are logged by Small-Books Inc. In parallel a new log is created by Small-Books Inc. that is transfered to Fast-Shipping Inc. Both organizations need to be identified in the new log. Small-Books Inc. as responsible for the copy action and Fast-Shipping Inc. as receiver of the data instance. All organizations processing the data identify themselves in the logs (Req2). Because the delivery service is called asynchronous, a alternative return method is specified in the newly-created log.
As next step Fast-Shipping Inc. uses the address data to deliver the package. This use-action and its purpose (delivery) are logged by Fast-Shipping Inc. into the log attached to its instance of address data. For the logging Fast-Shipping Inc. uses also the above-defined semantic formalism (Req4 and Req5). After the package is successfully delivered Fast-Shipping Inc. deletes its instance of the address data. The delete-action is also logged by Fast-Shipping Inc.
Before returning the log, Fast-Shipping Inc. signs the log entries it has recorded. Then Fast-Shipping Inc. returns the log by means of the specified alternative return method to Small-Books Inc. Small-Books Inc. integrates these log into its own log of the its instance of Mr. Smith’s address data. At the end of the processing Small-Books Inc. signs its log entries also. All involved organizations had to sign their log entries (Req3). By means of the logs Small-Books Inc. generates an information page that is accessible by Mr. Smith. This Web page contains all information about the processing of Mr. Smith address data (Req1). In addition, all actions, their actors, and their purposes can be identified by Mr. Smith (Req7).
Finally, Fast-Shipping Inc. did not have insight into internals of Small-Books Inc. The other way Fast-Shipping Inc. could have used the private key of Mr. Smith to encrypt his logs. This way Small-Books Inc. also would have no insight into internals of Fast-Shipping Inc. (Req8). 6
An example for another work identifying the need for accountability for data usage
in distributed environments is presented by Weitzner et al. [
To reach accountability, different approaches exist that propose the use of auditing
mechanisms: For instance, the authors of [
One example for an approach to log the communication of data is the Extended
Log File Format [
An approach to enrich existing logs with semantics is presented by Baker and
Boakes in [
Karjoth et al. introduce in [
This paper presented a logging mechanism for distributed workflows - called sticky logging. As part of the sticky logging mechanism we defined a well-defined, semantic formalism to specify logs. Besides the formalism we specified logging actions trigged by various events during the processing of personal data. In addition, we have described how the logs are shared and accessed by the person concerned. All together the sticky logging mechanism fulfills the requirements as demanded by privacy law and contracts. In addition, the sticky logging mechanism is able to overcome the above-mentioned organizational issues.
The next step of our work is the formal definition of the logging rules. After this we will analyze the integration of the sticky logging in an existing middleware platform. In addition, we are going to extend the sticky logging mechanism to achieve accountability. Therefore mechanisms for tamper resistance, avoidance of fraud, etc. shall be integrated. The complete sticky logging mechanism will be published by means of a technical report, which is under work. In parallel we are working on a prototype that implements the introduced sticky logging mechanism. Once the prototype is finished it will be made available for download. 8
This work has been supported by the Federal Ministry for Education and Research in the project SOAinVO - ”Technique Analysis and Risk Management for Service-oriented Architectures in Virtual Organisations” and by the european projects Knowledge Sharing and Reuse across Media (X-Media, FP6-26978) funded by the Information Society Technologies (IST) 6th Framework Programme.