Theo Dimitrakos
email: t.dimitrakos@kent.ac.uk

How to Develop a Security Controls Oriented Reference Architecture for Cloud, IoT and SDN/NFV Platforms

Keywords: Security Controls, Reference Architecture, Security Risk, Systems Design

In this paper we present a security architecture style and approach named Security Controls Oriented Reference (SCORE) Architecture. The SCORE Architecture extends commonly used security architecture methodologies by placing particular emphasis on how security controls are specified, refined, implemented, traced and assessed throughout the security design and development life-cycle. It encompasses experience of over 30 years in secure systems design and development and it has been applied in practice for developing security capabilities for on top of advanced Cloud, NFV and IoT platforms.

Introduction

Modernization represents the changes that every organization must face as the generations of technology, skills and expectations are inevitably replaced by the next ones. Telecom Service Providers (TSP), Cloud Service Providers (CSP) and Enterprises alike prepare for the inevitable impact that Cloud Computing, Software Defined Networks (SDN) with Network Function Virtualization (NFV) and the Internet of Things (IoT) have on how to conduct business and compete. Cloud, SDN/NFV and IoT are delivery models for technology enabled services that drive greater agility, speed and cost savings. Although used in different scope, they all provide on-demand access via a network to an elastic pool of interconnected computing assets (e.g. devices, services, applications, frameworks, platforms, servers, storage, and networks) that can be rapidly provisioned and released with minimal service provider interaction and scaled as needed to enable pay per use. They enable faster delivery of services and on premise cost savings they to optimise the time from idea to solution. They also depend on complex supply networks and ecosystems with shared responsibility models for their delivery and operation. Enterprises will typically consume applications, compute services or devices offered and sometimes also operated by multiple providers. TSP and CSP will often deliver and operate platforms that are developed by many different vendors and whose operations and maintenance (O&M) often involves one or more third parties. In a platform provider, different product lines focus on but interdependent products and services that are later integrated into a Cloud, NFV or IoT platforms. Reference architectures and shared responsibility models are essential tools to govern and align such complex development, integration and O&M ecosystems.

An architectural style [START_REF] Taylor | Software architecture: Foundations, Theory and Practice[END_REF], [START_REF] Shaw | Software architecture: perspectives on an emerging discipline[END_REF] is a named collection of architectural design decisions that can be applied to a specific information system and operation context in order constrain and guide architectural design decisions in that context and elicit beneficial qualities in the resulting system. A reference architecture (RA) provides a method and template solution for developing an architecture for a particular domain. It also provides a common set of concepts which stress commonality. It is an architecture where the structures and respective elements and relations provide templates for concrete architectures in a particular domain or in a family of software systems.

A security reference architecture (SRA) for Cloud, NFV or IoT platforms is a RA that focuses on: a) the specification of common security capabilities that are fulfilled by security services and the design of blue-prints for such services; and b) the specification of security requirements that need to be fulfilled by the platform and the design of platform enhancements to fulfill these requirements (leveraging where appropriate the security services). It is not the design of a final solution but a baseline that enables aligning platform development and optimizing service delivery and business operation. SRAs for Cloud, NFV and IoT platforms and services are important for a variety of reasons including the following: -Provide a reference model for security architecture and security policy to those who have a project to produce or use NFV deployments on public or private cloud infrastructures or inter-cloud software-defined overlay network services that enable IoT.

-

Enable effective communication of technical solutions, security impact and development strategy to the senior management of a provider and their customers -Offer guidance for mission-specific product designs that work together.

-

Combine knowledge from TSP and CSP with experts from the Cloud, NfV and SDN security communities (e.g. in ETSI, IETF, CSA, ISF). -Capture relevant security standards and where appropriate align with them. In this paper we present a security architecture style and approach named Security Controls Oriented Reference (SCORE) Architecture, which extends commonly used security architecture methodologies by placing particular emphasis on how security controls are specified, refined, implemented, traced and assessed throughout the security design and development lifecycle.

The motivation for SCORE Architecture has been to build into the platform design and development processes the ability to: 1) explain in a structured how security and compliance requirements are satisfied by the system design and implementation; 2) continuously assess if security and compliance requirements are met to a satisfactory degree; 3) ensure the mechanisms satisfying these requirements offer a sufficient level of assurance; 4)ensure clear methods of collecting evidence about the ICT system's conformance to these requirements.

Basic concepts

The key concepts used in the SCORE Architecture approach are the summarized in Fig. 1 and detailed in the subsequent sections. .

Fig. 1:

Overview of the main concepts used in the SCORE Architecture approach.

Information Assurance, Risk, Continuous Monitoring and Validation

Information Assurance (IA) [3] [4] is about assuring information and managing risks related to the use, processing, storage and transmission of information and data and to the systems and processes used for this purposes. Security risk management [START_REF]Minimum Security Requirements for Federal Information and Information Systems (FIPS 200)[END_REF], [START_REF]Guide for Applying the Risk Management Framework (RMF) to Federal Information Systems: a Security Life Cycle Approach[END_REF], [START_REF]Risk Management Framework forInformation Systems and Organizations: A System Life Cycle Approach for Security and Privacy (DISCUSSION DRAFT)[END_REF] provides an overall framework guiding the selection of security controls in relation a security (impact/risk) classification. When combined with continuous monitoring [START_REF] Dempsey | Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations[END_REF], evidence-based validation of security control implementation, regular controls update and risk re-assessment, it enables risk-based decision-making and adaptation for security adaptation, and resilience through tailoring and enhancing of security controls and validating the correctness and effectiveness of their implementation.

Security Threats and Threat Assessment

We define security threat as any circumstance or event with the potential to adversely impact organizational operations of the carrier or enterprise (including mission, functions, image or reputation), organizational assets, individuals, other organizations, or the nations served by the carrier through the NFV platform via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Typically, a threat source realizes a threat by exploiting some vulnerability. A threat may also be enabled by a security challenge either by means of directly enabling some vulnerability or by means of enabling a threat source to exploit another vulnerability of the system that is not directly caused by the security challenge.

Adapting [START_REF]National Informaiton Assurance (IA) Glossary[END_REF], we define Threat Assessment as the formal description and evaluation of threat to the information system that contains the NFV platform.

NIST guidance documents [START_REF]Joint Task Force Transformation Initiative[END_REF] and [START_REF] Stoneburner | Risk Management Guide for Information Technology Systems[END_REF] also offer a similar definition of threat and threat source: a threat is seen as the potential for a threat source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability, where a threat source is either 1) the intent and method targeted at the intentional exploitation of a vulnerability or 2) a situation and method that may accidentally trigger a vulnerability.

Vulnerability and Vulnerability Assessment

Vulnerability is a weakness in an information system of the NFV platform, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. Vulnerability assessment (or vulnerability analysis) [START_REF]National Informaiton Assurance (IA) Glossary[END_REF] is the systematic examination of a (socio-technical) information system containing the NFV platform in order to determine the adequacy of security measures, to identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation.

Security Challenges

A "security challenge" is a technological, operational, policy or business shortcoming, unresolved technical issue, design, implementation choice or operational complexity that may possibly give rise to vulnerabilities or enable a threat actor to exploit vulnerabilities. Security challenge may often be the security side-effects of a desired and necessary functionality of the system. One can argue that the effects of security challenges may be split into threats and vulnerabilities and therefore reduce or remove the need for capturing and recording security challenges. However our experience with applying security architecture best practice is that threats and vulnerabilities resulting from security challenges have complex interdependences and characteristic causality which may result in implicit but distinct semantic differences compared to a similar vulnerability caused by external factors. Security challenges for systems conforming to the ETSI NFV Reference Architecture implemented on top of a Cloud (IaaS) NFVI are provided in [START_REF] Dimitrakos | Security Challenges and Guidance for Protecting NFV on Cloud IaaS[END_REF] and [START_REF] Dimitrakos | Towards a security reference architecture for Network Function Virtualisation: security challenges and security controls[END_REF]. These are consistent with, and more comprehensive than, previous security challenges and requirements elicited by ETSI [START_REF]Network Functions Virtualisation (NFV)[END_REF] and CSA [START_REF] Csa | Network Function Virtualization[END_REF], [START_REF] Csa | Best Practices for Mitigating Risks in Virtualized Environments[END_REF].

