Holistic Trust Design of E-Services
چکیده
As a central issue of modern e-services, trust has to be tackled early during the development phases. We present and compare in this chapter various works and methodologies that contribute to this aspect. A Holistic Trust Design Methodology that combines useful aspects encountered in the existing works is then described in detail. It is based on a systematic analysis of scenarios that describe the typical use of the e-service by using a Trust Analysis Grid. The Trust Analysis Grid is composed of eleven Trust Issue Categories that cover the various aspects of the concept of trust and is used to guide the design of the computing system by analyzing and refining the scenarios, and providing hints at the suitability of technologies for the scenario. We illustrate this methodology on several examples. INTRODUCTION Trust has recently been recognized as a crucial and central property of modern systems that provide e-services in a variety of contexts. Because failing to address this issue correctly may have a profound and costly impact on the e-service development, the issue of trust must be tackled early during the development, so as to identify and mitigate it as early as possible. This chapter covers methodologies that help to do so. Trust is a human notion that goes beyond technical aspects of the system. It is important that it is not confused with other concepts, e.g. security, so that users understand and thus have confidence into the system. This aspect is reinforced by the rapid growth of e-services developed in, for example, pervasive computing (Huandget al., 1999) or multi-agent systems (Hanssens et al., 2002). Trust defies traditional analysis in that it encompasses a wide range of other issues at a high level of abstraction, for example security, risk, social engineering or the law, in an ever-increasing complex arrangement. The recent literature on trust (see (Rindeback & Gustavsson, 2004), (Josang et al., 2005) or (Staab et al., 2004) for example) shows a number of ways with which trust can be dealt. But the literature lacks a holistic point of view that can help understand which techniques or technologies are best in various contexts and circumstances. The design phase of the system development is the most appropriate time for analysis of trust in the system. This is the approach used to tackle more traditional issues like risk (Storey, 1996) and security (Anderson, 2001), and it has proven successful in improving the quality of systems. It can be seen as a process whose output is a set of requirements that must be addressed in the subsequent phases of the development. Based on those two ideas of holistic design, trust is considered in this chapter as an evolving, contextual and composite belief that one principal (trustor) has that another principal (trustee) will perform certain actions with certain expected results, when not all information about those actions is available. The various elements of this definition will be detailed in the remainder of this chapter. The first section presents current works on methodologies to help design trustworthy e-services. Then we present a methodology that builds upon the current understanding of trust and improves on the existing trust design methodologies. It provides a holistic analysis framework to help design trustworthy e-services where the user is the focus of attention. This framework is applied to several realistic systems under development, including e-health and e-learning, in the next section. EXISTING METHODOLOGICAL WORK TACKLING THE TRUST ISSUE There is a huge corpus of work on the issue of trust, but few concentrate on this issue during the design of a system development and fewer propose methodologies to help the design process. We present here representative contributions to this topic and discuss their advantages and disadvantages as holistic trust design methodologies. Typologies of Trust There are many general works that analyze and decompose the notion of trust so as to provide general guidelines and understanding into this notion. Some of them suggest in particular the holistic nature of the concept of trust, by combining together the various aspects of trust presented in other works. Though these works provide a necessary and fundamental insight into the notion of trust that any holistic trust design methodology should provide, and in particular a basic decomposition into its more elemental properties, they are not sufficient by themselves for devising an e-service design methodology as they provide no concrete help to the e-service designer. TRUST-EC e-Commerce Requirements The TRUST-EC project (Jones & Morris, 1999) lists the common applications in eCommerce and analyzes how they consider trust, taken as a kind of reliance of system stakeholders that is more general than dependability. The list of non-functional requirements for trust for the e-Commerce business derived from this analysis is comprised of confidentiality, integrity, availability, identification, prevention, traceability, quality, risk management, and authentication. This work concludes on the possible necessity of “a requirements process for e-business, based on the framework, which will assist developers in structuring both the process of eliciting trust requirements (by providing a checklist of issues to be discussed with different stakeholders), and the way in which such requirements are documented” (Jones & Morris, 1999). McKnight and Chervany’s Conceptual Framework McKnight and Chervany (McKnight & Chervany, 1996) analyze research papers on trust, taken from a wide range of domains: management, sociology, economics, politics, science, psychology. They summarize the various views on trust in a conceptual framework based on six constructs, which themselves are decomposed into more elements. The basic concepts of the generic definition of trust of McKnight and Chervany are trusting intention, trusting behavior, trusting beliefs, system trust, dispositional trust, and situational decision. These general concepts are refined into notions like feelings of security, vulnerability, honesty, situational normality, beliefin-person, or trust stance. This work is probably the one that provides the best view on the holistic nature of trust, in that it gathers information from domains whose problems are quite orthogonal, and it shows the intrinsically diverse and interwoven structure of trust. On the other hand, it covers such a wide scope of trust issues that it is difficult to use it concretely. Jøsang, Ismail and Boyd’s Analysis of Trust-related Applications and Models Jøsang, Ismail and Boyd (Josang et al., 2005) give a more technical overview of the research on trust, in particular by focusing on modern reputation systems. They describe five trust classes (borrowed from Grandison and Sloman's classification (Grandison & Sloman, 2000)) that describe the various layers of the concept of trust, namely provision trust, access trust, delegation trust, identity trust, and context trust. These classes are defined in the context of a trust purpose, which enables to instantiate the classes in a given situation. The semantics of trust considered in a given application is then described against two dimensions, the levels of subjectivity and specificity. Many examples of modern systems using reputation are presented, for example eBay (EBay, 2006), or Slashdot (Slashdot, 2006). General Methodologies This section presents methodologies to help in various aspects of the design of systems and e-services where trust is central. The following methodologies are based on ad-hoc concepts and methods but will show the possible approaches currently taken to design trustworthy systems. Security Requirements Specification Method Tan, Titkov and Poslad (Tan et al., 2002) devise an abstract security model that they apply to the case of an e-Banking service implemented as a multi-multi-agent system. This model is based on the concepts of asset, safeguard to protect the asset, threat to the asset and profile to specify policies and relationships between the previous concepts. A graphical notation is used to illustrate the model, where security domains are shown as groupings of concepts and profiles. The various assets are then described more precisely in the case of the e-Banking scenario, where the various services needed are modeled as assets. That analysis enables to discuss the various service design issues in the e-Banking scenario. But first the methodology is aimed at Multi-Agent Systems, though it could still be used more generally at a conceptual level, and secondly, the analyzed issues are related to the more technical side of trust, namely security, and they require expert knowledge (authentication, security policies). The ideas underlying this approach are good, but not developed enough to make it a holistic trust design methodology. Matrix Model Tan's trust matrix model (Tan, 2003) is a means to analyze trust-building services between trading partners in e-commerce. It proposes to represent an e-service in the form of a grid. The grid rows correspond to properties of the service grouped into three layers. The grid columns correspond to a theoretical decomposition of the notion of trust into four reasons, namely social signs, personal experience, understanding, and communality. Each reason is divided into two sources, depending on whether they correspond to trust created by a party of the transaction or a control mechanism. The trust analysis in this framework is suited to the examination of a particular service offered by a system. It is also quite precise in that it considers a lot of trust issues, but those issues are specific to the kind of services examined in this work, namely Business-to-Business first trade situation. This approach is very rich in terms of the holistic view it provides into trust, but weak in terms of design features as it is not aimed at this task. Decompositional Model of Trust used in System Design Yan and Cofta (Yan & Cofta, 2003) define trust domains as areas of mobile communication where the definition of trust, which is a set of statements and goals, is common between the various elements. Gaps between these trust domains, implied by the subjectivity of the trust definitions, are bridged with particular components that are responsible for ensuring trust at a level above the one of the domains. The methodology is based on a graphical representation of entities, domains and their interconnections, enabling a view of the system at a higher level of abstraction. This methodology brings intuitiveness to system design and enables to treat the trust issue at a variable level of granularity, but it lacks accurateness to express more specific properties and localized problems, and it does not provide clear guidelines to help the system designer understand the various trust issues. It is in particular unclear what the application of the methodology would bring to examples other than the one presented. Holistic Analyses of Trust Relationships In the context of virtual communities, Ishaya and Mundy (Ishaya & Mundy, 2004) indicate that the potential barriers to trust development and management are fivefold: sociological, psychological, technological, legal, economic. They develop mechanisms to support the provision of trust, summarized by three tables that present relevant questions to ask about the elements of trust, the trust building process, and the security factors. Similarly, Grimsley and Meehan (Grimsley et al., 2004) consider trust from the perspective of internet-mediated community relations and decompose it into various dimensions, which are not necessarily orthogonal. The community trust compact and an experience management matrix described in this work are based on three dimensions, corresponding to the notions of information, control and influence. These two conceptual tools are represented by tables guiding the design of the project under consideration. These two works present a holistic view on trust mainly focused on the sociopsychological phenomenon and where the subjective aspects of trust are captured by many concepts and notions expressed in long questions. These textual approaches at design are not satisfactory as they add a layer of subjectivity and are prone to errors. Furthermore they are very difficult to apply to technical systems, as they mainly consider abstract properties of human systems. Framework to derive Trust Assumptions Haley et al. (Haley et al., 2004) apply principles of requirements engineering to security systems with the goal of deriving trust assumptions during the system-level analysis. A graphical notation is used to define domains. Interfaces, phenomena and constraints are described in context and problem frame diagrams. Constraints explored in this work are security requirements that help identify threats and vulnerabilities at the system-level. The constraints are completed by trust assumptions that help satisfy the security requirements and that specify the system designer’s point of view on trust. This approach provides powerful features for e-service design, but it considers trust in the technical sense, i.e. implicit assumptions in the security model that need to be made explicit. The subjective, and thus holistic, nature of trust is not represented. Though apparently intuitive, the graphical notation can rapidly lead to cluttered diagrams, which impede on an effective design. The i* Graphical Design Framework The i* framework (Yu & Cysneiros, 2002; Yu & Liu, 2001) is a framework proposed to model non-functional requirements (privacy and security) in multi-agent systems. A composite graph is used to represent the relationships between actors of a system. Relationships are of four types: goal, task, resource and softgoal (goal that have no qualitative measure of satisfaction and are attached to graph edges). Trust relationships are expressed as softgoals. The SD (Strategic Dependency) and SR (Strategic Rationale) models enable to view the system at various levels of abstraction. An i* graph looks like a scenario annotated with interrelated keywords. The i* framework is interesting as it focuses on a user-centered scenario describing the e-service under consideration in its context of daily use and uses intuitive graphical features to represent properties. But as illustrated in (Yu & Cysneiros, 2002) i* graphs can very quickly become unreadable, and thus unusable to the e-service designer. Methods with a Formal Background This section covers some methodologies that use formal methods to design and specify the electronic system. Computing science formal methods stem from mathematics and aim to help design, develop, analyze and validate software so that it is correct, error-free and robust. The formal dimension of these methodologies provides a basis for automated reasoning and tool support, thus greatly easing the work of the designer and opening the door for systematic analysis. TROPOS TROPOS (Giorgini et al., 2004, 2005) is a graphical methodology for modeling and representing the various system dependencies with the aim of analyzing trust requirements in security properties of electronic systems. TROPOS extends the i* framework (see above) by defining new concepts (actor, resource) and relationships (delegation, negative authorization) with the goal of focusing on trust. The diagrammatical notation is formalized into the logical language Datalog so that the specification can be checked automatically with software. A CASE tool has been devised to draw TROPOS diagrams and checking its correctness. TROPOS builds upon i* and extends it with more precise security notions. It removes the disadvantage of needing to manage the complexity of its graph thanks to the formalization. On the other hand, this approach requires some knowledge of formal verification that may not be available in the design project. CORAS The CORAS methodology (Braendeland & Stolen, 2004; Vraalsen et al., 2005) implements risk assessment techniques using an extension of the UML semi-formal method. The expressiveness of UML profile is extended conceptually by introducing normative modalities borrowed from deontic logics so that legal risks can be better specified. It covers the risk dimension of trust, but does not explicit any definition of trust. It requires and enables the system designer to use the definition most suited for his system. Various tools are available to use the methodology (Vraalsen et al., 2005) and a fully-formal view of CORAS is under development. The CORAS approach is close to software engineering as it uses the UML notation to model the system and it bases its analysis on a scenario. In these scenarios, a hierarchy of assets describes trust that must be protected from threats, vulnerabilities, and incidents. Evaluating in detail the risks associated with the system under examination enables to propose the solution to trust issues. The CORAS analysis methodology is partitioned into five sub-processes that are: establish the context; identify risks; analyze risks; evaluate risks; treat risks. This sequence is completed by a monitoring and review process that run in parallel and can restart the sequence of sub-processes. Conclusion A study of the existing works reveals that a decomposition of trust is central to any trust design methodology. General methodologies focus on a functional subset of properties, more well-known and less subjective, except for Holistic analyses of trust relationships (Grimsley et al., 2004; Ishaya & Mundy, 2004). But this limitation removes the holistic nature of trust, in that focusing on a sub property while eluding the others transforms the issue from trust to a different concept (e.g. security, risk). Most methodologies adopt an ad-hoc approach, without building on traditional design methodologies. This makes more difficult and costly the tackling of the trust issue in e-service design, and thus constitutes an impediment to the adoption of such methodologies in e-service development. While methodologies using a graphical representation bring intuitiveness to this task, it is quickly limited because of graph cluttering, though this can be improved as in TROPOS (Giorgini et al., 2004, 2005) and CORAS (Vraalsen et al., 2005; Vraalsen et al., 2005) via tool-support. This later methodology is based on traditional design methodologies (risk analysis, UML) but mainly focuses on risk. Haley et al. (Haley et al., 2004) is also based on existing requirements engineering methods. Textual notations are not limited by the graphical notation and can express complex notions in a human-understandable way, but it is only useful to the designer if guided as in the Matrix model as long descriptions are prone to misinterpretations and difficult to use. Furthermore, these notations can easily be incorporated into existing design methodologies, without the need to modify the design process. A HOLISTIC TRUST DESIGN PHASE As seen in the previous section, it is still quite difficult to find an existing methodology able help in designing e-services so as to make them globally trustworthy. It is particularly difficult in computing systems where the subjectivity induced by plain text English is in conflict with the operational nature of computing systems. This is made even more difficult in the context of emerging and changing technologies, where the level of abstraction is quite low and the focus is centered on the user. We describe a holistic methodology to analyze trust during the design of a system that focuses on the system user and provides insight into the subjective nature of the system. This methodology can be seen as a holistic trust design phase that is added at the start of the system development. Many of the subjective facets of trust are captured by this methodology, as well as objective concepts that are more directly applicable to real-world applications. The holistic trust design phase is composed of five steps that are structured as shown in Figure 1. Each step of the holistic trust design is described in the following sections. We then illustrate the methodology on several examples. Figure 1: The holistic trust design Step 1: The Scenario Because of the human-centric nature of trust and modern e-services, it is critically important that trust is explored from the user's perspective, rather than in terms of abstract concepts or security features, so as to appreciate the impact of particular trust issues on the users of the system. The holistic trust design phase reflects this imperative by working on scenarios. The scenarios form the foundations of the methodology and their development and analysis provide a valuable holistic view of trust that can guide the design of the electronic system. A scenario is a short, fictional narrative, set in the near future that describes people's daily lives, concentrating on their use of e-services under examination. The scenarios Trust Analysis Grid Step 3: Peer review Step 1: The scenario Step 2: Trust Analysis Step 5: Guiding the design Step 4: Scenario Refinement Scenario Step Data Next step Data modification Validation by expert are user-focused and usually avoid descriptions of how the technology works unless such descriptions clarify the users' interactions with the system. It is important that the scenarios reflect the way in which people would use the eservices to support them in their daily lives, in order to fit the technology to the task rather than the opposite. It is critical that the scenarios are validated by subject matter experts, so that they plausibly depict people and processes within the application domain. This validation should be done, if possible, by a person external to the trust analysis and the system design, so that her opinion is not biased towards the technical environment proposed. When writing scenarios, there is a trade-off between length and accuracy, but for the purpose of system development scenarios should focus on a specific set of features provided by the systems. The writing of scenarios is thus eased but this may limit the scope of the results, as a longer scenario can introduce interactions between elements that would be independent in smaller scenarios. Scenarios are living documents that will evolve during the process of trust analysis to meet the needs of the users and of the system designer. Their iterative development provides insight into the system and enables system designers to explore the various dimensions of their system. Step 2: The Trust Analysis The second step and foundation of the holistic trust design phase involves the Trust Analysis Grid. A sketch of a Trust Analysis Grid (TAG) is given in Table 1. The rows of the grid correspond to vignettes in the scenario. The columns of the grid correspond to categories of trust issues that will be checked against the vignettes. Trust Issue Categories Data System Subjective Vignette in the scenario So ur ce v s. In te rp re ta tio n