Fig-2: Major components of Organization Domain.
Fig-2: Major components of Organization Domain.
Fig-3: Major components of Organization Domain.
Our architecture, see Fig-2 starts with User interacting with the Runtime & Enforcement area. Since TAS3 architecture is user centric, all action starts directly or indirectly with the User. Even offline, user-not-present, processes are seen to have been authorized by the User at some earlier time.
In the Runtime area, the User will interact with Payload services to obtain the tangible business benefits that motivated him to use the services in the first place. However, for the Payload to work in secure and trustworthy manner, services from Infrastructure and Discovery areas are needed. For the system as a whole to remain secure and trusted, functions in the Audit and Monitor area are needed. They will receive their input through Audit Event Bus of the Runtime environment.
Front End Service. User's principal point of interaction with the system is a GUI, most commonly a Web GUI. This is a special kind of Service Provider that instead of speaking Web Services, e.g. SOAP, offers a user friendly interface. The Front End Services often call Web Services to perform all or parts of the functionality they provide. It is possible that the GUI is generated to match a Business Process Model.
Web Service. Machine accessible endpoint from which data or action services can be obtained. Machine-to-machine nature of Web Services is in contrast with the user-to-machine nature of the Front End Services.
The exact sequence of Web Services called will depend on a business process, whether expressly modelled or implicit to the design of the web services. A business process can encompass several Front Ends and the Web Services they call.
Business Process Engine is an orchestrating entity that controls how Front Ends and Service Providers, often Web Services, work together to achieve the objectives of the business process. It is depicted here as being a separate service, but "in process" realizations are equally likely. In such case the Business Process Engine would be inside the Front End Service, perhaps as linked in library. The role of the Business Process Engine is to serve payload business processes. There is a similar Trust Network Process Manager entity that, while technically similar, will exclusively execute business processes critical to the TN itself.
Dashboard is an important auditing and trust building feature of the TAS3 Architecture. It is a user interface, a Web GUI, that allows the User to understand and audit how the system as a whole uses his Personally Identifiable Information (PII). The Dashboard may also integrate a user interaction facility, PII Consent Service, for asking users consent or other input that is required for a business process to advance. All these features provide transparency. (Reqs. D1.2-2.11-Transp, D1.2-3.3-Dash, D1.2-6.3-WhatHowWhyWho, and D1.2-12.15-Valid)
(*** If you need a category for it, I would say it is "TAS3 User Tools" which includes Dashboard, Policy editor, Consent manager, Interaction Service, etc.
If you are re-engineering the picture, some aspects I explicitly do not like right now are that 1 Authorization is not given the emphasis it deserves. 2 Client side activites like verious forms of PEP and the web services stack are not shown.
Re ordering of infrstructure boxes, I want to see IdP, IDMapper, and Discovery Registry - it should be called that instead of "Registry Server" - in close proximity of each other.
The Credential and Privacy Negotiation and Trust Reputation should be in vicinity of Discovery Registry. Identity Aggregator should be close to Credential and Privacy Negotiator. Finally the Delegation should be close by to IDMapper.
User - User Agent Layer - Front Channel Communication - GUI Layer - Application Layer - TAS3 Security Layer - Web Services Stack Layer - Back Channel Communication Layer - Web Services Stack Layer - TAS3 Security Layer - Application Layer - Legacy Layer
)
Identity Provider is the point where Users actually authenticate to the system. After authentication, the IdP issues a Single Sign-On (SSO) token so that the Front End Service can complete the login process. IdP has also an important role in providing Id Mapper bootstrap token for the User.
Authorization. This box actually represents an entire subcontinent of functionality. Authorization is pervasive in TAS3 architecture. This topic is treated in more detail in Section 2.2.3.
Delegation provides mechanisms for one User to allow another User to use FE or WS services on his behalf. Delegation also includes mechanisms for introducing users to one another, such as invites. In some cases User can be replaced in delegation by a juridical person. In delegation both the delegator and delegatee may be authenticated indirectly. A situation similar to delegation arises when User instructs a service to act on his behalf. In this case the delegatee is a system entity, usually a Service Provider, and is authenticated directly. The act-on-behalf delegation is handled by the ID Mapper component. (Req. D1.2-7.1-Deleg)
Trust Reputation encompasses a number of components that deal with gathering reputation data, usually via Audit Event Bus, and computing trust scorings that are then used in Authorization and Trust and Privacy Negotiator components. The trust and reputation system is also used to detect certain classes of fraud (Req. D1.2-7.21-Safe).The architecture and design of this subsystem is further elaborated in WP5 deliverables.
Trust Network Process Manager. There are many maintenance processes that a trust network must realize in order to work dynamically and react to threats rapidly. These include intake process for users (Req. D1.2-6.1-IntakePers), intake and certification process for organizations (Req. D1.2-6.2-IntakeOrg), and user's access to his own data and audit trail (Req. D1.2-6.8-UserAccess). The application specific business processes belong to Business Process Engine, above.
Id Mapper is used to translate User's IM token (Id Mapper bootstrap token) to a token usable for Web Service that is about to be called. Such translation is necessary as the user is known by different pseudonym at different services. This is used to express act-on-behalf relationships where Service Provider (delegatee) wields a token provided by Id Mapper (or in some cases by IdP). (Req. D1.2-2.3-BMs)
Registry Server contains knowledge about which end point serves which type of service for any given User. Typically Registry is queried as a preparatory step of web service call proper, but it could be queried in advance. (Req. D1.2-2.3-BMs)
Linking Service provides a facility for a user to indicate how he wishes his attributes to be aggregated.
Obligations Service (not depicted) provides a way to process many commonly occurring obligations such as data retention limit. Obligation handlers register with the obligations service. The service uses this information to advertise its capabilities in satisfying obligations. This leads to trust and privacy negotiation.
Trust and Privacy Negotiator. This is the server side of the negotiation. Every Service Requester, such as Front End Service, must implement Trust and Privacy Negotiator Client Agent (not shown in the figure). The Client Agent can be implemented as a web service and the Service Requester merely performs a web service call to the agent, which then engages in trust and privacy negotiation protocol with the web service provider's Trustand Privacy Negotiator. Trust and Privacy Negotiator functions in many ways similar to the registry, but instead of returning all end points, only some are returned based on trust scoring.
Modelling and Configuration Management is connected to the TN level modelling. It also contains local ontologies, such as trust and privacy ontologies, and local Models and Configurations. All of these may be edited using Modelling Tools. From Models and Ontologies, configuration items can be generated and pushed to the Runtime using Management Event Bus, as governed by the Trust Network Process Manager.
An essential element of this architecture are community-managed ontologies (Model in Fig-2), which allows for unambiguous, but flexible, meaning agreement at all times. We can envisage several roles for these ontologies. It first provides a machine-understandable documentation of the architecture as well as a formal vehicle to exchange explicit semantic agreements (i.e. commitments) between partners and, eventually, systems. Thus, these commitments will enable the enforcement of (organisational and/or legal) policies within the TAS3 architecture. For example in Role-Based Access Control (RBAC), the role of a subject need to be provided with some semantics (e.g. a list of attributes) to be able to enforce authorization based on the privileges assigned to that role.
Secondly, the ontologies will assure that relevant parts of the system commit to the same interpretation of possibly ambiguous elements to allow for meaning alignment, certification and early conflict discovery. These ontologies will enable improved understanding; common methods of expressing terms enabling people and organisations to better trust each other in these application environments. TAS3 will integrate these architecture elements into a fully embedded trust framework to automate business processes managing personal information, which will result in considerable societal benefits. The Semantic Interoperability Engine (Fig-30) will facilitate the interoperability across different contexts (e.g. across different organizations). Ontologies are further discussed in [TAS3D22UPONTO].