Security Requirements

A security requirement is a requirement levied on the information system and organization that contains or operates the NFV platform. It is derived from mission or business needs, regulation, legislation, directives, organizational policies, standards, threat analyses, risk management advisories, guidance and procedures in order to ensure the confidentiality/privacy, integrity, accountability and availability of information (including data and software) that is being processed, stored or transmitted.

Security Controls and Security Control Assessment

Security controls are the safeguards/countermeasures prescribed for information systems or organizations that are designed to: protect the confidentiality/privacy, integrity, accountability and availability of information that is processed, stored and transmitted by those systems/organizations; and to satisfy a set of defined security requirements [START_REF] Joint | Security and Privacy Controls for Federal Information Systems and Organizations[END_REF]. A security control resolves or mitigates the risk associated with some threat either by correcting an existing vulnerability or by preventing a security challenge enable vulnerabilities or by preventing vulnerability exploitation by a threat source. A security control must come together with metrics for assessing the level of assurance of its implementation.

A Security Control Baseline [START_REF]Minimum Security Requirements for Federal Information and Information Systems (FIPS 200)[END_REF] is the set of minimum security controls that provides a starting point for the "security controls tailoring" process [START_REF] Joint | Security and Privacy Controls for Federal Information Systems and Organizations[END_REF]: (i) identifying and designating common controls; (ii) applying scoping considerations on the applicability and implementation of baseline controls; (iii) selecting compensating security controls; (iv) assigning specific values to organization-defined security control parameters; (v) supplementing baselines with additional security controls or control enhancements; and (vi) providing additional specification information for control implementation. Security controls may also be enhanced as part of tailoring in order to: a) build in additional, but related, functionality to the control; b) increase the strength of the control; or c) add assurance to the control.

Security Control Inheritance [START_REF]National Informaiton Assurance (IA) Glossary[END_REF] means that an information system receives protection from security controls (or portions of security controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides.

Security Control Assessment is the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended and producing the desired outcome with respect to meeting the security requirements for an information system or organization [START_REF]National Informaiton Assurance (IA) Glossary[END_REF].

Architectural and Design Patterns

An architectural pattern is a rigorous description in a specific architectural style that solves and delineates some essential cohesive elements of a system architecture. The functionality described by an architectural pattern is sometimes referred to in the literature as a Common Capability [START_REF] Dimitrakos | Service Oriented Infrastructures and Cloud Service Platforms for the Enterprise. A selection of common capabilities validated in real-life business trials[END_REF].

A design pattern elaborates how to apply the architectural pattern into a specific information system or product implementation and how to collect the corresponding evidence to asses both conformance to the architectural pattern and the fulfillment of the corresponding security controls. Different system or solution architectures may implement the same patterns [START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF].

Architectural and design patterns should be used to elaborate how security controls are realized and enforced and what is the required evidence to fulfill the level of assurance of the control implementation. It should then also capture dependences between security controls, trace their relationship to security challenges and security requirements and evidence how a collection of security controls resolve or mitigate corresponding threats and vulnerabilities. Use-cases should be used as the preferred means of explaining by means of exemplar scenarios how threats and vulnerabilities are resolved or mitigated via the application of security controls as realized by the corresponding architectural patterns.

SCORE Architecture Process

A simplified overview of the architecture development process used in the SCORE Architecture approach is described in Fig. 2: In this section we elaborate each stage of this process.

Information Assurance: a Security Risk Management

Risk Management and Information Assurance are continuous governance processes that govern the assessment and impact analysis of threats, vulnerabilities and security challenges and the selection, adaptation and refinement ("tailoring") of security controls as well as risk associated with the sufficiency of the selected security control implementations. Security risk management and information assurance are enacted during and in between these sequentially linked steps and they may trigger iteration from any sequentially linked design and development stage to any preceding stage. The SCORE Architecture recommends that NCSS/NIST Risk Management Framework (RMF) [START_REF]Risk Management Framework (RMF) Overview[END_REF] enhanced with the guidance of ENISA publications "Cloud Computing Risk Assessment" [START_REF] Enisa | Cloud Computing Benefits, risks and recommendations for information security[END_REF] and "Cloud Computing Information Assurance" [START_REF] Enisa | Cloud Computing: Information Assurance Framework[END_REF]. The following Fig. 3 summarizes the risk management steps.

Architectural Conformance and Implementation Validation

Typically the implementation of security controls is validated by internal and third party security auditors and certification authorities. However, in order to improve security and privacy by design through continuous improvement and alignment between control definition and implementation, SCORE Architecture recommends that architectural conformance and implementation validation is enacted as a continuous process complementing risk management and information assurance. First the conformance of the design and implementation of a control to the specification of the control is ensured, then once implementation is approved the conformance of the implementation with the design and architecture patterns is assured in addition to the validation of the implementation. The SCORE Architecture requires that every control comes together with:

-Conformance guidance: qualitative information and metrics on how to assess conformance of the control architecture. Each architectural pattern contains criteria that must be met by the conformant design patterns.

-

Validation metrics and requirements: test-cases, metrics, validation criteria and qualitative guidance that help validate the correctness of the implementation of a control. This may be similar to what certification bodies and auditors would require when assessing the system. -Evidence collection requirements: a classification of the data that need to be collected for substantiating conformance and validation together with guidance on the preferred evidence collection methods.

Additional techniques that can help with achieving design conformance are mentioned in [START_REF] Enisa | Cloud Computing: Information Assurance Framework[END_REF] and some of them have been applied to a case study on CryptoDB [START_REF] Abi-Antoun | Analyzing security architectures[END_REF].

Architecture Design Process

In this section we describe the design and development process of SCORE Architecture. Although the design and development steps are presented in a sequence, the SCORE Architecture prescribes iterations of varying scope and frequency which are determined by the information assurance and risk management process in conjunction with the results of the architectural conformance and validation process.

Threats and Challenges

The starting point of the SCORE Architecture design process is the Security Challenges Analysis Phase. Analysis of threats and vulnerabilities on the basis of the organizational (e.g. carrier operations) and information system requirements (e.g. VNFs, NFV platform, cloud platform, datacenters), any anticipated compliance requirements and of the security challenges (e.g. [START_REF] Joint | Security and Privacy Controls for Federal Information Systems and Organizations[END_REF]) associated with the targeted platform architecture. This should be complemented by a (model-based) Security Risk Assessment based on [START_REF]Joint Task Force Transformation Initiative[END_REF] which may be enhanced with other security risk analysis methods such as OCTAVE [START_REF] Caralli | Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process[END_REF] or COBRA for assessing security risk related to human centric processes or FRAP [START_REF] Peltier | Information Security Risk Analysis[END_REF] and m CORAS [START_REF] Fredriksen | The CORAS Framework for a Model-Based Risk Management Process[END_REF] and [START_REF] Lund | Model-driven risk analysis -The CORAS Approach[END_REF] for assessing information system or product / platform risks. Risk and impact should be classified so as to enable a base line of control for each risk acceptance and impact level and also be traced by to the associated threats, vulnerabilities and organizational or compliance requirements.

Fig. 4: Indicative categorization for a catalog (repository) of relevant security controls

Security Controls

An important stage of the SCORE Architecture process is the elicitation and specification of the specific security controls for the system being architected. The security controls underpin the risk management process and provide a reference for the information assurance process. They also scope and steer the development of security architectural patterns and consequently design patterns and their imprint must be traceable and measurable (or assessable) in every step from information system design to the targeted application and platform implementations. The elicitation and specification of security controls typically includes the following steps: 1) Security control catalog selection; 2) Security categorization; 3) Security control base-line determination; 4) Security control tailoring.

