Enabling Usage Control through Reputation Objects: A Discussion on e-Commerce and the Internet of Services Environments

This paper discusses the meaning and the role of Trust and Reputation in Internet-of-Service and e-Commerce environments following a comparative case study. Both environments represent paradigms through which the Internet is seen as a huge infrastructure where electronic services or real products are traded on. In comparison to electronic commerce, participating in an Internet-of-Services can be full of risks for all participants. Even well known security mechanisms are not able to close all gaps of access and usage control. This paper discusses the concepts of trust and reputation and brings to light the relation between these concepts to security mechanisms, Service-Level-Agreements, and quality measurements in order to enable Usage Control. The proposed solution is based on our previous model of reputation objects. The discussion also introduces a new concept of what we call reputation auditing where quality processes are considered part of reputation management not the other way around.

This paper discusses the meaning and the role of trust and reputation in Internet of Service and e-commerce. The discussion build up to the goal of using our model of reputation objects to enable usage control. We elaborate on our previous work in the model and in usage control, and then relate both works at the end of the paper. This work follows the methodology of a comparative case study [19]. Following the work of Eisenhardt, we will compare two use cases, both covering the issue of trust and reputation problems through qualitative observations. The first use case covers the topic of Electronic Commerce, where the trust problems have been known since popular websites for Consumer-to-Consumer (C2C) businesses like eBay came up and provided a reputation model to cover the problem of asymmetrically distributed information between seller and buyer. The second case considers the same problem in a fully automated environment (Internet-of-Services) where software agents are interacting with each other. Like we will see during this paper, the problem of asymmetrically distributed information is very similar to the ecommerce case.

Outline of This Paper
In section 2, we first explain the definition of trust and reputation (ours and in the literature), with a brief view on trust management and trust problems. Defining main concepts that we use during the rest of the paper such as quality, service level agreements, and usage control follows in section 3. This is followed by a description of the IoS and e-Commerce scenarios. Based on these presented scenarios, section 4 will explain and relate our model of reputation objects to these scenarios. In the same section we show the relation to quality and what the information sources are in both domains. Finally we discuss the development of a framework that enables Usage Control using reputation objects and show the model benefits in section 5.

Trust and Reputation
We start with defining the term reputation and relating it to the term image. Later we elaborate on a detailed definition for reputation respective to the domain it is used in.
Image is an averaged evaluation from an individual of a given target. It consists of a set of evaluative beliefs [32] about the characteristics of a target. These evaluative beliefs concern the ability or possibility for the target to fulfil one or more of the evaluator's goals, e.g. to behave responsibly in an economic transaction. An image, basically, tells whether the target is ``good'' or ``bad'', or ``not so bad'' etc. with respect to a norm, a standard, a skill etc.
In contrast reputation is the process and the effect of the transmission of a target image. The evaluation circulating as social reputation may concern a subset of the target's characteristics, e.g. its willingness to comply with socially accepted norms and customs. More precisely, we define reputation to consist of three distinct, but interrelated objects: (1) a cognitive representation, or more precisely a believed evaluation (any number of agent in the group may have this belief as their own); (2) a population-level dynamic, i.e., a propagating believed evaluation; and (3) an objective emergent property at the agent level, i.e., what the agent is believed to be as a result of the circulation of the evaluation [16].
Putting it simple, an image is the picture an individual has gained about someone else (the target) based on his own previous interaction with that target. Dealing with reputation, the individual expands the information source about the target beyond its own scope and includes the information of others about the target as well. There are different reputation models available that support their corresponding agent in building, managing or using trust information. Here, it does not make a difference if the agent is a human agent or a software agent, only the concrete implementation of such trust and reputation model will make the difference. Humans use cognitive models to model trust relations; software agents are able to use mathematical approaches for simplicity reasons. Sabater and Sierra provide more details in [44]- [43] on how image, reputation information or a combination of both can lead to trust.
In the literature, reputation is defined as an expectation about an entity's behaviour based on information about or observations of its past behaviour [41]. In the business world, Balmer [4] defines two characteristics for Corporate Reputation: it evolves through time and is based on what the organization has done and how it has behaved. It deals with the cause of a problem, offers solutions, set processes in motion, and monitors progress towards these solutions. In the corporate environment, reputation is often confused with branding. Branding is a marketing concept that collects symbols, experiences, and associations connected with a product, a service, a person, or any other entity [25]. Reputation on the other hand is the major factor that formulates an opinion about a brand. The use of correct reputation in the business world is the key point to minimize risks. In today's economy, 70% to 85% of market value comes from hard-to-assess intangible assets, which makes organizations especially susceptible to anything that damages their reputation. A positive reputation can contribute to profits. According to [4], [18], three things determine the extent to which a company is exposed to reputational risk: whether its reputation exceeds its true character, how much external beliefs change, which can widen or narrow this gap, and the quality of internal coordination, which also can affect the gap. There is an increasing body of evidence demonstrating the link between financial performance and a strong reputation.

