Towards Privacy-Friendly Transparency Servicesin Inter-Organizational Business Processes

Meiko Jensen

Independent Centre for Privacy Protection Schleswig-Holstein (ULD)Kiel, Germany

Email: Meiko.Jensen@rub.de

Abstract—With upcoming regulation, the task of implement-ing transparency services gets a critical part of all electroniccommerce. Within inter-organizational business processes, thistask becomes more challenging, as even determination of thetopology of a service composition within such a setting is gettinga complex issue of its own.

In this paper, we shed a light on the functional, legal, andeconomic issues and challenes of realizing useful transparencyservices. We also propose a decentralized solution for support-ing anonymized collection of transparency-relevant informationbased on the principles of service-orientation.

Keywords-privacy; transparency; transparency services;inter-organizational business processes

I. INTRODUCTION

Privacy and security have become major concerns when

it comes to the use of services on the net or in the clouds.

As security breaches are in the news almost weekly, and

as privacy of individuals erodes to the benefit of service

providers that sell their user’s data, it is reasonable to foster

research on countersteering these trends.

In that line, the case of inter-organizational service com-

position is special. Being based on the collaboration of

at least two, but commonly way more, separate organi-

zations, potentially spreading among several countries and

jurisdictions, a security breach or a potential privacy law

violation rapidly becomes a complex issue to cope with.

Besides clear responsibilities among the service composition

participants, a major source of problems in these settings

tends to be the fact that some service providers try to keep

confidential details about their internal business partners.

From an economic point of view, such confidentiality clearly

makes sense, as disclosure of a service’s internal suppliers

and supply chain costs may result in competitors joining the

market and hence pricing undercuts. However, in terms of

both privacy and security, such confidentiality against thebusiness partner (cf. [1], [2]) poses severe limitations to

inter-organizational collaboration.

In this paper, we argue that such type of confidentiality

can be eased by far, without raising the risks of competition

or other negative effects as discussed above. Based on

existing privacy-enhancing technologies and a few exten-

sions to service interfaces within inter-organizational service

compositions, we propose that a lot of transparency can

be created regarding the internals of a service composition.

This again helps assessing—and hence mitigating—security

issues that may occur, and also improves privacy w.r.t. the

end users of a service composition—also improving the

challenge of service selection, as far as it is based on security

and privacy perception of a service composition’s provider.

The next section introduces the key terms of privacy and

transparency. Sections III-A and III-B assess the state of

the art and the issues of realizing transparency servicesas part of inter-organizational business processes. Then,

Section III-C discusses the main conflict of privacy and

business secrets, illustrating the legal and business impacts,

and Section III-D analyzes the challenge of aggregating

transparency-related information in a service composition

setting. Section IV outlines the technical architecture derived

from this discussion. The paper concludes in Section V.

II. PRIVACY AND TRANSPARENCY

In our setting, the term privacy refers to the perceived

affection of an individual by service providers w.r.t. the

personal data of that individual. Depending on the legislation

considered, this implicit affection can be understood and

safeguarded by completely different means. For instance,

U.S.-based service providers mostly implement privacy as

a concern addressed by a self-regulatory privacy policy. The

mindset behind this could be summarized as “agree, or stay

out”. However, the individual user is completely bound to

the terms of service as imposed by the service provider only.

In contrast, the European means of privacy protection are

more based on laws and regulations. Here, an individual

that fears about its privacy has lots of means—and rights—

to interact with a service provider for assessing its privacy

conditions. In this line, several efforts have been made to

align European data protection laws with the principles ser-

vice composition architectures. Moreover, European privacy

protection research has identified three major protectiongoals of privacy, equivalent to the well-known protection

goals of common security (i.e. confidentiality, availability,

integrity). Those three protection goals of transparency,

intervenability, and unlinkability, are to be recalled next (see

also [3], [4], [5]).

2013 IEEE 37th Annual Computer Software and Applications Conference Workshops