Security control repository and catalog selection: Defining the security controls catalog form a repository of security controls. For Cloud, IoT and NFV platforms, SCORE Architecture recommends a base-line for the security controls repository (Fig. Security categorization: Determining the criticality and sensitivity of the information to be processed, stored, or transmitted by the target platform including the corresponding Operation and Maintenance (O&M) processes. FIPS Publication 199 [START_REF][END_REF] offers commonly referenced security categorization. SCORE Architecture the follow-ing formula in for describing impact, where the acceptable values for potential impact are low, moderate, or high. This formula extends [START_REF][END_REF] with additional security objectives relating to privacy and accountability in order to accommodate recent regulations in Europe relating to the implementation of GDPR [START_REF][END_REF] and NIS directive [START_REF]THE EUROPEAN PARLIAMENT AND THE COUNCIL OF THE EUROPEAN UNION[END_REF]:

Security_Category = {(confidentiality, impact), (privacy, impact), (integrity, impact), (accountability, impact), (availability, impact)}.

Following the security categorization, security controls are then selected as countermeasures to the potential adverse impact described in the results of the security classification. Fig. 5 summarizes the security control selection and tailoring process described in this section and the corresponding documentation extending [START_REF] Csa | Network Function Virtualization[END_REF] and [START_REF]Cloud Controls Matrix[END_REF].

Fig. 5: Summary of the security controls selection and documentation

Security controls baseline definition: determining the most cost-effective, appropriate set of security controls, which if implemented and determined to be effective, would mitigate security risk while complying with security requirements and security challenges defined in the previous phase. To assist organizations in making the appropriate selection of security controls, NIST defines the concept of baseline controls [START_REF] Joint | Security and Privacy Controls for Federal Information Systems and Organizations[END_REF].

Baseline controls are the starting point for the security control selection process. Furthermore [START_REF] Joint | Security and Privacy Controls for Federal Information Systems and Organizations[END_REF] in Appendix D defines three security control base-lines in accordance with FIPS Publication 199 and FIPS Publication 200.

The security controls must be carefully reviewed and revised periodically to reflect experience gained from using the controls, directives and regulations, changing security requirements and new or emerging threats, vulnerabilities, and attack methods as well as new security challenges resulting from the emergence of new technologies. Also security controls catalogs may be specialized for different regions to reflect differences in legislation.

Once the applicable security controls baseline has been selected, the controls in the baseline need to be tailored.

Security controls tailoring: to modify appropriately and align the controls more closely with the specific conditions of the targeted system and its intended context of operation. Security controls must not be removed at any stage from the baseline to serve operation convenience. The following tailoring activities must be approved by authorizing officials in coordination with selected organizational officials: • Identifying and designating common controls in initial security control baselines;

• Applying scoping considerations to the remaining baseline security controls;

• Selecting compensating security controls, if needed;

• Assigning specific values to organization-defined security control parameters via explicit assignment and selection statements; • Supplementing baselines with additional security controls and control enhancements, if neededsee [START_REF] Joint | Security and Privacy Controls for Federal Information Systems and Organizations[END_REF] and [START_REF]Cloud Controls Matrix[END_REF] for details and references to examples of recommended supplementary security controls; • Providing additional specification information for control implementation, if needed.

Every security control from a baseline must be accounted for either by the organizations consuming or operating the service or by the product or platform owner. Each of these actors must determine which controls are implemented solely by the actor, which correspond to shared responsibility and which are implemented by another of these actors.

Documenting security controls: it is necessary to document all relevant decisions take during the security control selection process. Such documentation provides a very important input in assessing the security of a system in relation to the potential mission or business impact. This documentation together with supporting evidence about the correctness and conformance of the security control implementations provides valuable information for information assurance, architectural improvements, change or revision and compliance assessment or accreditation. It also constitutes a reference document for NFV platform providers, VNF developers, Cloud IaaS providers, carriers and enterprises understanding how to implement shared or common controls and control overlays.

Architectural and Design Patterns Definition

This phase of SCORE Architecture starts by mapping security controls to the different layers and components of the target system. In this mapping, security controls provide the common technical requirements for the elicitation of common capabilities which are documented by means of architectural patterns. Detailed examples of how to elicit common technical requirements and identify common capabilities for cloud platforms are provided in [START_REF] Dimitrakos | Service Oriented Infrastructures and Cloud Service Platforms for the Enterprise. A selection of common capabilities validated in real-life business trials[END_REF]. An illustrative high level overview of such a mapping is provided in Fig. 6. Fig. 6: Mapping security controls into subsystems of the NFV/Cloud platform layers In addition to defining common (security) capabilities and their architectural or design patterns, conformance and traceability must be assured and maintained. SCORE Architecture provides templates for architectural and design patterns that ensure: 1) Specifying which security controls are satisfied by the pattern; 2) Explain how the requirements, description, intend and dependences are met by the pattern for each referenced security control; 3) Specifying criteria, metrics and preferred conformance validation methods for ensuring conformance of subsequent design patterns to the architectural pattern; 4) Specifying criteria, metrics and preferred methods for validating the implementation of the architectural or design pattern and for collecting evidence that is suitable to support such validation.

The dependences to other design patternsincluding those describing relevant information models as well the application of relevant policies and proceduresmust be specified explicitly. Typically design pattern dependences inherit and extend architectural pattern dependences. The implementation results in interdependent subsystem. It is therefore very important to ensure traceability of dependences and validate it as part of architectural conformance. Furthermore, technical use-cases (decomposing and refining the generic use-cases used for common capabilities and architectural patterns) should be used in order to describe the functionalities and usage scenarios of the corresponding design patterns. It is recommended that refinement of archi-tectural pattern to design pattern is aligned with and informed by the refinement of general use-case through to technical use-cases and its decomposition to several subuse cases.

Product Improvement

The SCORE Architecture also includes guidelines for product improvement that are consistent with system engineering methods such as IPD, ISC and Agile. These guidelines comprise: -Guidance on (product) features identification, specification, design, validation including (1) design specialization; (2) prioritization of technical requirements and templates to assist this prioritization ; (3) GAP analysis against the prioritized requirements and templates to assist this analysis ; (4) Change impact assessment and (5) change management; (6) Time-line definition -Guidance on defining an innovation roadmap and a product improvement timeline in order to guide future enhancements and identified shortcomings. SCORE provides templates to assist innovation roadmap creation and maintenance.

Conclusion

In this paper I presented a method for developing reference security architectures for distributed information systems such Cloud, IoT and NFV platforms. This approach reflects over 20 years of research and incorporates methodologies developed through analysis and experimentation in [START_REF] Csa | Best Practices for Mitigating Risks in Virtualized Environments[END_REF] (where 100 organizations conducted 25 experiments in Enterprise use of Cloud Computing) with model-based risk analysis (e.g. [START_REF] Fredriksen | The CORAS Framework for a Model-Based Risk Management Process[END_REF] and [START_REF] Lund | Model-driven risk analysis -The CORAS Approach[END_REF]) and guidance from NIST, ENISA, ETSI, ISO and CSA. In its current form, the SCORE Architecture approach has been used for developing reference architectures of innovative security capabilities for intrusion prevention and data protection in multi-provider clouds in the context of EIT Digital High Impact Initiative on Trusted Cloud in cooperation where BT, TIM and Huawei participated. It has also been validated in additional use-cases with KDDI Research and it is currently being used by security researchers in Huawei for developing security reference architectures for NFV and Hybrid Cloud platforms.

Fig. 2 :

 2 Fig. 2: Simplified overview of the process that underpins the SCORE Architecture

Fig. 3 :

 3 Fig. 3: Extending NIST RMF in accordance to the SCORE Architecture framework

4 )Fig. 4 :

 44 based on ISO/IEC 27017 extending ISO/IEC 27001 and 27002 complemented with CSA Cloud Controls Matrix including their reference to the scope of applicability of each control. summarizes an indicative collection and classification of relevant security controls based on CSAISO/IEC 27001 and 27017/27018


Mirko Tagliaferri

Alessandro Aldini