Trust Management
In [14] the authors differentiate between trust in the computing paradigm and in the business one. They consider "trusted computing" as "trust in security context"; which is related to security issues, security mechanisms, security technology, and security services. In general, they define it as all topics of security study and research directed towards providing a secure and a tamper-free environment, network, or communication. This is not the same as trust in the business paradigm (the trust between the customer and the business provider). They define trust in this domain as a specially tailored trust for ensuring honest dealings and quality of products or services and that is usually related to mutual agreements and understandings ( Figure 2) [14]. This distinction corresponds to the two categories of trust management approaches identified in [12]. Trust management can include security measures (policy-based) and soft trust relationships (reputation-based). The idea is the same however; Trust and Security are complementary technologies. Policy-based approaches define permissions, obligations, norms and preferences for an entity's actions and interactions with other entities. It can also be defined as a set of rules and practices describing how an organization manages, protects and distributes sensitive information at several levels. The result is a binary decision-trusted or not. Reputation based approach depends on user's local experiences and feedback to create a soft measure for trust decision. However, the two trust management approaches address the same problem which is establishing trust among interacting parties in distributed and decentralized systems [9].
Reputation is used to establish this kind of trust for interacting entities. It can be established for entities like web communities' users (i.e. e-markets, blogs, social networks), services (in service oriented architecture), or software agents. In the online community, trust and reputation (or rating at this point) is represented numerically or graphically using bars and stars, karma, or in natural language. The range of possible values for a trust level varies according to each system along with the meaning of these values. Online reputation systems can also be categorized based on the common features and properties of the online communities: [3] 1.  In these systems they use the following definitions to describe reputation target, model, and context:

The Problem of Trust
If enforcement methods like institutional frames or insurances are not available or not implemented, the reputation concept seems to be the most suitable way to overcome the obvious moral risks of being betrayed by some not wellbehaving transaction partners. Resnick and Zeckhauser state, "whenever one individual depends on the action of another, an agency relationship arises" [42]. The agent, who is taking action for the principal, has usually an edge on information on the activity it has to fulfil. If the principal is not able to monitor the agent's actions on low costs or due to technical reasons, the challenge arises. On a larger scale this situation occurs if markets are used to allocate resources, i.e. when services and goods are offered to potential consumers over this market. In such situations there is a high potential of deceit from either sides (i.e. consumers not paying, providers not delivering the services or goods, bad review regardless the good service ( Figure 5)).
In order to tackle this problem Pratt and Zeckhauser propose to construct a reciprocal relationship between principal and agent [42]. That means, for each pair of interacting participants a principal-agency relation in the opposite direction has to be constructed, i. e. both participants have to fulfil the roles of principal and agent at the same time. The service consumer (principal P) requests a service and the provider (agent A) fulfils this guaranteed service. To meet the second principal-agent relation a reputation mechanism has to be established: the principal in the first case is now the provider of a (potentially good) reputation value and therefore fulfils the role of an agent. The service provider, in the first case the agent, is now acting as principal, which pays with quality of service and receives a reputation value, which is functionally dependent on the quality of service. When applied for a huge amount of participants and transactions such reputation concepts will significantly increase the efficiency of the overall market. [20].  Figure 4 illustrates an example of a reciprocal principal-agent relationship in a service market: The first relation is easy to construct: the consumer (principal) requests a service and the provider (agent) fulfils this guaranteed service. The price, which has to be paid for the received service s, is denoted by p. The prices are determined through the framework contract all participants have signed. This contract defines the valid time, the price for the service, the service's definition and a reputation threshold that all service providers have to fulfil.
To construct a second principal-agent relation a reputation mechanism has to be established: the principal of the first case is now the provider of a (potentially good) reputation value and therefore fulfils the role of an agent. The service provider, in the first case the agent, is now acting as principal, which pays with quality of service and receives a reputation value, which is -assumed-functionally dependent on the quality of service. This reputation should be published for a huge amount of participants to increase its significance [20].
Depending on the reputation values of the service provider, a deduction of risk r i for each service has to be paid. The consumer has to pay this deduction of risk less, but receives a risk Risk i in addition to the service. It is the responsibility of the service provider to have a good reputation in order to decrease this deduction of risk. Since the reputation is -assumed-functionally dependent on the provided quality of service (QoS), the QoS is finally responsible for the deduction of risk of the following contracts. Hence, the service provider should always fulfil the expected quality standards.
On the other hand, the service consumer receives the service and the risk of an uncertain execution (i.e. the service is not executed as the provider has promised before). The consumer is not able to determine the risk before

Reputation Exchange Problems
Although reputation systems are used as the basis of trust in many of the online communities, these communities cannot share reputation information. Even when this collaboration can lead to building a knowledge base about multiple participants in the market, the exchange of reputation information is still not feasible. The reasons are: • each system has a different way of data entry or enquiry, • different approaches to calculate the reputation value for use in the current timeslot (i.e. Sum approach, Average, deterministic, Bayesian, fuzzy systems, etc.), • different representation for this value i.e. different interactions styles, scales, etc.. [1] • difficulty of collecting evidence • distinction between the high and the low quality of services • incomplete or non-comprehensive provided information • an attractive website offers little evidence about the solidity of the organization behind it Therefore it is hard to assess and exchange reputation between e-markets due to the difference in perception, calculation, interpretation, but most of all because the given reputation is an overall one that doesn't reflect the related contexts in which it is earned. These contexts can vary from the category it is earned (i.e. a selling transaction) to the quality aspects of one transaction (i.e. different quality criteria or attributes).