978-0-7695-4987-3/13 $26.00 © 2013 IEEE

DOI 10.1109/COMPSACW.2013.27

200

The protection goal of Transparency describes all means

(technical and organizational) that enable an individual with

understanding of how a system (here: a service composition)

works. Its realization is commonly based on techniques of

documentation, such as service handbooks, log files, and

help desks. In theory, 100% transparency would imply that

every individual is able to see—and understand—every type

of data processing taking place in every part of a service

composition at all times. In reality, however, this obviously

is not feasible. Merely, today’s service providers tend to do

the opposite: by keeping their internals confidential, they

make if very difficult for individuals to determine what may

have happened with their personal data within a service

composition (e.g. if their mail address happened to leak to

spammers, or similar). As is discussed in more depth in the

next section, implementing transparency commonly impacts

both confidentiality and unlinkability (see below).

Intervenability refers to a system’s (or service compo-

sition’s) property of allowing an individual to actively in-

fluence data processing steps of that individual’s personal

data. For instance, the ability to opt out of a mailing list is

one aspect of realization of intervenability. As can already

be seen, intervenability mostly requires transparency, as

an individual must be aware of a data processing taking

place prior to interfering with it. The natural opponent to

intervenability is the classic protection goal of integrity, as

the latter prohibits any type of modifications to data or

processes of a system (or service composition).

The protection goal of Unlinkability, finally, covers all

aspects of reducing the ability to link different types of data

against each other. Its most widely known implementation

is that of anonymization, which unlinks a dataset from its

described individual. Similarly, pseudonymization is another

manifestation of unlinkability, reducing the link to a data

owner to a certain token called pseudonym [6]. Without

the mapping of pseudonym to identity, data linkage can

not be performed. Unlinkability is a natural counterpart to

transparency, as it undermindes the ability to link data from

differenct sources (e.g. logfile entries) to reconstruct a full

story out of them.

Each of these protection goals has its realization best

practices, and together with the classic secuirty protection

goals, they can be considered as a 6-dimension star with

opposing edges (cf. Figure 1). Using these six protection

goals as a methodological basis allows for argueing about

privacy and protection of personal data in almost every

type of system. Hence, applying these protection goals

to the scope of inter-organizational service compositions

is a straight-forward approach for research. Hence, in the

following, we will investigate some of the more interesting

aspects and interferences that may occur within service

compositions. For the “common” scenarios, such as e.g.

confidentiality, realized via data encryption throughout a

service composition, we refer to related work: [7], [8], [9]

Figure 1. The six privacy protection goals.

III. TRANSPARENCY-ENHANCED SERVICE

COMPOSITION

A. Transparency-Enhanced Services

As discussed e.g. in [10], services provide excellent

preconditions for enabling transparency-enhancing technolo-

gies. Given that most existing services already provide some

technical descriptions of their particular service interfaces

and APIs (e.g. by means of WSDL [11] or WS-Policy [12]),

extending those interfaces with additional information on

non-functional elements, such as transparency-related infor-

mation, is neatly feasible. For instance, it is technically

trivial to extend an existing WSDL description of a given

service interface with additional human-readable descrip-

tions of the service’s interior functionality and details, e.g.

by means of a <wsdl:documentation> element.

However, in order to fully support automated service

consumption and service composition, it is more reasonable

to provide such information in a more structured way, e.g.

by means of appropriate XML Schemas. In this line, recent

efforts have been made in the direction of defining strictly

structured service annotations, such as service certificates,

performance indicators, and other Quality of Service charac-

teristics (cf. [13], [14], [15]). All of these may contribute to

a service’s perceived transparency, as each of them provides

information (and maybe even proven or verifiable claims)

about certain aspects of a service’s realization.

Nevertheless, none of these attempts did focus on trans-

parency directly. Hence, some of the core information re-

quired in terms of service selection is still lacking sufficient

schematic support. For instance, common attributes of rele-