From Knowledge to Trust: a Logical Framework for Pre-Trust Computations

Keywords: Computational Trust, Trust Logic, Subjective Logic

Computational trust is the digital counterpart of the human notion of trust as applied in social systems. Its main purpose is to improve the reliability of interactions in online communities and of knowledge transfer in information management systems. Trust models are typically composed of two parts: a trust computing part and a trust manipulation part. The former serves the purpose of gathering relevant information and then use it to compute initial trust values; the latter takes the initial trust values as granted and manipulates them for specific purposes, like, e.g., aggregation and propagation of trust, which are at the base of a notion of reputation. While trust manipulation is widely studied, very little attention is paid to the trust computing part. In this paper, we propose a formal language with which we can reason about knowledge, trust and their interaction. Specifically, in this setting it is possible to put into direct dependence possessed knowledge with values estimating trust, distrust, and uncertainty, which can then be used to feed any trust manipulation component of computational trust models.

Introduction

Given the growing number of interactions in online communities and of information exchanges in information management systems, it's becoming increasingly important to have security mechanisms that can prevent fraudulent behaviors. However, implementing hard security mechanisms for every possible interaction, e.g. authentication methods or access controls, can be costly and a failure of such mechanisms might put the whole system in jeopardy. For this reason, it is necessary to include other soft security mechanisms in the design of those environments where transactions and exchanges take place [START_REF] Jøsang | A survey of Trust and Reputation Systems for Online Service Provision[END_REF][START_REF] Sabater-Mir | Review on Computational Trust and Reputation Models[END_REF]. Trust is one form of soft security that can be implemented into a system: trust is a social control mechanism that brings an undoubtedly positive impact on cooperative operations, both by increasing the chances of performing an interaction and by decreasing the chances of having malevolent behaviors during those interactions [START_REF] Arrow | Gifts and Exchanges[END_REF][START_REF] Rasmusson | Simulated Social Control for Secure Internet Commerce[END_REF]. Therefore, trust has both a proactive and a control effect over interactions. Computational trust is the digital counterpart of trust as applied in ordinary social communities and computational trust models are soft security mechanisms that implement the notion of trust in digital environments to increase the quan-tity and quality of interactions 1 . Computational trust models are typically composed of two parts: a trust computing part and a trust manipulation part. While trust manipulation is widely studied, very little attention is paid to the trust computing part. In this paper, we propose a formal language with which it is possible to reason about how knowledge 2 and trust interact. Specifically, in this setting it is possible to put into direct dependence possessed knowledge with values estimating trust, distrust, and uncertainty, which can then be used to feed the trust manipulation component of any computational trust models. The paper will proceed as follows: in section 2, we discuss the distinction between trust computation and trust manipulation by providing some examples of both components as implemented in computational trust models; in section 3, following on the discussion of section 2, we will show how one well-known model for trust manipulation, i.e. Audun Jøsang's Subjective Logic [START_REF] Jøsang | Subjective Logic[END_REF], struggles when dealing with the trust computing component; in section 4, we provide the syntax and semantics of what we will call trust logic. In this logic, we will show how we can talk about the notion of trust and we will then show how the semantical structure in which the logic is interpreted helps in compute trust values that can be fed into Subjective Logic's trust manipulation component; finally, in section 5, we conclude the paper with some general remarks.

Trust Computing and Trust Manipulation

A good formalization of the notion of trust must accomplish two goals. The first goal is that of explaining how trust is generated: while it is possible to take trust as a primitive and unexplained notion, it is often preferable to provide a reduction of the notion of trust to more basic concepts, aiding our comprehension of the phenomenon of trust in various contexts. The second goal is that of explaining the dynamics of trust, i.e. how trust evolves under different circumstances: this should help in determining how dynamics in an environment (e.g. a group of friends or a multinational company) influence trust. To each goal corresponds a different component of trust models. Specifically, it is possible to identify a trust computing and a trust manipulation component. The former serves the purpose of gathering relevant information, which is considered basic, and then use it to compute trust values; the latter takes trust values as granted and manipulates them for specific purposes using different operators.

Even though both components are important, authors often concentrate on one or the other: models that concentrate on the trust computing component rely on the fact that when an environment changes, it is possible to repeatedly compute new trust values, therefore no trust manipulation component is needed; models that concentrate on the trust manipulation component can rely on conceptions of trust that take the concept as a primitive or depend for their initial values on other models, therefore neglecting the trust computing component. To highlight the distinction between trust computing and trust manipulation, we will now provide three examples of trust models and show how each component behaves in those models. To those three models we will then add a fourth one, which will be used as a target for the reflections of the rest of the paper. Note that the models presented were selected for explanatory purposes (i.e. to make clearer the distinction between the two components). No important or specific facts are derived from the models and, therefore, no results of this paper depend on the choices made.

Marsh's Trust Model

In [START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF], Stephen Marsh presented the first example of a thorough and detailed analysis of the notion of trust in a computational setting. His system was designed for possible implementations in distributed artificial intelligence and multi-agent systems: the main purpose of his thesis was that of using a formal variant of common-sense trust to increase the quality of the evaluation an autonomous agent should perform to decide whether to collaborate or not with other agents. In this model, it is possible to identify three different forms of trust: 1) Basic trust; 2) General trust; 3) Situational trust.

Basic trust represents the general attitude of an agent, when all his experiences in life are considered; general trust is the overall trust a trustor has in a trustee; situational trust is the specific trust a trustor has in a trustee when a specific collaborative task should take place. Basic trust and general trust are taken as primitives, while situational trust is reduced to more basic concepts.

In Marsh's model, the trust computing component is arrived at through a conceptual analysis of the notion of trust, which either classify trust as a primitive notion or helps in identifying the basic elements that form specific versions of trust (i.e. situational trust). We will now briefly explain how situational trust is analyzed, since this form of trust is at the core of Marsh's model. Specifically, situational trust is computed starting from three basic parameters: 𝑈 𝑥 (𝛼), the amount of utility agent 𝑥 gains if situation 𝛼 occurs; 𝐼 𝑥 (𝛼), the importance of situation 𝛼 for agent 𝑥; 𝑇 𝑥 (𝑦) ̂, the general trusting disposition of agent 𝑥 towards agent 𝑦. To obtain the situational trust, those three components are multiplied together.

The trust computing component of Marsh's model is straightforward. Once some basic information is gathered and expressed with numerical values, those values are multiplied to obtain a specific trust value.

What is limited in Marsh's model is the trust manipulation component. This is because the model relies on repeated computations of the trust values, rather than a manipulation of already obtained values. We will show in later sections (section 3) that this is a very severe limiting factor in computational trust models, since it makes it hard to provide evaluations for trust in different scenarios, e.g. when trust is obtained through referrals from one agent to another.

Yu and Singh's Trust Model

In [START_REF] Yu | Detecting Deception in Reputation Management[END_REF], the authors present a formal framework in which to evaluate the reputation of agents based on witnesses. The model also provides tools to avoid deception in rating provision. Yu and Singh's model is based on Dempster-Shafer theory of evidence and favors the trust manipulation component over the trust computing one. The trust computing component is based on past interactions between agents, where an agent 𝑥 trusts another agent 𝑦 if the percentage of positive past experiences over the whole number of recent experiences is superior to a given threshold. The trust computing component of this model is extremely simple and is lacking a proper analysis of trust. Moreover, it relies on the fact that the amount of data on past interactions is big, otherwise the values computed might be misleading. This is troublesome, since in digital environments interactions between the same agents are scarce. However, the strength of the model is associated with its trust manipulation component. In this model, it is possible to aggregate together ratings from different agents. Given a trust net, which is a directed graph representing the referral chains produced by an agent 𝑥's query about the trustworthiness of another agent 𝑦, 𝑥 might obtain a value of the trustworthiness of 𝑦 by combining the various ratings given to 𝑦 by all close acquaintances of 𝑥 in the trust net. The operation is based on Dempster rule of combination and the result is that of combining as a weighted sum all the trust values of other agents into one for the trustor.

BDI + Repage

