This documentation provides information and insights into the different components of the TNO Security Gateway (TSG).
The TSG components allows you to participate in an IDS dataspace to exchange information with other organizations with data sovereignty in mind. You will be able to participate with the provided components as-is, but your allowed to modify the components to create your own dataspace with specific use-cases in mind. The source code is open-source with the Apache 2.0 license, and is available in the TNO TSG Gitlab group.
Trust: Trust is the basis of the International Data Spaces, by means of evaluation and certification before getting granted access to the dataspace.
Security & Data Sovereignty: Secure data exchanging with the certainty of remaining in control of your data, by means of security protocols and policy enforcement.
Ecosystem of Data: Decentralization is a key aspect of International Data Spaces, with the principle of keeping the data as close to the source as possible and only sharing it when explicitly allowed.
Standardized Interoperability: Standardized communication patterns between IDS Connectors allow the creation of different connector implementations, of which the TSG is one.
Value Adding Apps: The ability to create a modular ecosystem in which value adding applications can be added on-demand to IDS connectors.
Data Markets: Data-driven services combined with the pilars above allow for new business models to thrive.
But next to these pilars, the TSG components have a unique set of features:
Kubernetes support: All of the TSG components are created with support for Kubernetes in mind, that make the deployments of components robust and allow for production-ready deployments.
Abstractions of IDS specifics: By means of specific Data Apps developed to enable the inclusion of existing systems.
Embedded Policy Enforcement: The TSG Core Container contains an embedded Policy Enforcement Framework that supports a variety of IDS Usage Policies.
Easy Configuration: The TSG components can be deployed in a wide variety of use cases, configuration of the components receives special care to prevent overwhelming configuration and allow the flexibility of the configuration.
This documentation is aimed to support readers that want to get more information about IDS and TSG. Ranging from deploying existing component to information on how to create new functionality.
The Communication page is the starting point to get more information on how information can be shared with the TSG components.
The Deployment page is the starting point if you want to deploy TSG and participate in a dataspace.
The Core Container page is the starting point for more information on the core component of the TSG, to get in-depth information on how to interact with the internal API and how to configure the Core Container.
The Data Apps page is the starting point for more information on the Data Apps and see which Data Apps are available and how you can create your own Data App to add functionality that is not provided by one of the existing Data Apps.
Deployments of the TSG components occurs within an IDS-based dataspace. The figure below shows the required and optional components in a full operational dataspace, where there are generic dataspace enabling services (Identity Provider, Metadata Broker, Clearing House, Vocabulary Hub, App Store)
In the following paragraphs a short summary of each component is provided.
Connector / TNO Security Gateway
The connector is the primary point of communication within the dataspace, all communication with other parties is executed or managed by the connector. The TSG Core Container is an implementation the core services of a connector, accompanied with additional services (data apps) is the connector. The IDS information model is the primary ontology that is used for supplementing requests and responses with metadata on the message so that its receiver is able to deduce the context and purpose of the message. The connector is responsible for making sure usage policies are enforced, either by using an internal policy enforcement framework (PEF) or by using an external services that handles the policies. For all messages the connector exchanges a Dynamic Attribute Token (DAT) must be included in that proves certain attributes for the connector are valid and are claimed by the Dynamic Attribute Provisioning Service (DAPS). Examples of these attributes are the certification level, attested capabilities, the transport certificate fingerprint of the connector.
Currently, there isn’t a standardized Data App structure yet in the IDS specifications. Therefore, within the TSG the choice is made to implement a proprietary data app structure. These data apps are designed to handle IDS messaged with the accompanying metadata directly, this way no specific logic is needed in the core container to connect a new data app to the core container. As long as the data app is able to handle IDS messages the core container can include the data app, where the core container is responsible for verifying the DAT and policies for the request and the data app itself will handle the business logic related to the message. The core container, however, is capable of handling artifacts without the need of a data app. This makes the core container on its own compatible with other connector implementations (such as the Dataspace Connector).
The Identity Provider is an essential enabling service for a dataspace as it provides identities as well as the Dynamic Attribute Tokens for continiously verifying the claims attached to the identities. The Identity Provider is a combination of a Certificate Authority (CA) and a Dynamic Attribute Provisioning Service (DAPS). The Certificate Authority is based on a X.509 scheme with one or multiple CA certificates that sign public keys of components, participants, or devices. The certificates signed by the CA are usually only used for signing, seperate certificates are used for transport (e.g. for encrypting TLS tunnels and HTTPS connections) to allow certificates that are more easily accepted by other applications (e.g. by using LetsEncrypt certificates). The different certificates must be linked to ensure the used transport certificates really belongs to the identity that it claims to be. This is done via the DAPS, that provides short-lived tokens in order to create a more dynamic identity scheme by including information that can change within the usual validity of the X.509 certificate (2 year). The connector uses its certificate to send an client assertion to the DAPS, which in turn will create the DAT based on the identity that signed the client assertion. Therefore, the DAT is the primary piece of data that provides the value and trust to the remote party that validates the incoming request.
The TSG implementation of the Identity Provider combines the CA and DAPS functionality in one software solution, that makes it easy to request certificates by means of Certificate Signing Requests (CSRs) that are included linked in the DAPS to provide the necessary information needed for creating the DATs. This implementation will be made open source soon.
The Metadata Broker is an optional enabling service for a dataspace, although it is used in most dataspaces. Since the Metadata Broker provides the yellow pages of a dataspace, by providing the metadata of connected connectors to provide discoverability within the dataspace. Connectors in the dataspace are responsible for making sure the information in the metadata broker is up to date by informing the metadata broker of updates. This also means that connectors can decide what information they share with the publically visible (at least visible for other connectors in the dataspace) Broker. The information stored in the metadata broker can be retrieved by connectors by querying (via e.g. SPARQL) or by browsing a directory of connectors.
The metadata broker itself is implemented in the form of a connector, in the TSG the broker functionality is contained in a data app, with an triple store as backend to enable the SPARQL query functionality. Since the messages the metadata broker needs to handle are IDS Information Model annotated messages. The implementation of the data app will be made open source soon, which can be combined with the TSG Core Container and a triple store (e.g. Apache Fuseki) to deploy a full instance of a Metadata Broker.
The Clearing House is an optional service for a dataspace, that allows a trusted third-party to provide secure logging functionality. Especially logging on the aspect of clearing & settlement and to provide external logging for the execution of usage control.
Currently, there is no implementation of a clearing house available within the TSG. But there is an implementation available in the IDSA Github - Clearing House that is maintained by Fraunhofer AISEC. The integration between the TSG Core Container and its Policy Enforcement Framework with this clearing house implementation is not formalized yet and no examples are available yet.
The Vocabulary Hub is an optional service for a dataspace, that allows for management and retrieval of vocabularies used in the dataspace. An example of such a vocabulary is the IDS Information Model, containing the vocabulary of all the metadata used within IDS. Next to the generic vocabulary, the vocabulary hub can also contain domain-specific vocabularies that can be used to describe the actual data that is transferred with connectors.
Currently, there is no implementation of a vocabulary hub yet. But Semantic Treehouse is working on the development of such a component, with next to the management and retrieval of vocabularies also support for tooling around mapping messages of existing applications towards vocabularies (e.g. with RML). A position paper is released that describes how Semantic Treehouse could provide the vocabulary hub functionality, the position paper can be retrieved here: The Vocabulary Hub to configure data space connectors.
The App Store is an optional service for a dataspace, that provides a secure registry of data apps. Which is especially usefull when certified data apps are available, as the app store can provide this data app and its relevant metadata (including the certificate) to a connector.
Currently, there is no implementation of an app store that is compatible with the TSG components. Since the current data app structure used in the TSG Core Container does not work together with the generic data apps as proposed in the working versions of the IDS specifications. The expected update of the IDS specification will move towards support of a separate control and data plane, as the data apps are likely to be largely within the data plane changes are expected with regards to the app store and data apps. Therefore, the focus for the TSG is, for now, not on implementing an app store in the near future.