vance for the privacy protection goal of transparency involve:

• location of servers that operate the service implemen-

tation,

• country of residence of the service provider,

• number of subcontractors or internal service providers

involved in service realization,

• reference to a human-readable, legally binding privacy

policy and terms of use document, or

201

• documentation of a service’s internal workflows, e.g.

by means of an abstract WS-BPEL process description

(cf. [16]).

Each of these would contribute to the privacy protection

goal of transparency, as each enables services users to better

understand the interior workflows within a service compo-

sition. Furthermore, as transparency—and yet knwoledge of

the way of data processing within a service composition—is

a prerequisite for proper intervention in case of data misuse,

these details directly affect also the privacy protection goal

of intervenability.

B. Transparency in Service Compositions

Given that each atomic service provides a detailed techni-

cal description of its interior workings as discussed above, it

remains an issue to automatically use this information in the

context of a service composition. Here, two core challenges

arise:

1) collecting the transparency-relevant information of

each atomic service within the service composition,

and

2) aggregating this information, along with information

on the service composition’s topology, to provide a

full view on all aspects of the service composition.

The former assumably can relatively easy be realized on

the technical side by recursively iterating over all atomic

services and collecting the results of their particular interface

descriptions. However, considering business and legal factors

as well, it turns out that this part probably is the most

challenging part of the whole approach. An brief discussion

on both of these aspects is provided next.

C. Transparency vs. Business Secrecy

Inter-organizational business processes, such as supply

chains or collaborative enterprises, tend to become quite

complex, with nested and intersecting collaborations and

business contracts. Though all of the companies involved

in such a conglomerate have a general economic interest in

participating in the collaboration (and hence in contributing

to the overall business of the collaboration), each company

has its very own motivations, business goals, and perceptions

of collaborators and competitors. In certain conditions, these

individual goals may negatively affect the business of the

conglomerate in se (see e.g. [17]). For instance, a business

partner may be trusted to supply its products under accept-

able conditions, but may not be trusted to get to know the

business secrets and interior workings of a company.

Hence, when it comes to providing transparency w.r.t. the

interior workings of a company, it is often the case that such

information is provided reluctantly, inaccurately, or even not

at all. Fears of legal prosecutions or of misuse of business

secrets by competitors contribute to this reluctance, which

largely affect the overall realization of the privacy protection

goal of transparency.

Figure 2. Transparency service composition with blocking partner.

D. Aggregation of Transparency Data

Beyond fear-based reluctance against disclosure at

each individual company, even in presence of sufficient

transparency-related information, the aggregation of such

information throughout an inter-organizational business pro-

cess is a challenging issue. A trivial assumption would be

to collect all data of all companies involved in the business

process at a central place, providing transparency-related

information to requesters on demand. This approach has

several pitfalls.

At first, it is not a trivial task to identify (or even set

up) a single central point trusted by all collaborators in an

inter-organizational business process. If it is hosted by one

of the collaborators themselves, that one (perceivably) gets

additional “political powers” within the conglomerate. If it

is hosted by an external party, agreement on trustworthiness

of that entity is a challenge of its own.

Secondly, even if a single trusted third party is found,

that entity has to cope with the challenge of unifying all

disclosed information of all services within a service com-

position. Those may come in in different technical formats,

providing different types of information, in ifferent styles,

languages, and so forth. Unifying all of these to provide

an at least somewhat homogeneous picture of the overall

business process is a huge challenge itself.

Third, it is often not clear which compnaies are actually

involved in a certain business process. For instance, some

companies may also supply to other compnaies that are not

officially part of the conglomerate. Nevertheless, there might

be situations where such external peers are temporarily

involved in certain parts of a business process instance.

Then, it is in question whether those companies are to be

involved in the centralized transparency aggregation or not.

Moreover, in some cases, business partners do not even

disclose their internal suppliers’ (or other internal business

partners’) identities, fearing that such disclosure would affect