In [START_REF] Putnam | Making Democracy Work[END_REF], the authors present a sophisticated model for trust and reputation evaluation and propagation. This model has both a simple trust computing and a good trust manipulation component. First, in BDI Rapage, there is a clear distinction between a trust and a reputation evaluation, where the former (called image) is interpreted as the trustor's belief in the trustworthiness of the trustee, while the latter is interpreted as the trustor's meta-belief on the beliefs about the trustee of other agents. The trust computing part is based, like in [START_REF] Yu | Detecting Deception in Reputation Management[END_REF], on past experiences, which can be categorized under five different labels (Very Bad, Bad, Neutral, Good, Very Good). Past experiences influence the weight of each label, providing a specific numerical value for each. Those numerical values are then used to generate an image (what we call trust evaluation) of the trustee for the given trustor. This trust evaluation, coupled with the desires, the beliefs and the intentions of the trustor, leads to the decision of collaborating or not. As in [START_REF] Yu | Detecting Deception in Reputation Management[END_REF], the trust computing component suffers from the requirement of having many past interactions and the real strength of the model lies in its trust manipulation component. For such component, this model includes a full logical language that can help reasoning about trust and reputation. The logical framework is that of a hierarchical multi-sorted first-order language. In such language is easy to express formulas that describe, over and above simple properties of objects, the de-sires, beliefs, intentions and the trust evaluations of a given agent and then, using various logical connectives (e.g. conjunction and disjunction), it is possible to specify different conditions for the presence or absence of trust by the trustor.

Summing Up

We saw three computational trust models and their respective trust computing and trust manipulation components. It has been shown that none of the model can deal perfectly with both components. We will now present a fourth model, which will be the starting point for the reflection made in this paper. This model, i.e. Audun Jøsang's Subjective Logic [START_REF] Jøsang | Subjective Logic[END_REF], is extremely well-suited to manipulate trust values using different algebraic operators, but suffers from a poor trust computing component. We will show how the logical language we present in this paper, can be used to implement a good trust computing component in Subjective Logic.

Subjective Logic

We described in section 2 the two main components of computational trust models and provided some examples of the role those two components have in such models.

In this section, we will introduce a further computational trust model, i.e. Audun Jøsang's Subjective Logic. We will explain why we choose this model as the starting point of our work and why we believe the model requires some improvements.

In Subjective Logic trust is represented as the opinion of agent 𝑥 about a given proposition 𝑝. An opinion has three major components, and a fourth added component which completes the trust evaluation and helps in computing an expected value for trust. The three major components are, respectively, a belief component, a disbelief component and an uncertainty component3 , while the fourth added component is labelled as base rate and indicates the prior probability associated with the truth of a proposition when no initial relevant information is available. The belief, disbelief and uncertainty components are additive to one, leading to the fact that Subjective Logic is effectively an extension of traditional probability logics. The additivity principle of the three major components allow also for a nice visualization of opinions through a triangle, which we will call the opinion triangle (Fig. 1). It is possible to observe in the figure that an opinion 𝜔 𝑥 is identified through the three major components of belief, disbelief and uncertainty and, after the generic opinion is obtained, it is possible to compute the expected trust value 𝐸(𝜔 𝑖 ) using the base rate (indicated in the figure with the letter a): the base rate determines the slope of the projection of the opinion on the base of the triangle and allows to compute an expected value when no uncertainty is taken into account in the valuation of the opinion. Subjective Logic is a widely employed model to manipulate trust, but is rather illsuited when it comes to compute initial trust values to be used as inputs to the model. The reason is that the only source of information that Subjective Logic allows to compute trust values is reputation scores based on past interactions. Once it is noticed that different agents might evaluate interaction differently and that reputation scores in one context are not easily transferable to other context, the fact that Subjective Logic has no other means to compute initial trust values becomes a big drawback. This is also noted by Jøsang himself: "The major difficulty with applying subjective logic is to find a way to consistently determine opinions to be used as input parameters. People may find the opinion model unfamiliar, and different individuals may produce conflicting opinions when faced with the same evidence." [START_REF] Jøsang | A Metric for Trusted Systems[END_REF].

The aim of this paper is specifically to implement a trust computing component that can produce initial trust values which can then be plugged into Subjective Logic.

A Language for Trust

We will now introduce the syntax and semantics of a formal language that will allow us to reason about knowledge and trust and, furthermore, to provide a trust computing mechanism that can produce values to be fed into Subjective Logic's trust manipulation component. This, we believe, is an improvement to Subjective Logic. The leading idea of the framework comes from an insight given by Jøsang:

"…[T]rust ultimately is a personal and subjective phenomenon that is based on various factors or evidence, and that some of those carry more weight than others. Personal experience typically carries more weight than second hand trust referrals or reputation…" [START_REF] Jøsang | Trust and Reputation Systems[END_REF]. The idea is therefore that of using the expressive power of a formal language to describe the information possessed by an agent and then transform this knowledge into an opinion value about a given proposition with all the three major components of Subjective Logic made explicit.

Syntax

In our language ℒ, we start with two sets. The two initial sets are a finite set Ag of agents and a finite set At of atomic propositional constant. Given p  At, i  Ag and b a rational number in the interval [0, 1] (with 0 and 1 included), the grammar for our language is given by the following BNF:

 := p |  |  | Ki() | i()b
All other connectives and operators are defined in the standard way: i)

 := () ; ii)  :=  ; iii)  := ()() ; iv) Fi() := Ki() ; v) i()b := -i()-b ; vi) i()b := (i()b) ; vii) i()=b := (i()b)( i()b) .
Ki() should be intuitively read as "agent i knows that "; we will call such formulas knowledge formulas. i()b should be intuitively read as "agent i trusts formula  to degree at least b"; we will call such formulas trust formulas. The degree to which an agent can trust goes from 0, complete distrust, to 1, complete trust.

Semantics

The semantics we will provide in this paper is in truth theoretical form and depends on a structure that is a combination of traditional relational structures for modal logics with added components to interpret trust formulas [START_REF] Hughes | A New Introduction to Modal Logic[END_REF][START_REF] Kripke | Semantical Considerations on Modal Logic[END_REF]. We will interpret the above presented language in the following structure M = (S, Cntx, , Ri1, …, Rin, T), where S is a finite set of possible states of the system; Cntx is a finite set of contexts, i.e. scenarios in which to evaluate trust;  is a valuation function over the set At, assigning to each atomic proposition in At a set of possible worlds, i.e. : At →(S) ; Ri, one for each agent i  Ag, is an accessibility relation defined over S, i.e. Ri  SS ; finally, T = ((i, c), (i, c, )) is a trust relevance space which determines, for each formula of the language, which propositional constants are relevant and how relevant they are. T has two distinct components: a qualitative relevance component (i, c) and a quantitative relevance component (i, c, ).

The qualitative relevance component (i, c), one for each couple of elements i  Ag and c  Cntx, takes formulas of the language as arguments and returns as values subsets of At, i.e. (i, c): ℒ → (At); the quantitative relevance component (i, c, ), which is a family of functions, one for each formula of the language and defined over the same couple of i  Ag and c  Cntx of (i, c), assigns to each relevant atomic proposition p member of the subset of At selected by (i, c), a rational number in the range (0, 1], i.e. (i, c, ): (i, c)() → (0, 1] 4 . The weights assigned must be additive to 1. Since the set of agents and the set of contexts are finite, there is a finite number of trust relevance spaces.

