News Feed
Forgot your password?
New user?
WP2 Framework, Architecture and Semantics
TAS3_D2p1_arch-v17_2.pdf
TAS3 Architecture Accepted by European Commission in June 2009. Architecture Executive Summary: This document contains version 1 of the TAS3 system architecture (by system architecture we mean the conceptual design that defines the structure and behaviour of a TAS3 trust network). As the Description of Work states, the TAS3 project’s main objective is to provide a next generation trust & security architecture that is ready to (1) meet the requirements of complex and highly versatile business processes, (2) enable the dynamic user-centric management of policies and (3) ensure end-to-end secure transmission of personal information and user- controlled attributes between heterogeneous, context dependent and continuously changing systems. This architecture has been designed to fulfill the above objectives through a combination of: • providing users with the ability to meaningfully give their consent to the use of their personal information • ensuring a complete set of audit information is recorded by a TAS3 trust network and that users have the ability to directly or indirectly see the audit information that pertains to their personal information. Note that there will not be a single central audit log. If a person needs to drill down into the distributed audit trail, he will need to be authorised and obtain sufficient permissions to access the various local audit logs in order to correlate the events and see the "big picture". • a legal framework and set of model contracts that will contractually bind all service providers into operating in a trustworthy manner e.g. so as to honour the choices of users concerning the handling of their personal information • a set of trusted third parties that facilitate the sharing of trust related information such as public keys, authorization attributes, and reputation information • strong cryptographic algorithms and privacy preserving protocols • end to end security through application layer encryption and digital signing • sticky policies that cryptographically bind data and policies together, along with a policy enforcement infrastructure that controls access to all resources • quality assurance and testing technology and actors to test if on-line services actually behave in compliance with their specifications. This architecture document describes the conceptual entities that are needed and the services they should provide in order to operate a TAS3 trust network. These trust and privacy enhancing services include: authorization services, secure business process management services, delegation services, privacy preserving discovery services, identity management services, secure repository services and trust and reputation services. All of these services are usually needed regardless of the applications that might run in a TAS3 trust network. However, small centralized trust networks may be able to dispense with one or more of these trust and privacy enhancing services, e.g. discovery or delegation services, depending upon their requirements. This architecture contains many novel features such as: a trust infrastructure based on novel metrics, actor behaviour and structural components which can be correlated together, an authorisation infrastructure which supports multiple policy languages and conflict resolution, an obligation infrastructure which enforces privacy throughout the trust network, and a distributed audit system which can be cross correlated with the necessary permissions. These are described in more detail in the specific work package deliverables. The TAS3 architecture is designed to be standards, protocol, data and application agnostic so that any protocol capable of implementing the flows and satisfying the service requirements can potentially be used by any application. Annex A maps these services onto the latest state of the art application independent protocols as far as is currently possible. This is to ensure interworking between the prototypes that will be developed in this project. Further standardization effort will be needed in order to fully complete this mapping and this will be documented in a future version of this architecture (or in other TAS3 deliverables). Annex B shows an example deployment architecture that maximizes a service’s availability and is resilient to both system and network failures including denial of service attacks. Annex C states the compliance requirements for participants in a TAS3 trust network. Legal, policy and technical compliance requirements are covered. Annex D provides a set of use cases which allows the reader to see how an end user might use the services of a TAS3 trust network. Annex E contains the first version of a business model that could be used to successfully operate a TAS3 trust network Annex F summarizes the threats that the TAS3 architecture is designed to protect against Annex G lists the events that should be captured in the secure audit trails of a TAS3 trust network Annex H gives some example protocol messages based on the mapping provided in Annex A Annex I provides a glossary of terms Scope. The TAS3 project has a narrower scope than the architecture that is documented here. This is natural as the novel research contributions of TAS3 are being made only in some areas of the architecture. However the full architecture needs to be documented as this will be needed both to successfully test the research results and to provide a production service. We present a comprehensive architecture that addresses actual use cases end-to-end, rather than simply an architecture of the services that are within the scope of our research.
TAS3_D2p2_v1p8.pdf
Common Upper Ontologies Accepted by European Commission in June 2009. Executive Summary: The TAS3 project aims at developing a trusted Service-Oriented Architecture (SOA) enabling secure exchange of information across (human and non-human) agents. A SOA decomposes complex processes into manageable and reusable services to respond to changing business environments. Furthermore, it facilitates the collaboration between any numbers of organisations to provide combined services. As a result, all partners in the Trust Network (TN) need to agree upon a common understanding for the technical underpinning of the services as well as a common vocabulary for goods and data. One of the goals of the TAS3 project is to exploit Semantic Web technologies to address this problem. The Semantic Web extends the current World Wide Web (WWW) with resources in machine-readable form. On the one hand, each organisation needs to document their respective services in well documented standards (e.g. SOAP and WSDL). On the other hand, the resources (e.g. personal information) being exchanged need to be given adequate semantics to know which services have to be used. These types of resources are given meaning through the use of ontologies. This document describes the TAS3 ontology developed by STARLab. We first introduce a Descriptive Upper Ontology (UO) that could be applied to any domains. This upper ontology is different from existing ones as (i) it is grounded in natural language, and (ii) provides a descriptive framework to capture real world semantics. As a result, the upper ontology can be re-used in a non-restrictive manner. Furthermore, we extracted important concepts from IT standards (e.g. ISO/IEC 15008, 17799) to develop the Upper Common Ontology (UCO). A UCO contains the conceptualizations and semantic constraints that are common to and accepted by a domain. As such, we believe that standards provide a vocabulary of terms (agreed upon by domain experts) and that this can provide a starting point for the TAS3 conceptualisation. Annotating (web) services with security concepts would allow the correct semantic interpretation of security paradigms and data protection regulations (addressing privacy) and thus increase the trust in the TN. In this first iteration, we have mainly concentrated on security and data protection aspects.
TAS3_D2p3 Lower Common Ontology v1p1.pdf
TAS3 D2.3 Accepted by European Commission in March 2010. Executive Summary: The TAS3 (Trusted Architecture for Securely Shared Services) project aims to develop an open, secure and trusted architecture for the exchange of personal information across services. As this data is generated over a human lifestyle, it needs to be collected and stored at distributed locations and used by a multitude of services. In the employability domain, for instance, a person is continuously learning new competences not only based on her education history, but also based on her employment experience. His or her employability information will therefore be stored with different service providers who each use their own technical specifications when processing information. In such a distributed environment, all partners in a Trust Network (TN) need to agree upon a common understanding for the technical underpinning of the services as well as a common vocabulary for the data in order to support secure data exchange. Over the years, many languages have been developed to define security policies and privacy policies enabling secure access to personal information in distributed environment. For example, eXtensible Access Control Markup Language (XACML) is an access control policy language describing how to interpret authorization policies while exchanging data in service-oriented architecture. More specifically, XACML provides a XML-based syntax enabling a Policy Decision Point (PDP) to determine whether a request to access a resource should be granted, and to return an answer to a Policy Enforcement Point (PEP), which allows or denies access to the resource. However, policy interoperability can only be achieved if every system expresses their policies in the same language. Furthermore, these languages do not cover the content of a security policy. In this document, we present a security policy ontology based on the DOGMA (Developing Ontology-Grounded Methods and Applications) framework. In particular, we define conceptual models associated with authentication, credential validation, access control, obligation, privacy, delegation, and audit policies. More specifically, we represent security policies as a declarative model by defining a set of concepts and the relationships between them rather than describing the explicit sequence of steps required to apply them. Given this ontology, PDPs can interoperate with each other by interpreting policy attributes and their values from the Service Requester to those of the Service Provider through annotations. This removes the impractical restriction on all PEP/PDP in a TN to use an identical vocabulary to describe the conceptual model of their respective security domains. For instance, the credentials of an employee in System A together with their ontological annotation can easily be evaluated by the PEP in System B. As a result, the PDP in System B can call on ontology-based interpretation and translation services to understand whether the presented credentials and their values are those required by System B or are equivalent to the conditions in its policies. Note that the concepts defined in this document draw upon those defined in the Descriptive Upper Ontology and the TAS3 Common Upper Ontology in Deliverable D2.2.
TAS3_D2p4_Protocols API Concrete Arch_v10.pdf
TAS3 D2.4 Accepted by European Commission in March 2010. Protocols and Concrete Architecture Executive Summary: This document specifies a set of protocol level interoperability profiles, usually leveraging open standards, deployment scenarios, APIs, and other considerations that constitute the official way to deploy version 1 of TAS3 architecture, see [TAS3ARCH]. The purpose of defining these specifics is to enable multiple independent implementations of TAS3 to be wire protocol interoperable (and to limited extent also API interoperable). TAS3 reference implementation and reference deployment will behave essentially as described in this document. The TAS3 architecture is designed to be standards, protocol, data and application agnostic so that any protocol capable of implementing the flows and satisfying the service requirements can potentially be used by any application. However, to build practical systems, different components, possibly from different sources, must speak the same protocols, hence TAS3 provides this profile that allows interoperability at the level of Single Sign-On, Web Service Discovery, Web Service Call, and Authorization. The standardized profile provides the scaffolding where plurality of trust and privacy negotiation mechanisms, policy languages, obligations and other value added features can exist. The TAS3 API is designed to allow an application programmer to understand how simple it is to "TAS3 enable" his application. It is noteworthy that using the API does not require any in-depth knowledge of the underlying standards, protocols, and profiles, or indeed even of the TAS3 Architecture itself. All these details are taken care of by the API implementation, supplied commercially or in open source. The TAS3 Reference Implementation will be one such API implementation. The APIs will be available in all popular programming languages and platforms. The simplicity of the API is due to a coherent integration model that shows how the steps from SSO and Authorization all the way to the web service calls work together and are able to pass necessary credentials and tokens "behind the scenes" by the use of session and other state information. Many design parameters that could have been handled by yet another argument to the API functions, are in fact handled by configuration file, with sensible default values, and automated discovery, trust negotiation, and trust network business processes. The split between explicit arguments, configurability, and automated processes has been guided by division of concerns between the application programmer and the systems administrator. When automatic mechanisms are used, appropriate manual control point exists elsewhere in the architecture, e.g. automated discovery is kept in check with explicit authorization. We provide guidance regarding possible integration and deployment scenarios and illustrate how TAS3 Architecture can be deployed in a resilient and redundant way. Neither this document nor the TAS3 Architecture [TAS3ARCH] mandate use of a particular deployment or software architecture (although the integration scenarios suggest a recommended one), implementers are free to organize their software and deployment in other ways as long as the wire protocol compatibility is maintained and all signature generation and validation steps, as well as trust determinations, and authorizations are implemented. The Annex gives some example protocol messages.