their own position (and hence economic profits) within the

conglomerate (as shown in Figure 2). Hence, consequently,

the transparency-related information gathered from these

companies typically omits such information, and hence gets

very vague with respect to such internal collaborators.

202

Figure 3. Anonymized transparency service composition.

Especially the latter type of issue fosters the collec-

tion of transparency-related information within an inter-

organizational business procvess to become a highly com-

plex challenge.

IV. A SERVICE-ORIENTED ARCHITECTURE FOR

TRANSPARENCY SERVICES

As was discussed in the previous section, collecting

transparency-related information in a central repository is

not a feasible solution for all types of conglomerates. Hence,

it becomes necessary to develop other realizations of such

transparency services within inter-organizational business

processes, respecting the constraints as indicated above.

In this section we outline an architecture for trans-

parency services that follows the principal rules of service-

orientation, i.e. every company may decide upon its level of

transparency-related disclosure by itself. This also involves

disclosure or non-disclosure of internal collaborators. How-

ever, based on the idea of service-orientation, it becomes

possible to adapt the level of disclosure based on the type

of information asked by the user of a transparency service.

We will discuss this based on an example.

A. Anonymous Assessment of Countries in a Service Com-position

Assume a large conglomerate of companies, e.g. in

the defense industries, that is obliged by law to provide

transparency-related information to its customers. In such a

setting, it is obvious that a lot of information on internals of

each involved company is classified, hence is not allowed

to be disclosed to unauthorized entities, especially end-

users. Hence, collecting an overall transparency picture of

the business process realized by such a conglomerate most

probably will hide lots of details, especially with respect

to the set of companies involved. Hence, such an approach

renders itself of limited use.

However, using the principle of service-orientation turns

out to be superior here, as it allows for anonymized re-

sponses to requests for transparency-related information. For

instance, if the end-user is only interested in determining

the set of countries the business process spans over, e.g.

in order to ensure that certain countries are not involved

in the business process, it is a viable approach to collect

that information—and only that information—throughout the

service composition, without disclosure of which companies

actually are involved, and which country was added by

whom. Therefore, as is shown in Figure 3, the initial

transparency request is placed at the transparency service

of the business partner in direct contact with the end-user.

That request contains precisely the information the end-user

wants to collect throughout the service composition, e.g. the

countries involved, or the number of companies of SME

category (Small or Medium-sized Companies) within the

conglomerate (see also Section IV-B).

Then, each business partner that receives this request via

its own transparency service may decide upon itself as to

what information it adds to the response, and replies back

to its caller with that information. Thus, if a company relies

on the use of external partners or suppliers, it may decide to

forward the request to those partners, more precisely to their

transparency services, and aggregate their responses into its

very own response. This way, a decentralized approach is

followed, which allows each company to decide on its own

whether it wants to involve its internal business partners in

the evaluation or not.

Finally, the end-user that placed the initial request at

its peering service provider’s transparency service gets a

response that incorporates all information as requested—

based on the decision each individual company has taken

thorughout the service composition.

B. Evaluation and Trust in Transparency Services

An obvious issue with the architecture outlined above

consists in accurancy and completeness of the information

the end-user gathers this way. If only one of the involved

companies accidentally or intentionally decides to lie about

their status, or does not forward the request to its successors

as intended, the result of the transparency assessment is

falsified immediately.

However, this is a common issue of transparency services

in all conditions. All types of transparency-related disclo-

sured depend on honesty of the companies that provide

the transparency information. This is a persistent threat for

every realization of transparency, hence it does not render

the proposed approach of service-orientation better or worse

than any other solution.

Moreover, in contrast, based on the level of anonymity

achieved through the proposed service-oriented approach,

companies may feel more safe to forward the request to

their internal peers, providing the end-user with information

he would not even be able to gain in other conditions. Taking

the example above, it is not 100% reliably possible for the

end-user to determine whether the business process invovles