A possible state s  S represent a way in which the system can be specified; two states differ from one another by what propositions hold in such states. For example, in one state it might hold that it is sunny in San Francisco, while in another state it might hold that it is raining in San Francisco and therefore it is not sunny. If no nonstandard conditions 5 are placed on the description of a system (i.e. proscriptions on propositions that can or can't hold together), there will be exactly 2 |At| states in S, where |At| is the cardinality of the set of propositional constants.

The valuation function  assigns to each proposition 𝑝 ∈ 𝐴𝑡 a set of states; a state is included in the set if, and only if, the proposition holds in the given state.

The accessibility relations Ri connect possible states according to the epistemic status of the agent to whom the accessibility relation is associated. Two states are therefore connected if they are epistemically indistinguishable for the agent (i.e. according to what the agent knows, he can't determine which of two states is the actual one). For example, if an agent only knows the weather of Rome, he can't determine which is the actual state between the state in which it is sunny in San Francisco and the one in which it is raining in San Francisco; therefore, the two states would be connected by an accessibility relation; for the current paper, we are assuming that the accessibility relations are equivalence relations, i.e. reflexive, symmetric and transitive relations.

Finally, the trust relevance space T provides both a qualitative and a quantitative evaluation of the information that will help in determining the exact trust value an agent places in a formula. The qualitative relevance function (i, c), specifies, for an evaluating agent (the trustor) and an evaluation scenario (the context), which information (under the form of propositional constants) is relevant to compute an actual trust value. The relevance weight assigning functions (i, c, ) provide a quantitative assessment of relevance of a given proposition to trust, assigning specific weights to all propositional constants that are selected by applying (i, c) to . The additivity condition on (i, c, ) is in place to guarantee that in the best-case scenario (the one in which all relevant propositional constants do hold in the state and the agent is aware of all of them) there is full trust on the part of the trustor and moreover, it is never possible, in the system, to exceed full trust.

Once the basic components of the model are given, it is possible to extend the functions  and (i, c, ) to consider other formulas over and above the ones on which those functions are defined. This is fundamental to provide proper satisfiability conditions for the language. We will proceed to give the extensions explicitly: we will label the extension of  with  ext and the extension of (i, c, ) with (i, c, ) ext . Intuitively, the function  ext assigns to each formula of the language the set of states in which the formula holds, i.e.  ext : ℒ → (S). Put another way,  ext returns, for each formula of the language, the states that are compatible with the truth of such formula. This means that if an agent knows a given formula (i.e. he/she thinks that the formula is true), he/she will consider possible only the states contained in the set identified by  ext . For now, it is only possible to extend  to negations, conjunctions and knowledge formulas, we will then extend it also to trust formulas. The function  ext is defined recursively as follows:

 ext (p) = (p) (1)
 ext () = S\ ext () (2)
Where S\ ext () is the set-theoretic complement of  ext () with respect to the whole set of possible states S.

 ext () =  ext ()   ext () (3)
 ext (Ki()) = { s  S | tS s.t. sRit, t   ext () } (4)
The valuation of knowledge formulas should be read intuitively as follows: to check if a given state s is a member of the valuation set of the Ki(), take all states t of the system that are accessible from the state s; if all those states t are members of the valuation set of the formula , then the state s is a member of the valuation set of the formula Ki(); repeat the process for every state of the system (since the set of states S is finite, the process will eventually end). Before extending  ext also to trust formulas, we are required to extend the family of functions (i, c, ). To obtain such an extension, we define another family of functions (i, c, ). The (i, c, ), one for each formula  of the language, are defined over the possible states of the system and associate with every state s  S a rational number in the interval [0, 1], i.e. (i, c, ): S → [0, 1]. The family (i, c, ) depends on a trust relevance space T and the members of such family sum up all the relevance weights of the propositional constants that hold in the state s taken as argument. This sum represents the upper bound of trust in  for each state. Intuitively, a function (i, c, ) indicates how much trust an agent has in the formula  in each state, if he/she is aware, in the state, of all the relevant information related to that  (i.e. he/she knows what relevant propositions are true in that state). Another way to put it is the following: if an agent knows exactly which is the current state, (i, c, ) indicates the amount of trust he/she has in . Thus, (i, c, ) is an ideal measurement of trust. The function is defined explicitly as follows:

(i, c, ) (s) =  (i, c, )(p), s.t s   ext (p) (5)
Note that since (i, c, ) is additive to 1, we are guaranteed that (i, c, ) itself never exceeds 1. We assume that if the state to which (i, c, ) is applied is not contained in any  ext (p), then (i, c, ) assigns to it the value 0:

If there is no  ext (p) s.t. s   ext (p), then (i, c, ) (s) = 0 ( 6
)
We can now define (i, c, ) ext for all formulas. Intuitively, the function (i, c, ) ext assigns a trust relevance weight to all formulas of the language, i.e. (i, c, ) ext : ℒ → [0, 1]. Note that (i, c, ) ext also depends on all the elements on which (i, c, ) depend. This allows for the possibility of taking  both as parameter and as argument of the func-tion. (i, c, ) ext takes the sum of the relevance weights of all worlds in which a formula holds, i.e. the members of the valuation of the formula, and then divides the result for the cardinality of the valuation of the formula. It is extremely important to understand the behavior of (i, c, ) ext , because this function is the one properly defining trust in our formal language. The explicit definition of (i, c, ) ext is the following:

(i, c, ) ext () = ( (i, c, )(s), s.t. s   ext ())/| ext ()| (7)
Two remarks must be made about ( 7): first, it should be noted that the (i, c, ) ext of a formula, again, never exceeds 1; furthermore, the reader should note that  ext () is yet to be defined for trust formulas and, therefore, the function (i, c, ) ext is undefined for this typology of formulas. The reason is that, in our language to obtain the valuation of a trust formula, we need to be able to apply the function (i, c, ) ext to knowledge formulas first. This should be expected, since the main intuition behind the language presented in the paper is that trust depends on the knowledge of agents.

To properly define (i, c, ) ext for all formulas, we must return first to the function  ext and see how this function can be fully extended to include in its domain trust formulas. To obtain the valuation  ext for trust formulas, we now present a complete procedure. This procedure indicates what are the step necessary to obtain the set of states in which a given trust formula hold and a by-product of the procedure will be that of understanding how to compute the value of a trust formula in each state.

The procedure has 6 steps: 1. We start with the trust formula i()b that we want to evaluate. We consider the trust relevance space T of the formula . Note that the set (i, c) of any formula will only contain propositional constants and, particularly, it will not contain any occurrence of trust formulas6 . 2. Given a state s  S, we take the formulas  s.t. s   ext (Ki()) and  does not contain occurrences of trust formulas (i.e. no subformula of the formula is a trust formula) 7 . 3. We take the conjunction of the formulas identified in step 2 and we manipulate it to transform it in the equivalent simplified Conjunctive Normal Form (CNF), i.e. a CNF on which redundant formulas are eliminated and the annihilation and absorption law have been applied 8 . 4. We compute the (i, c, ) ext of the formula obtained in step 3. This is a rational number in the range [0, 1]. Note that, given our conditions during the procedure, we are guaranteed that (i, c, ) ext is properly defined for such a formula, since there is no occurrence of trust formulas at this point. 5. We compare the value obtained in step 4 with the value 𝑏 that appears in the trust formula we are evaluating. If the value is more than or equal to b, we say that i()b holds in the state s  S and we therefore add it to the set  ext (i()b) 6. We return to step 2 and repeat the process for another state of the system.

Note that, since the set S of states is finite, the procedure will eventually end. When the procedure ends, the result is the valuation set of the formula i()b, i.e.  ext (i()b). Even if not strictly necessary for the evaluation of the formulas of our language, we also complete the extension of function (i, c, ) ext to all formulas by giving the valuation function of trust formulas.

We will now provide truth-theoretical conditions for the satisfiability of a formula. Given a model M, a state s  S, a context c  Cntx and a rational number b in the range [0, 1], the satisfiability conditions are defined as follows:

• (M, s, c) ⊨ p iff s   ext (p) ; • (M, s, c) ⊨  iff s   ext () ; • (M, s, c) ⊨  iff s   ext () ; • (M, s, c) ⊨ Ki() iff s   ext (Ki()) ; • (M, s, c) ⊨ i()b iff s   ext (i()b) .
Given the above satisfiability conditions, we define four concepts of validity. A formula is context-valid with respect to a structure if, and only if, it is satisfied by every state of the system, once a specific context is given. A formula is state-valid with respect to a structure if, and only if, it is satisfied in every context, once a specific state is given. A formula is model-valid if, and only if, it is both context-valid and state-valid. A formula is fully-valid if, and only if, it is model-valid for all possible models. This structure is sufficient to be able to reason about knowledge and trust.

The above presented language is sufficient to reason about knowledge and trust and their interrelationship. The language provides a good way to compute pre-trust values and therefore can be employed as a trust-computing component of a computational trust model. We will now show how it is possible to use this language to feed the trust manipulation component of Jøsang's Subjective Logic.

From Knowledge to Trust: Pre-Trust Computations

The aim of our pre-trust computation is to obtain the three distinct components of Subjective Logic's opinions. Such components are respectively, belief, disbelief and uncertainty. We will now show that obtaining those three components is straightforward in our system, once our semantical structure is given. We start by specifying the three opinion components: "agent i believes in proposition p" (symbolically 𝒷 𝑖 (𝑝)) means that agent i, the trustor, believes, to a given degree, in the truth of proposition p; "agent i disbelieves in proposition p" (symbolically 𝒹 𝑖 (𝑝)) means that agent i dis-believes, to a given degree, in the truth of proposition p; finally, "agent i is uncertain about proposition p" (symbolically 𝓊 𝑖 (𝑝)) means that agent i does not possess any relevant information on whether to trust or not the proposition p. In our case, it is possible to connect the amount of information with the cardinality of the set attributed by  ext to the simplified CNF of the known formulas. Specifically, the smaller the cardinality, the higher the amount of information possessed and viceversa.

The three components are obtained in the following way: 1. We start by considering the trust relevance space T corresponding to a given context and a given agent for the formula p. 2. Assuming the actual state is s  S, we take the formulas  s.t. s   ext (Ki()) and  does not contain occurrences of trust formulas. 3. We take the conjunction of the formulas identified in step 2 and we manipulate it to transform it in the equivalent simplified Conjunctive Normal Form (CNF). We label this formula with . 4. We compute  ext (). 5. For each state s   ext (), compute (i, c, p)(s). [START_REF] Halpern | Reasoning about Uncertainty[END_REF]. Identify the maximum and the minimum value among the results of step 6. 7. 𝒷 𝑖 (𝑝) is equal to the minimum value identified; 𝑑 𝑖 (𝑝) is equal to 1 minus the maximum value identified; 𝑢 𝑖 (𝑝) is equal to the difference between the maximum and the minimum values. The three components so defined form the basis of subjective logic's opinions and they can therefore be manipulated by Jøsang's model to obtain further trust values. We believe that augmenting subjective logic with the trust computing component that comes from the application of the interpretational structure of the language we proposed is an improvement of the original model presented by Jøsang.

Summing up

We will explain the intuitive idea behind the semantical structure we just presented and explain why we believe this structure is able to capture formally the traditional notion of trust. We will do so by describing how each component of the system contributes to the generation of trust values.

In our language, we take propositions as pieces of information. Each proposition tells us something about the system and, doing so, it helps us in determining the state of the system. The set S of possible states includes, initially, all the possible combinations of propositional constants: this is equivalent to a setting where there is complete ignorance, i.e. the system can be in every possible state. On top of this initial setting we start constructing ideal settings. To do so we first identify which information is relevant for trust in a formula in each context (i.e. evaluation scenario): this role is fulfilled by the structure T, which takes formulas of the language and returns the relevant information for such formulas. Obviously, this step is subjective in nature and this is the reason the X set depends both on agents and contexts. Each agent might consider different information as relevant in different contexts and therefore there is a different X set for each couple (i, c). However, determining what is relevant isn't sufficient. We are dealing with a formal version of trust and this makes it necessary that trust is somehow measurable. For this reason, we have the  function, that assigns measures to the relevant information, telling us how much each piece of information is relevant to the trust in a given proposition. Again, this measure is subjective in nature and therefore must depend both on agents and contexts. Once obtained the T structure, we can now compute trust values for ideal situations. This is the role of the  function. What a  function does is to take states and determine the trust value in the formula in such a state, if an agent can determine univocally that that state is the only possible one. To this extent, the value of the  function and that of the  ext function is the same, if the formula to which  ext is applied univocally identifies the state to which  is applied. As we said, though, this is an ideal situation and often, in the real world, agents do not possess enough information to univocally determine a state over the others. For this reason, we introduce the function  ext , which tells us how much trust must be placed into a given formula, when that formula identifies a subset of S. This is the reason  ext depends on the function  ext (i.e. the function that identifies the states compatible with the information carried by a given formula). One possible critique is that we take the average of the ideal trust values of the remaining possible states and this is not justified, since we might want to take the minimum or the maximum value among the ones available. To justify our choices, we rely on the principle of sufficient reason. For the principle of sufficient reason, if an agent has no sufficient reasons for preferring a state to another, he should attribute to each state the same probability. Since we are assuming that agents can't determine which is the actual state among all the ones compatible with his/her information (if he/she could determine the actual state, we would again return to the reflections on ideal settings), he/she has no way of preferring one trust value over the others. Note that this might lead, in some scenarios, to trust a formula in a situation where there shouldn't be trust and distrusting a formula in a situation where there should be trust. We believe that this is not fully problematic, since the traditional concept of trust is open to the same issues and therefore it might be that the problem is inherently connected with trust and not specifically with our formalism. Nonetheless, it is possible to change the computation of  ext to consider optimistic and pessimistic attitudes in the part of the agent. Note, however, that this would only avoid one part of the problem of misplaced trust by enhancing the other part (e.g. an optimistic approach would avoid the possibility of not trusting when trust should be warranted, at the expense of having many more scenarios in which the agent trusts when trust shouldn't be warranted). For those reasons, at least at the theoretical level of this work, we prefer using the average. This exhaust the intuitive description of our formal language. We will now include a concrete example, to show a practical application of our language to a real scenario.

Example

In this section we build a concrete example and show how our formal language (especially the semantical structure) helps in analyzing the example. Assume we have 2 agents (Anne and Bob) and 2 contexts (Fixing_the_car and Preparing_dinner). Imagine we have a third agent, Charlie, Anne's father and a car relevant fact is that Charlie is meticulous. Since she knows in s7 that Charlie is meticulous, she has full trust in the fact that Charlie will help.

Let's now check (M, s7, P) ⊨ A ()0.5. Given that the knowledge Anne has in state s7 is not affected by the context, part of the procedure is like the previous one, we therefore must compute:

• (A, P, ) ext (p1 p4)=( (A, P, )(s), s.t. s   ext (p1 p4))/| ext (p1 p4)| The (A, P, )(s) are: (A, P, )(s1)=(A, P, )(s3)=1 and (A, P, )(s5)=(A, P, )(s7)=0. [START_REF] Fagin | Reasoning about Knowledge and Probabilities[END_REF]. This means that (A, P, ) ext (p1 p4)=2.8/4=0.7. Therefore (M, s7, P) ⊨ A ()0.5 holds. This result should be expected, because for Anne to trust that Charlie will help in the context of preparing the dinner the relevant facts are that Charlie tool cooking classes and that he is meticulous. Since Anne knows that Charlie is meticulous, her trust increases slightly above the indifference threshold. We now check both (M, s2, F) ⊨ B ()0.8 and (M, s8, F) ⊨ B ()0.8.

Note that in our structure, Bob knows whether p3 holds each state (i.e. if it holds he knows it and if it doesn't hold he knows the negation of it). Again, we will only compute the values, without giving discursive explanations. The reader can check autonomously that the computations are correct. Since p3 holds in s2 Bob knows it. We will therefore compute (B, F, ) ext (p3)=( (B, F, )(s), s.t. s   ext (p3))/| ext (p3)|=0.7. Therefore (M, s2, F) ⊨ B ()0.8 does not hold. Finally, in s2, p3 does not hold and therefore Bob knows p3. We then must compute (B, F, ) ext (p3)=( (B, F, )(s), s.t. s   ext (p3))/| ext (p3)|=0.3. Therefore, (M, s8, F) ⊨ B ()0.8 does not hold.

When evaluating the 𝜔 𝐴 (𝜑) opinion in the context fixing_the_car and assuming the actual state is s7, we first determine , which is p1 p4. We then compute  ext (p1 p4), which is {s1, s3, s5, s7}. The next step is that of computing the various (A, F, )(s), i.e. (A, F, )(s1)=(A, F, )(s3)=(A, F, )(s5)=(A, F, )(s7)=1. We can finally determine the various components of the opinion 𝜔 𝐴 (𝜑): 𝒷 𝐴 (𝜑) is equal to 1, i.e. the minimum among the values of the (A, F, )(s); 𝑑 𝐴 (𝜑) is equal to 0, i.e. 1 minus the maximum among the values of the (A, F, )(s); 𝑢 𝐴 (𝜑) is equal to 0, i.e. the maximum minus the minimum. We now give the result for the other three examples we examined, without providing the computations. For the opinion 𝜔 𝐴 (𝜑) in the context preparing_dinner and assuming the actual state is s7: 𝒷 𝐴 (𝜑) is equal to 0.4; 𝑑 𝐴 (𝜑) is equal to 0; 𝑢 𝐴 (𝜑) is equal to 0.6. For the opinion 𝜔 𝐵 (𝜑) in the context fixing_the_car and assuming the actual state is s2: 𝒷 𝐵 (𝜑) is equal to 0.4; 𝑑 𝐵 (𝜑) is equal to 0; 𝑢 𝐵 (𝜑) is equal to 0.6. For the opinion 𝜔 𝐵 (𝜑) in the context fixing_the_car and assuming the actual state is s8: 𝒷 𝐵 (𝜑) is equal to 0; 𝑑 𝐵 (𝜑) is equal to 0.4; 𝑢 𝐵 (𝜑) is equal to 0.6. This last computation exhausts our example.

Conclusion and Future Work

In this paper, we first discussed the distinction between the trust computing component and the trust manipulation component of computational trust models. We then showed that classical computational models are often focused only on one of the two components. Specifically, we showed that Audun Jøsang's Subjective Logic, one of the best-suited models for trust manipulation, is lacking a proper trust computing mechanism. To overcome this downside of Subjective Logic, we proposed a logical language that can be employed to reason about knowledge and trust. Moreover, we showed how to move from our logical language to Subjective Logic. This, we believe, is an improvement for Subjective Logic and, generally, for the understanding of computational trust. In the future, the aim is to provide an actual implementation of the language and the ideas contained in this paper. Moreover, we believe it is possible to provide dynamic version of the language, which can take into consideration flow of information and time-related concerns. A final and interesting research direction is that of comparing the language proposed with others formal structures employed to represent uncertainty.

Fig. 1

 1 Fig. 1 Opinion triangle where all components used to compute trust are represented.

See[2, 3, 5, 14, 15, 16,

[START_REF] Tagliaferri | A Taxonomy of Computational Models for Trust Computing in Decision-Making Procedures[END_REF] for surveys on computational trust models.[START_REF] Artz | A Survey of Trust in Computer Science and the Semantic Web[END_REF] It is important to note that, even though we employ the word 'knowledge', we do not commit to any specific epistemological notion of knowledge. In fact, our term might refer to very different conceptions of knowledge and, in some cases, also to beliefs. Although important from a philosophical point of view, this fact does not influence the formal framework we are presenting in the paper.

Uncertainty plays a crucial role in the formalization of trust. There are many ways this concept has been described formally (see e.g.[START_REF] Halpern | Reasoning about Uncertainty[END_REF] for a survey). Dealing with trust in a formal way can thus help also understand how uncertainty can be modelled, providing useful insight also for fields other than computer science, e.g. economics.

It is important to stress that (i, c, ) is not a single function, but a family of functions. Therefore, each member of (i, c, ) assigns a value to the relevant atomic propositions according to the specific formula on which the function depends.

With standard conditions we refer to conditions such as the principle of non-contradiction, for which a proposition and its negation can't both hold in the same state. An example of a nonstandard condition is the fact that one proposition always implies a second one, therefore proscribing states in which the former holds while the latter doesn't.

This is an extremely important point, since it avoids infinite regresses in the procedure and, consequently, in the evaluation process of trust formulas. If we allow arbitrary formulas in the qualitative relevance set, then an infinite regress might happen, for example, if the trust formula we are evaluating (i()b) appears in the qualitative relevance set of the formula for which we are trying to determine trust (). In such case, when we apply the recursive procedure and try to determine the valuation of i()b, the same formula will appear again in the qualitative relevance set of , ab infinitum.

This condition is similar in spirit to the one we impose on the qualitative relevance set. See note 3 for further explanations.

Note that in our language a tautology is the neutral element for conjunction and the destructive element for disjunction, while a contradiction is the neutral element for disjunction and the destructive element for conjunction.

mechanic. What we are trying to evaluate in this example is the trust Anne and Bob place in the proposition "Charlie will help me". We will call the agents A and B, the contexts with F and P and the proposition "Charlie will help me" with . Imagine the world is completely described by 4 propositional constants: p1: Charlie has a master degree in engineering; p2: Charlie has taken cooking classes; p3: Charlie offers a guarantee when he repairs a car; p4: Charlie is a meticulous person.

Given the fours propositional constants, we have 16 possible states of the world, representing all the possible combinations of the four propositions. We will label the states with the letter s, with subscripts. The initial valuation  of the propositional constants is the following: (p1)={s1, s2, s3, s4, s5, s6, s7, s8}; (p2)={s1, s2, s3, s4, s9, s10, s11, s12}; (p3)={s1, s2, s5, s6, s9, s10, s13, s14}; (p4)={s1, s3, s5, s7, s9, s11, s13, s15}.

The R for each agent are the following: RA={(s1, s3), (s3, s5), (s5, s7), (s2, s4), (s4, s6), (s6, s8), (s9, s11), (s11, s13), (s13, s15), (s15, s17), (s10, s12), (s12, s14), (s14, s16)}; RB={(s1, s2), (s2, s5), (s5, s6), (s6, s9), (s9, s10), (s10, s13), (s13, s14), (s3, s4), (s4, s7), (s7, s8), (s8, s11), (s11, s12), (s12, s15), (s15, s16)} 9 .

We will now specify the trust relevance space for the three couples (A, F), (B, F) and (A, P) and the proposition . We start with the X sets: X(A, F)()={p4}; X(B, F)()={p1, p3, p4}; X(A, P)()={p2, p4}.

We now apply :

We now have all the elements to assess how much trust an agent has in the proposition  in each possible scenario. Let's imagine we want to evaluate the two formulas A()0.5 and B()0.8. We will evaluate the first formula for two contexts in the same state, i.e. the contexts Fixing_the_car and Preparing_dinner in the state s7. We will evaluate the second formula for the same context in two different states, i.e. the context Fixing_the_car in the states s2 and s8.

Let's try to determine first whether (M, s7, F) ⊨ A ()0.5. Given the structure we presented above, it is possible to derive that in every state Anne knows whether or not her father has a master degree in engineering and whether or not he is meticulous. Therefore, she knows those facts also in s7, meaning that s7 is contained both in the set  ext (KA(p1)) and  ext (KA(p4)) 10 . We therefore identified the two propositions p1 and p4. The simplified CNF of the conjunction of those two propositions is just their conjunction p1 p4. We now compute the (A, F, ) ext function of this proposition:

This means that (A, F, ) ext (p1 p4)=4/4=1. Therefore, (M, s7, F) ⊨ A ()0.5 holds. This should be expected, because for Anne to trust that Charlie will help in the context of fixing the car the only 9 For this example, we are assuming that the R relations are equivalence relations; however, we omit the couples generated by the reflexive, symmetric and transitive closure of the relations specified in the example. The reader should consider them present. 10 Strictly speaking she also knows the conjunction of the two facts, but we won't consider it, since the conjunction of the two propositions corresponding to our fact would be eliminated during the simplification of the CNF.