Quality Concepts
Quality is defined as the level to which a set of characteristics fulfils requirements. The International Organization of Standardization (ISO) defines it as: "the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs". A quality attribute is a specification or a feature that is regarded as a characteristic of an action or an entity (i.e. product, person, service). Usually it reflects a level of performance to this action. They vary according to the context and domain they are measured in. They can also be described as quality dimensions, quality measures, and quality criteria. When using a quality attribute, it should be defined in relevance to the domain, its possible values and how it can be measured (subjective attributes can have an approximated measure or mapped meanings

Quality Processes
Quality control and assurance organizations exist for a wide range of topics, products, specialties and services. The goal of these organizations is to control the quality of developing systems to ensure products or services are designed and produced to meet or exceed customer requirements. Reputation, as a concept, aids in quality assessment in several environments. It can be used also as a way to solve problems that need large-scale collaboration like resource allocation. However, questions regarding the relation between quality and reputation are not answered such as: does quality control performed by standardization organizations lead to good reputation? Does quality control generate measurable reputation or vice versa?
In some communities the two terms reputation and quality assessment are legally different [12] where Reputation refers to public opinion rather than a method to judge quality. U.S. News (see Site 1) for instance, announced that the surveys they are conducting in their process of setting universities ranking are quality surveys not reputation surveys. This can be understandable in businesses or communities that have solid measures for assessing quality but there are entire sets of industries that depend on the so-called public opinion such as the music industry. Quality in these industries means most of the time popularity or more generally reputation.
In order to understand the difference, or the connection, between quality control, quality assurance and reputation, we define first the former terms. For simplicity, the domain of our definitions is software engineering in which quality control and quality assurance are useful to manage risks of developing and managing software.
• Quality Assurance (QA) is a set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. QA activities ensure that the process is defined and appropriate.
• Quality Control (QC) is a set of activities designed to evaluate a developed work product. QC activities focus on finding defects in specific deliverables.
Tom Mochal, president of TenStep Inc., identifies the difference between both sets as: "QA is process oriented and QC is product oriented. Where QC activities are focused on the deliverable itself, QA activities are focused on the process used to create the deliverable".

Service Level Agreements (SLA) and Service Level Objectives (SLO)
Another important field of related work is how the participants can agree on certain service levels. In decentralized environments like the Internet, one is not able to establish a central unit to measure service quality. Nevertheless participants in an Internet of Services (IoS) environment need a reliable document structure that allows negotiating before and measuring quality aspects after interaction takes place; that is a Service Level Agreement (SLA).
SLAs have been discussed in different fields of electronic commerce and distributed computing [29], [33]. Usually they include functional and non-functional quality attributes that the service provider and the service consumer negotiate on before interaction takes place. As they can also define penalties that are due when an agreed attribute is not met by a participant, they represent an important input for quality measurement after the service delivery. By employing the SLA concept, a robust and reliable service-oriented architecture in electronic commerce as well as in distributed computing can be realized [22].
SLAs can be defined and used within different abstraction layers. They can be defined for single services as well as for complete IT infrastructure, which can be outsourced to external service providers. Each SLA consists of different Service-Level Objectives (SLOs) that are deducted from the functional requirements. Some SLAs and the corresponding SLOs is written in machine-readable files (e.g. XML files) but others are written in plain natural languages (i.e. in electronic commerce contracts and agreements) [24].

Usage Control
Protecting access to digital resources is one of the fundamental problems in computer science. Access Control is an attempt to secure particular resources (objects) by particular entities (subjects). To fulfil these requirements the models have to implement the possibility to permit or deny the access rights. Traditionally, three implemented access control models fulfil this under slightly different conditions: Discretionary Access Control (DAC), Mandatory Access Control (MAC) and Role Based Access Control (RBAC).
The first approach -DAC-makes use of an access matrix that specifies the owner of an object. Each object has exactly one owner. The access permission is defined on a certain object and the permission can also be delegated indirectly. That means, if the owner of an object delegates also the permission to assign permission rights, this agent is able to do so, even if the owner is not informed or does not agree on that [40]. However, this approach does not distinguish between the ownership of an object and subjects that are operating on behalf of another subject. result of this limitation, if a malicious or incompetent subject obtains the ownership of an object, nothing can stop the subject when destroying all discretionary protections. DAC policies do not enforce any control on the information flow [27].
Controlling this information flow is an important goal of the MAC approach. This approach aims at ensuring confidentiality and the integrity of the digital information. Comparing to DAC, in MAC the subject does not have the ability to override or to modify the security policy. This security policy has to be defined by a central authority. The approach guarantees the enforcement of these policies by using the multi-level security mode. Access rights of the subject are defined by its position in relation to the object [45]. Although subjects are permitted to access objects at any level below their own level, the strict notation of the Bell-LaPadula [5] restrictions results in too rigid constraints especially in dynamic and heterogeneous systems [27].
Finally, the RBAC approach presents an access control model powerful enough to simulate DAC and/or MAC. The main motivation is to merge the flexibility of explicit access control along with additionally imposed enterprise-specific constraints. The RBAC protection system regulates the access to objects based on organizational activities and responsibilities. The subject playing a certain role is allowed to execute all privileges for which this role is authorized which in return simplify the security administration. If a user fulfils a new or an additional function it can be allocated to new roles and the subject gets new access permissions [27]. However, RBAC is the most expressive and generalized approach for it simulates the other approaches. Nevertheless, it is not applicable in IoS because it requires a centralized unit with additional enforcement possibilities. A suitable unit that might fulfil this role is not available in IoS.
These traditional approaches work quite well if central units can decide on the access and the decision rules can be implemented in a static way. This central unit decides on the "permit" or the "deny" access. This decision is based on, for instance, certificates that the subject can show when trying to get access. For unknown entities, trust and reputation models are proposed to estimate the trustability of these entities [48].
Addressing new challenges regarding the increasing complexity of systems, some researchers proposed recently a comprehensive framework to indentify limitations of current approaches; Usage Control [37], [35], [39]. Park and Sandhu [38] define in their UCONABC framework six components in the usage control model: authorisation, subject, object, rights, obligations and conditions. Following their definitions, a subject is an entity that holds and exercises certain rights on objects. Whereas authorizations evaluate subject and object attributes together with the permitted rights and the underlying rules, obligations define mandatory requirements a subject has to fulfil before or during the usage. Conditions are defined as: "condition predicates and evaluate current environmental or system status to check whether relevant requirements are satisfied or not and return either true or false". For our framework, the conditions component is of highest importance, as it represents the environmental and system-oriented decision factors of the decision making process.
Server-side mechanisms, like certificates, trust management or traditional access control mechanisms determine the decision if a subject is permitted to get access to an object or not. However, decisions during runtime are not addressed by traditional approaches. Thus, we can state that access control in its traditional meaning does not cover challenges ``in open, distributed, heterogeneous and network-connected computer environment[s]'' [27]. In both IoS and in e-commerce environments, choosing credible services is a major challenge at runtime (preventing access control from being implemented properly). This is because the decision process is crucial in dynamic environments where conditions cannot be defined at build time. In our work, we are focusing on the condition component.
In the remainder of the paper, Section 3 shows the studied use cases. Section 4 and 5 explain what Reputation Objects are and how we can use them in order to support the decision process in usage control. With the help of reputation objects, we propose a mechanism that allows revoking participants due to their former behaviour and thus provide a larger basis of decision-making. In IoS, the importance of reputation information here is that well-disposed participants' opinions can return a service from its revoked state. In e-commerce, users have to be authenticated (i.e. using digital certificates, or check the identity by mail). Nevertheless, during run-time the service provision should be fulfilled directly between participants and not via the market place, which is done by using a measure of trust or reputation. In this case the market place has no possibility to check the correct service delivery.

Use Cases
This section will introduce two use cases that are used later to make the theoretical concepts clear. The first use case is E-Commerce, where human actors converge to negotiate on products. The second use case focuses on the Internet of Services. Within this scenario, intelligent services negotiate with each other on electronic services.

Use Case 1: E-Commerce
We will use for illustration a simple example of an online purchase transaction. Bob is a customer who wants to order a television via an e-Shop. Relying on the description of the seller, he expects the delivery within two weeks. Unfortunately he receives the order after one-week delay. Later he was asked by the online rating system of Torsten the marketplace to give a rating for the seller. Since Bob was not satisfied by the delay, he gave a low rating indicating in natural language "because of the late delivery". Here, the given rating doesn't indicate that the "quality" of the TV is low. Bob is quite satisfied by the quality of the television, as it has met the description of the seller before he ordered the device. But as the provided rating system uses a single value for all the services or aspects of the seller, Bob provided a low rating due to his disappointment with the delivery time. In conclusion, delivery and quality are two different contexts that should be rated separately. In our research we mimic real life reputation mechanism, where one gives one's feedback in natural language targeting a specific context. This is a simplified version of the amount of problems that can arise from such general rating. A study about the legal challenges that face online reputation systems is done by [12]. By exploring legal cases of big market places like eBay (California, Grace vs. eBay) and Amazon (cases in UK and USA), the authors concluded that the main issue in these lawsuits is the general rating or "rating ambiguity". The rating is misrepresented in a way that influences market entities negatively. From the legal point of view, systems like eBay hold no responsibility for users who are expressing their taste. What is important from the legal perspective is the distinction between "expressions of fact" and "opinion". Even if eBay instituted a limited assurance coverage, the problem still exists and growing. The key point to the solution is to give the possibility of making more concrete rating, storing concrete set of attributes to the rating, and later using these attributes to infer knowledge on the facts of the transaction.

Use Case 2: Internet of Services
The increasing dynamics of markets lead companies to adapt their processes to the changed environment. For every-day business, the use of computationally intensive information technology (IT) seems essential to implement new flexible business models within a short time. In contrast to these advantages, the operational expenses of the technology, including usage and maintenance of the IT infrastructure, are exploding; in particular, if the resources in question, like storage or CPU power, need to be dimensioned to cover peak demand while only sparsely used otherwise. Staying competitive requires saving costs in this area. The Internet-of-Services (IoS) describes a general computational paradigm, which allows companies to procure computational resources externally and thus to save both internal capital expenditures and operational costs. Depending on how the resources are treated and who the external provider is, several sub-concepts can be distinguished. The notion of Internet-of-Services follows the idea of consuming different services externally, provided by a distinct service provider, but from a blurred cloud of resources within a single business unit or even between different businesses [32]. As the interaction frequency is assumed to be very high and the volume of a single interaction is assumed to be very small, the whole process has to be fulfilled without human interaction. The process includes: finding a suitable service provider, negotiating with it, invoking the service, and finally fulfilling the post-processing if necessary.
To match providers and consumers, an efficient allocation mechanism between service demand and supply is needed: a market [47]. But introducing a market will lead to other problems, e.g. asymmetrically distributed information between service providers and consumers. Service providers usually have more information about quality or availability of the services they provide, than their potential users (consumers). Further, the effectively provided functionality might differ from the promised functionality. This case of asymmetrically distributed information usually leads to suboptimal results due to the uncertainty on the consumer side, and thus to an inferior usage of the service environment in total. Side-inverted, consumers have more information about their liquidity. In addition, both interaction participants deal with uncertainty caused by environmental factors (e.g. network failures). One common way to overcome this asymmetrical information distribution is the usage of trust and reputation models. The direct experiences, experiences from other participants or just gossiping received from other participants about a target service can influence one's behaviour. The usage of trust and reputation models is quite common in decentralized environments, because no central entity (that has central knowledge or even central control) has to be implemented. Comparing this scenario with the e-commerce, agents are acting on behalf of users. But a single interaction takes place without any interaction with the real-world pendant. Within the e-commerce scenario, only the communication is electronically supported, the participants themselves reach the decisions. What both scenarios have in common is that they have to address challenges based on the open character of the systems. Almost everybody can participate after running through an authentication process.

Redefining the Reputation Concept
The rapid evolution and use of open systems require a special consideration of all elements that builds up these systems. As discussed earlier, one of the major problems in trust management systems is the correct representation of reputation. In our previous work [3], [1], [2] we have analyzed the problem and proposed a new way of representing reputation by the means of what we call Reputation Object (RO), along with setting requirements for solving this problem. The basic idea and solution is that reputation cannot be viewed as a single value anymore. In this section we illustrate the concept of our model: reputation objects, the elements that construct it. And then we elaborate on using SLAs and quality processes as information sources.

The Reputation Object Model
A reputation object is a reflection of how complex, yet comprehensible, the concept of reputation is. Simply put, it contains a list of contexts (in which reputation is earned) associated with their corresponding values and related information. In the TV factory example presented before, we discussed how a customer is giving a rating to the wrong context (i.e. rating indicates the "quality" of the product but the low rating was meant for "delivery"). Associating context with trust definitely increases the complexity of the overall system but it is critical for deriving meaningful trust. Later, we will elaborate the details of reputation objects relative to each use case.
A ReputationObject is constructed either offline or during negotiation process. It's a generic object that changes according to the domain and the user preference but in general it holds a complete profile (functionality, quality, ratings, etc.) about an entity (service or agent), which is collected from heterogeneous information sources. In Figure  6, the model classes and relations are illustrated. We begin with some essential definitions in our model in the following table: Table 1: Definitions in the reputation object model

Reputation Object (RO)
An object that contains structured information on an entity (the reputation object's owner) to evaluate the expectation of its performance in one or many contexts

Reputation Information sources
Describe all sources used to collect reputation information about an entity. Examples: feedbacks, direct experiences, ratings, service level agreements feedbacks, logs, system analysis, etc.

Reputation Context
A relevant category in which a specific reputation is earned. A context can be an objective (measurable) or a subjective one (non-measured but can have an approximated evaluation). Examples: a person's reputation in driving, a factory's reputation of producing quality goods, a service's reputation in its response-time, a post 's reputation as likable to users, a movie's reputation in its storyline.

Criteria
A characteristic, a property or a measurement by which an entity is judged or evaluated in a certain context. A criterion c can be a part of a context C and is a context itself: c C

Quality Attribute
A characteristic used to reflect an entity's level of performance. A quality attribute acts as a reputation criterion

History List
For a single context or criterion c in an entity's RO, a history list describes a list of past values given to this entity regarding this particular context or criterion

Values Type
Describes the data type of a reputation criterion

Set of Possible Values
Describes the set of the possible values that a reputation criterion can have

Order of Possible Values
Describes the order of a set of possible values for a reputation criterion, statically by defining a specific set or dynamically by defining an order function, ordered from the relative best to the relative worst

Computed Value
Describes the new computed value v of a reputation criterion c after a reputation transaction t using its associated function f such that: v(c,t) =f c (vNew t , HistoryList)

Computation function
A function f related to a reputation criterion c that is used to compute or aggregate a list of the criterion's past values HistoryList to get the new computed final value v

Collecting Algorithm
The algorithm used to collect the value of the reputation criterion either by direct input to the value or by a sequence of steps that leads to this value

Reputation Query
Any query made about an entity's reputation object or the system participant's reputation objects From these definitions, we identify that when constructing a reputation object for a participant of any domain for each context/criteria the following information is a requirement: In this paper, we focus on two domains: e-commerce and Internet of Services by investigating the domain participants, their relationships, interactions, and the flow of information between them. This focus brought to light: how quality processes are connected to reputation management, and why.
• how reputation is a concept that enclose quality assessments not the opposite, and • how we can use reputation objects to enable usage control (discussed next section).
A reputation object can be constructed by discovering the contexts building up an existing system. Instead of dealing directly with the one context that describe the domain -highest ontologies or concepts in the system-, the process requires gathering more information about the domain by the means of tracking the sub-ontologies. Using this information reputation is represented differently. The use of ontologies here serves as a way to identify a domain's context or a criteria, and the associated quality attributes. In [6], the author elaborated on his view of Semantic web where structuring the various factors in a user's opinion is done using ontologies. Ontologies unify diverse understandings by introducing a central perception hierarchy for different knowledge domains. A generic approach should not be dependent on one domain ontology, but be open for any domain. Any domain ontology must be adapted and adjust over time.

RO for e-Commerce Participants
The main problem when attempting to give an entity correct reputation values is that the context in the reputation query is too general or nonexistent, for that matter. And since the context is a key component in any reputation query, correct reputation values can only be built if the domain is broken down into contexts, criteria (that describes the subcontexts that construct one context when aggregated), and quality criteria.
In that sense, we define reputation as the process of profiling a seller or a customer to evaluate the expectation of its performance in some or all of the contexts involved in the e-market transactions. The following assumptions are made: • A ReputationObject is constructed either offline or during negotiation process.
• A domain is the general business description of a market entity • A context is the key component in a reputation query addressing a market entity • A quality_attribute in a reputation_query describes a quality measure of a service that is specific to a certain entity • Each context in a reputation_query is associated with a context_name, a set of quality_attributes or criteria, and aggregation_method to aggregate the values of related quality_attributes into one value to be assigned to the context.
The TV factory example, mentioned before, illustrates that there are three sub-contexts/criteria (for simplicity) to be rated; delivery, quality, price. In this case the reputation object holds 3 criteria, each has a value, name, description, set of possible values (with the order), and computation algorithm (to compute the new criteria value). A simple view for this RO would be: RO={ (quality,"excellent"), (delivery, "Slow"), ( This way, not only the user can rate the right context but also can select the provider according to his own preferences.

RO in the Internet of Services Market
Applying the same procedure used in the e-commerce example (also in Figure 8), we can construct a reputation object for a service consumer or provider (or for the service itself). The principle is to use different information sources to decide: • The contexts used to evaluate a service consumer, a service provider, or a service's behaviour and/or the quality_attributes (specific to each context) that measure the quality aspects of the participants.
This is done by using elements of the involved SLAs and to SLOs in the domain. As mentioned before, SLOs define functional or non-functional attributes that can be used as criteria in an entity's RO. With addition of information from the service description and service history ratings, a service RO is easily constructed and exchanged between the market participants. After the web service invocation, the service quality can be measured regarding the functional attributes. Depending on the importance of the single objects, both sides can build their own image on the target and can send this information to other participants.

Using Quality to Construct Reputation
From the above description of the reputation object, we can see that in order to form an opinion about an entity, information about their quality of services should be acquired. So we can see that quality processes are closely connected to reputation concepts. Where most of the literature views quality as a higher concept that enclose reputation, we view it as the opposite. In the example, instead of giving one single value to represent the overall quality of a seller's services, we use the operational steps of quality processes to construct the RO. In figure 8 Domain means what object to be rated (i.e. Electrical Factory), Context means which area to be rated (i.e. Delivery, financial, insurance), quality_criteria breaks down the context to more specific questions: Was the price good? Does the insurance cover accidents for the product, and so on. This paper is available online at www.jtaer.com DOI: 10.4067/S0718-18762010000200005 of the service performance has been explored. In [7] and [8], the authors use client side monitoring techniques to generate information regarding functional and non-functional (QoS parameters) properties of service behaviour. They also use three components to manage service reputation: Reputation Manager RM (collect feedback from the clients), Subscription Manager (disseminate information provided by RM or by the Service Directory), Extended Service Directory (manage registered services). RM can provide reputation information only on services for which it has collected sufficient client feedbacks not new registered services. Clients are required to submit a binary report only of whether the service met the quality constraints set in the Service Level Agreement SLA (with timestamp). Their technique ensures honest feedback through incentives usage. The construction of service reputation depends only on feedback and reports are given in binary form without detailed description. In their approach they focus on user feedback only as a source of evaluation. In [34], the authors identify some problems regarding collecting service quality information like: (a) Researches focus on implementation level performance assurance, ignoring domain based or application level metrics which are also very important to service users, (b) Industry Web service standards lack QoS expression. The support for QoS based service choice-making is very limited.
Maximilien and Singh [30] designed a conceptual model of web service reputation and stressed on the importance of differentiating generic and domain based quality attributes. So in order for the agent to make intelligent decisions, it needs more than just the reputation and endorsement agencies. It needs knowledge of attributes the user cares about. Later in [31] they describe their approach as QoS-driven discovery and selection, where brokers can enable dynamic selection of services using QoS. The brokers use third party certifiers to collect QoS data on the services. The source of evaluation in this work is past interaction and user preferences. In [28] reputation is viewed as one single attribute in the generic quality category. It is merely the average ranking given to the service by end users [11]. Cardoso introduced a service work-flow QoS model but it is based only on historical data, so did Chandrasekaran [13]. In these projects QoS cover only common performance metrics such as time, cost, and reliability.

Information Sources in e-Commerce
The first source of information in the domain of e-commerce settings is the product description. Some of these information sources have higher importance depending on the kind of market place. For example, photos of the product are especially important for second-hand goods. A product description written in natural language might also be important to illustrate the traceability or the location of the seller or offered payment models, like escrow services [36].
The second source of information is provided by the market place. The market place is able to define the policies all participants have to follow. This includes the definition of the authentication and authorisation processes, which can be mandatory or optional. Some market places provide additional certificates if one participant fulfils additional requirements, for example is selling or buying frequently.
The next source of information is the reputation system, which represents more or less the past behaviour of all participants with the target. Next to a mathematical representation (like stars, average values, etc.) this can also be represented by textual comments from other users. Another information source is the meta-information the reputation model provides, like how many ratings the target received in the past or how many ratings have been petitioned (rating claimed to be not true) [17].
However, there are two complexities of getting the right information source: deciding between user data versus nonuser data, and differentiating between quality and popularity; or what we call the-cool-effect. The first problem can be addressed through an example of a survey done by US.News, which is a very popular source for ranking universities. Their rankings are based on data from the Times Higher Education World University Rankings. Their surveys target only specialists (i.e. through academic community opinion and Quality assurance agency for education). But the fact is even specialists are affected by recommendations or stories of users (either in real life or in the blog sphere). For business organizations, stamp from an Organization like ISO9001 is enough to qualify a business as one of the best within a certain context. So the question of whom to trust; standardization organizations or users ratings, depends solely on the recipient, domain and context, and potential gain.
The second problem is a question of taste. Sometimes the reason for a good rating is just: It is cool! This statement might be translated to an increase of rating. This creates a problem for people who see reputation as a scale of quality; popularity does not necessarily represent high quality. Also, popularity is not one of the factors considered by quality control and assurance organizations.
We address both problems by simply combining all sources of information to construct the participant reputation object. Each source can represent a new element in the criteria list, i.e. popularity is a criterion.

Information Sources in Internet of Services
Like in the e-commerce use case, the goal is to select a service based on their reputation. A reputation object is constructed to be able to identify a reliable service from trustworthy service providers. A consumer can choose a service based on the service quality aspects. These aspects are prioritized based on the consumer's preference list. An important information source in this case is the service description, which is exchanged during service negotiation. Within the Internet of Services vision, well-established notations like the Web Service Definition Language (WSDL) should be suitable to describe the service's functionality [15]. The service quality itself can be discovered by the implementation of monitoring services. But without a centralized institution to enforce central monitoring service, it is an extensive procedure for a single participant to observe interactions. Only if they are involved, they are assumed to be able to monitor the real service quality. Information sources in this case are: ratings provided by the reputation systems, direct experience/past behaviour, and the meta-data on the target.
The provided SLAs can form the building basics of a reputation object (i.e. an occurrence of a new quality attribute name in an SLA results in a new criteria element in the reputation object). Sometimes the form of SLAs themselves is a good indicator of the service quality. Especially if the service provider disclaims providing measurable quality metrics within its SLA, the service consumer might assume low quality. The amount of information revealed in an SLA can be negotiated in an Internet of Services. The content of the first SLA proposal can be used as a quality indicator, especially if other information sources are missing.

RO for Usage Control in IoS and e-Commerce
In the previous section, we elaborated on the basic construct of our model; the Reputation Object. We also explained how quality aspects are used as a set of evaluation criteria in the object. The process of defining what forms a user or a service reputation object is a dynamic one (changes through time) and depends on the domain the object being used. Quality aspects and quality assessment criteria are key concepts for the trust ontology in the service-oriented environment. In this environment, as well as in the corporate environment, reputation deals with the cause of a problem, offers solutions set processes in motion (which is similar to quality assurance) and monitors progress towards these solutions (which is basically quality control). One of the most important business processes in an organization is to identify all the issues that affect its reputation. We follow the same rule to ensure the usability and reliability of our model ( Figure 9). We define the process as: Reputation Auditing. The process of assessing the quality of the reputation process itself by ensuring that all elements of the involved reputation model exist, and by continuously monitoring the progress towards better solutions.

Usage Control through Reputation Objects
Given the appropriate level of detailed information in a Reputation Object, all the necessary information to implement Usage Control (controlling the users during run time) can be easily provided. One of the important examples is the use of security settings as one context in the reputation object context list (illustrated by inheritance in Figure 10). This allows a decision of each participant if it fulfils the security requirements. If the security settings are included in the reputation objects -exchanged during the negotiation process -a user can ask for a change in the encryption method used by the other party, for instance. Resuming the two different use cases, we can see that this concept is already implemented in parts. In an Electronic Commerce setting, a consumer choosing a marketplace for its transactions has usually information on the certificates the web site has, the payment model that has to be used (bank transfer or a specific escrow service). Also the participant might know the authentication process. The market place, for example, can check the users' real identities by non-electronic services. The second use case (Internet of Services) does not change significantly from the e-commerce example. The authentication can be based on the IP address of the user, whereas the authorisation is based on the concepts like DAC, MAC or RBAC, which have been explained during section two. Compared with a static service level description and how it has been already realized by SLAs, the RO concept allows implementing the requirements of usage control more efficiently. This is illustrated by an example of a transaction between a buyer and a service provider, where: 1. The service provider promises to use a certain encryption mechanism by means of contract 2. The prospective buyer querys other system participants about whether the service provider usually uses this promised encryption mechanism 3. The other system participants who had interactions with this provider check the stored provider's reputation objects. Each sends a response by communicating the stored object which has more than a yes/no or a single rating response. It has information about the context (i.e. encryption) and information about the provider behaviour regarding this context. Hence using ROs as a tool reacting on changing behaviour. For example, a service provider who conforms to its promises, but then changes its policies and communicates the service outcomes without using this encryption mechanism.
The communication of participants regarding the corresponding context and the underlying changing of behaviour determines another decision within the Conditions Module of the proposed Usage Control Model. Compared to the simple SLA, reputation objects provide more detailed information that is necessary to decide if other participants are permitted to access own resources. The decision does not depend on promised criteria and attributes (SLA), instead it considers also measured attributes, even based on others' past experiences [49].
Another example, in an e-commerce scenario is a market place provider who does not fulfil the requirement of truthfulness regarding the users' data. Truthfulness means that the data owner is using the given data within the scope permitted by the data provider.
Having prominent examples in mind, the market place could sell users' data to external -doubtful -companies. In this case, the RO's corresponding criteria /context will fall to a minimum value as soon as the affairs are brought to light. The RO concept, therefore, provides more flexibility in reporting breaches and updating rating during the service run time. The concept of reputation can even ensure this reaction if someone

Model Benefits
Using reputation objects and taking advantage of the existing quality processes has the advantages of: • Interoperable format: The use of different ontology to describe both the reputation object and its elements facilitate the development of the model in several domains. It ensures the simplicity and reusability of the embedded information. The advances in ontology matching techniques ensure the matching between the contexts of a reputation object in one platform to be used in another platform.
• Context awareness: Reputation of an entity is not generalized anymore. Each value in the reputation object can be related to a certain context. Therefore giving the opportunity of • Easier storage and maintenance: Easier to maintain the answers to e-markets rating questions (After buy Questionnaire: Was the product in the described condition? Was it delivered on time? ) • Providing customized selection: Easier to select a seller according to what is most suitable to my requirements (i.e. I need faster delivery service and I don't care about the price) • Eliminating Legal hassles: Contract law can only provide so much protection for both service providers and consumer because the courts can be an expensive and unwieldy place to enforce requirements. Infractions would have to be widespread and egregious before most wronged parties would be willing to sue. Therefore, the use of a reputation object can aid in avoiding lawsuits; the less vague the rating, the less legal issues arise. Especially given the fact that laws and regulation vary by jurisdiction, which creates a challenge for online businesses and providers of online reputation systems operating internationally.
• Enabling Reputation information exchange: Though still not applicable yet, but the use of reputation objects will lead finally to reputation information exchange. The possibility of sharing reputation information increases if there are common quality attributes that can be matched and then transferred to other domains (rather than transferring a single value that has no meaning in the destination system). After creating a distributed federation system, it doesn't make sense to create a centralized system for building trust. Distributed reputation systems means sharing data.
In contrast to the e-commerce scenario [21] traditional electronic service environments are not capable to react on changing and dynamic environments. The service designer endows the service with access control rules, which are applied during runtime. The Condition Module of the Usage Control concept is just capable of fixed rules to decide on access and finally on the service behaviour. Changing these rules requires an additional iteration through the design, implementation and deployment phase of the service lifecycle.
With Reputation Objects the decisions within the Condition Module become more flexible. That is, in a dynamic service environment the service designer is not able to foresee all circumstances, he will be able to define kinds of meta-decision rules. The concrete definition of the necessary rules can be done during runtime by the service. For the service designer the concept of Reputation Objects means that less design iterations are necessary. Only changes in the high level rules require additional design and implementation iterations.

Conclusion and Future Work
This paper is based on a comparative case study on Electronic Commerce and the vision of an Internet of Services, where services can be traded in the Internet infrastructure. Considering the two use cases in an abstract view leads to the findings that both scenarios have to deal with the same problem; the trust problem. This problem is usually solved by the use of strong security mechanism (like in Internet of Services) or by using reputation techniques. These techniques however lack the proper structure to address usage control methods. We introduced our model in reputation objects followed by an example of how to apply the model on both use cases. Furthermore, we showed how we make use of quality process to achieve the goals of correct reputation modelling, reputation exchange, and enabling usage control. Later we identified the glue between e-commerce and IoS: Usage Control. Implementing Usage Control with the proposed Reputation Objects is, in our point of view, a suitable solution to integrate both domains. Currently we are working on an implementation for our framework following common standards in service description and service level agreements.