companies of a certain countries, but it renders the result to

four different categories:

203

1) If the particular country is listed in the response

gathered from the transparency service, then either

a) at least one company in the conglomerate is

located in that country, or

b) at least one company in the conglomerate lied

about its location, claiming to stem from that

country.

In each of these cases, the end-user may decide not to

utilize the business process at all.

2) If the particular country is not listed in the response

gathered from the transparency service, then either

a) not a single company in the conglomerate is

located in that country, or

b) at least one company in the conglomerate lied

about its location, claiming not to stem from that

country.

The former case is exactly what the end-user is looking

for. In the latter case, there is the high probabil-

ity of peering companies detecting the—somewhat

obvious—lie about location, which at least weakens

the situation of the liar within the conglomerate. Even

if there is no detection of such fraud, this case is

rather rare. Hence, in total, the approach provides way

more precise information as compared to the end-user

getting no information on the set of countries involved

at all.

As can be seen, the use of service-oriented architectures

for realizing transparency services in inter-organizational

business processes is capable of providing way more detailed

information to the end-users, as compared to a centralized

or static approach. Moreover, it allows for anonymized

collection of transparency-related information throughout a

service composition, which in itself may provide important

information to end-users, and which would not be assessible

for the end-user at all.

Depending on the type of information an end-user is

looking for, such transparency services might provide lots

of different sorts of data. Examples are listed below.

• countries involved,

• legislations involved (implying applicable laws; not

identical to countries, as e.g. states of a country may

have specific laws)

• languages spoken in the companies involved (might be

used as indicator for degree of collaboration)

• sizes and types of companies involved (e.g. number of

enterprises, SMEs, public bodies, NGOs etc.)

• verification on whether all companies involved have a

certain type of certification (e.g. ISO 9001, ISO 27001,

Fairtrade certification, etc.)

V. CONCLUSION

As we have shown, the automation of transparency ser-

vices based on service-orientation is a feasible and highly ca-

pable approach for implementing transparency-related infor-

mation disclosure within enterprise-level inter-organizational

business processes. Given the number of upcoming reg-

ulations with respect to transparency (e.g. the upcoming

European General Data Protection Regulation, future FTC

regulations, etc.), this is a highly important, yet highly

dynamic field of research.

In this paper, we introduced the issues of transparency-

related information disclosure in large economic conglom-

erates, and we introduced our approach for tackling these

issues in a privacy-preserving yet economically friendly way.

The proposed approach of service-orientation that has been

shown to be highly successful for both functional and non-

functional issues of collaboration throughout the last decade,

again plays out its strengths in terms of collecting data

through decentralized means, thereby giving each participant

a high degree of control over its part. Thus, we expect that

this approach is superior to other approaches for realizing

transparency, and that transparency services will become part

of every inter-organizational business process implementa-

tion within the nearby future.

VI. ACKNOWLEDGEMENTS

This work has partially been funded by the European

Commission under contract numbers 318424 (FutureID

project) and 257243 (TClouds project).

204

REFERENCES

[1] F. Kerschbaum and R. J. Deitos, “Security against thebusiness partner,” in Proceedings of the 2008 ACM workshopon Secure web services, ser. SWS ’08. New York,NY, USA: ACM, 2008, pp. 1–10. [Online]. Available:http://doi.acm.org/10.1145/1456492.1456493

[2] M. Jensen and N. Gruschka, “Privacy against the businesspartner: Issues for realizing end-to-end confidentiality inweb service compositions,” in Proceedings of the 2009 20thInternational Workshop on Database and Expert SystemsApplication, ser. DEXA ’09. Washington, DC, USA: IEEEComputer Society, 2009, pp. 117–121. [Online]. Available:http://dx.doi.org/10.1109/DEXA.2009.38

[3] H. Zwingelberg and M. Hansen, “Privacy protection goals andtheir implications for eid systems,” in Privacy and IdentityManagement for Life, ser. IFIP Advances in Informationand Communication Technology, J. Camenisch, B. Crispo,S. Fischer-Hbner, R. Leenes, and G. Russello, Eds. SpringerBerlin Heidelberg, 2012, vol. 375, pp. 245–260. [Online].Available: http://dx.doi.org/10.1007/978-3-642-31668-5 19

[4] M. Rost and A. Pfitzmann, “Datenschutz-schutzziele - revis-ited,” Datenschutz und Datensicherheit, vol. 33, no. 6, pp.353–358, 2009.

[5] M. Rost and K. Bock, “Privacy by designand the new protection goals,” EuroPriSe Whitepa-per. [Online]. Available: https://www.european-privacy-seal.eu/results/articles/BockRost-PbD-DPG-en.pdf

[6] A. Pfitzmann and M. Hansen, “A terminology for talk-ing about privacy by data minimization: Anonymity, un-linkability, undetectability, unobservability, pseudonymity,and identity management,” URL: http://dud. inf. tu-dresden.de/literatur/Anon Terminology v0, vol. 34, 2010.

[7] F. Majernik, M. Jensen, and J. Schwenk, “Marv - data levelconfidentiality protection in bpel-based web service compo-sitions,” in Proceedings of the 6th International Conferenceon Network Architectures and Information Systems Security(SAR-SSI), 2011.

[8] B. Carminati, E. Ferrari, and P. C. K. Hung, “Securityconscious web service composition,” in Web Services, 2006.ICWS 2006. International Conference on, 2006, pp. 489–496.

[9] J. Han, R. Kowalczyk, and K. Khan, “Security-orientedservice composition and evolution,” in Software EngineeringConference, 2006. APSEC 2006. 13th Asia Pacific, 2006, pp.71–78.

[10] R. Herkenhoner, H. de Meer, M. Jensen, and H. C. Pohls,“Towards automated processing of the right of access in inter-organizational web service compositions,” in SERVICES,2010, pp. 645–652.

[11] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana,“Web Services Description Language (WSDL),” W3C Note,2001.

[12] S. Bajaj, D. Box, D. Chappell, F. Curbera, G. Daniels,P. Hallam-Baker, M. Hondo, C. Kaler, D. Langworthy,A. Nadalin, N. Nagaratnam, H. Prafullchandra, C. vonRiegen, D. Roth, J. Schlimmer, C. Sharp, J. Shewchuk,A. Vedamuthu, mit Yalinalp, and D. Orchard,“Web services policy 1.2 - framework (ws-policy),”W3C Member Submission, 2006. [Online]. Available:http://www.w3.org/Submission/WS-Policy/

[13] H. Foster, G. Spanoudakis, and K. Mahbub, “Formal Certifi-cation and Compliance for Runtime Service Environments,”in 9th IEEE International Conference on Service Computing,2012.

[14] C. Ardagna, E. Damiani, R. Jhawar, and V. Piuri, “A Model-Based Approach to Reliability Certification of Services,” inin Proc. of the 6th IEEE International Conference on DigitalEcosystem Technologies - Complex Environment Engineering,2012.

[15] M. Anisetti, C. A. Ardagna, and E. Damiani, “A Low-CostSecurity Certification Scheme for Evolving Services,” in inProc. of the 19th IEEE International Conference on WebServices (ICWS 2012), 2012.

[16] S. Weerawarana, F. Curbera, F. Leymann, T. Storey, andD. F. Ferguson, Web Services Platform Architecture: SOAP,WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-ReliableMessaging, and More. Prentice Hall PTR, 2005.

[17] F. Kerschbaum, A. Schropfer, A. Zilli, R. Pibernik, O. Catrina,S. de Hoogh, B. Schoenmakers, S. Cimato, and E. Damiani,“Secure collaborative supply-chain management,” IEEE Com-puter, vol. 44, no. 9, pp. 38–43, 2011.

205