4. Component details

4.1 Resources and Service Offerings

Resources describe in general the goods and objects of the Gaia-X Ecosystem.

Resource Categories

A Resource can be a:

• Physical Resource: it has a weight, a position in space and represents a physical entity that hosts, manipulates, or interacts with other physical entities.
• Virtual Resource: static data in any form and necessary information such as a dataset, configuration file, license, keypair, an AI model, neural network weights, …
• Instantiated Virtual Resource: an instance of a Virtual Resource. It is equivalent to a Service Instance and is characterized by endpoints and access rights.

A Service Offering is a set of Resources, which a Provider aggregates and publishes as a single entry in a Catalogue.

A Service Offering can be associated with other Service Offerings.

classDiagram
    ServiceOffering o-- Resource: aggregation of
    Resource o-- Resource: aggregation of

class Resource{
    <<abstract>>
}

    Resource <|-- "subclass of" PhysicalResource: 
    Resource <|-- "subclass of" VirtualResource
    VirtualResource <|-- "subclass of" InstantiatedVirtualResource

    InstantiatedVirtualResource <..> ServiceInstance : equivalent to

4.2 Policies

4.2.1 Policy definition

Policy is defined as a statement of objectives, rules, practices, or regulations governing the activities of Participants within Gaia-X. From a technical perspective, Policies are statements, rules or assertions that specify the correct or expected behaviour of an entity¹².

The Gaia-X Policy Rules Conformity Document, which is an evolution of the previous Gaia-X Policy Rules and Labelling Document and Gaia-X Trust Framework, defines the Gaia-X Policies for all Providers and Service Offerings. They cover, for example, privacy or cybersecurity policies and are expressed in the Conceptual Model indirectly as attributes of the Resources, Service Offerings, and Service Instances.

4.2.2 Policy description

The general Policies defined by Gaia-X form the basis for detailed Policies for a particular Service Offering, which can be defined additionally and contain particular restrictions and obligations defined by the respective Provider or Consumer. They occur either as a Provider Policy (alias Usage Policies) or as a Consumer Policy (alias Search Policy):

• A Provider Policy/Usage Policy constrains the Consumer’s use of a Resource. For example, a Usage Policy for data can constrain the use of the data by allowing to use it only for x times or for y days.

• A Consumer Policy describes a Consumer’s restrictions on a requested Resource. For example, a Consumer gives the restriction that a Provider of a certain service has to fulfil demands such as being located in a particular jurisdiction or fulfilling a certain service level.

In the Conceptual Model, they appear as attributes in all elements related to Resources. The specific Policies have to be in line with the general Policies defined by Gaia-X.

graph TD;
    A[Policy Rules] --> |defines| B[general Gaia-X Policies]
    B --> |basis for| C[Resource-specific Policies]
    C -->D[Provider Policy/ Usage Policy]
    C -->E[Consumer Policy/ Search Policy]

4.2.2.1 Policy enforcement

Policy enforcement is executed by software engines (e.g. the Gaia-X Compliance Service or engines within a Data Exchange Service).

4.3 Service composition

4.3.1 Assumptions

The generic Gaia-X service composition model is derived assuming the availability of key related functions and systems within the Gaia-X Ecosystem. The first assumption is the availability of a Catalogue containing service offerings compliant with Gaia-X. These correspond to provider services with self-attested credentials and credentials verified by the Gaia-X Compliance Service. In addition to these services, there can be external and independent services offered by multiple third parties. A requirement on these third-party service offerings is to provide independent services compatible with Gaia-X compliant services. It is thus possible to combine them to produce composite services. Means to check for compatibility and composability are provided and potentially built into the respective credentials. Service composition consequently assumes that searching for compatible and interoperable services in multiple Catalogues is possible. Whenever such capability is not available, service offerings nevertheless come along with service templates and service descriptors and descriptions that readily embed this key information. Hence, credentials have to contain key characteristics and must have the appropriate structure. They would embed the following TOSCA-like or similar descriptors:

• Capabilities
• Requirements
• Properties
• Operations
• Artifacts
• Compatibility, interoperability, composability, substitutability attributes (information, list, possibly revealing if service components are bundles)
• Interfaces

Furthermore, we assume embedded additional information in credentials in the Catalogues. That is, providing information on how to chain services to ensure successful and failure-free composition as well as guaranteed operation at instantiation and run time.

4.3.2 Generic Service Composition Model

Considering an open European and international context involving multiple stakeholders and participants, the Gaia-X service composition model has to be abstract at the start of any initial service composition. The focus of the composition model is consequently on the service functional behaviour, with no constraints, localization, or preset values of non-functional attributes. Values are set only once the end users, tenants or consumers, have expressed their requirements, constraints and preferences. These values are gradually set as service composition moves from initial provisioning to the life cycle management of services at run time. Figure 1 depicts a high-level class diagram view of the service composition model.

Figure 4.1 - Simplified and abstract conceptual service composition model

This process shall by no means prevent or hamper interoperability, portability, or substitution of services and applications. This should require no or only minor changes. Figure 4.1 depicts the abstract and simplified service composition model. Beyond this simplified and abstract service composition view and class diagram, Figure 4.2 illustrates a more elaborate class diagram representation of the service composition model. The figure includes details and related functions and modules involved in service composition starting from a user service request to the instantiation of the services by providers. It also includes and extends the Gaia-X conceptual model with an expanded view of the service composition model.

4.3.3 Conceptual Service Composition Model

We start with a generic and abstract view of the conceptual service composition model and illustrate where it fits in the Gaia-X conceptual model. As far as the Gaia-X service composition model is concerned, both API and template-based services have to be included in the modelling framework. The role “Federator” in the diagram below indicates a provider which has been designated by the ecosystem governance to operate “Federation Services”

Figure 4.2 - Gaia-X Conceptual Architecture Model with Service Composition focus

Figure 4.3 depicts the need for a service discovery service that can search, match, and select from a Catalogue. The search may concern other Catalogues and offers depending on the will of the users to combine service offerings from different sources with verified interoperability and compatibility characteristics available in the Catalogue itself. End users or tenants express this initial request and set both their requirements and constraints in their demand.

Figure 4.3 - Generic and abstract conceptual service composition model

The service composition module first “analyzes, parses and decomposes” the service request. It then prepares a set of service discovery queries to find and select the candidate services among the service offerings via Gaia-X Federation Services.

Once the user has negotiated and approved the selected services and providers, candidate services are returned to service composition in order to build service deployment and instantiation workflows and plans. A contract is also established accordingly. The service composition module realizes the functional version of the solution and initiates service binding with the providers’ provisioned resources.

Starting from this abstract implementation plan for the Gaia-X Services Composition process, real implementations by suppliers will be developed. The actual deployment, binding and connectivity occur via an orchestrator, responsible for the coordination and organization of service instances, as well as the initial deployment, configuration and activation of such created service instances.

The orchestrator interacts with deployment and configuration tools ensuring the actual configuration, control and dynamic adaptation of service instances. A service life cycle manager is also associated with the orchestrator to manage services at run time. The orchestrator and service life cycle manager are typically external and act as the interface between service composition plans and providers. Optionally, the consumer acting as a broker can realize service composition. In this case, the consumer actively drives the orchestrators and partakes in the orchestration and service life cycle management according to compatible service deployment and management tools specified by the providers.

These tools and management systems can be proprietary or readily available in Catalogues. Popular configuration and deployment tools and systems such as Terraform, Ansible, Heat and Salt Stack are examples used for deployment and configuration purposes in cloud infrastructures. If service instances and resources are hosted in containers rather than in virtual machines, an intermediate container orchestration and management system such as Kubernetes is then used in an intermediate step, which is out of the scope of this document.

4.4 Identity and Access Management

The identities of participants in the Gaia-X Ecosystem rely on signed attributes, which can be requested and exchanged to gain individual trust from other participants.

Each Participant provides a unique identifier that is associated with the attributes and the Participant can cryptographically prove that this Identifier is under his control.

The attributes are evaluated by the Participants to implement, enforce, and monitor permissions, prohibitions and duties when negotiating a contract for services or resources.

In the context of Gaia-X, the attributes are encapsulated in the Party Credential associated with its controlled identifier. Examples of Party Credential specializations are:

• Natural Person Party Credential
• Legal Person Party Credential
• Service Party Credential
• Membership Party Credential

The key elements of the trustworthiness of an identity at the time of the negotiation are:

• The demonstration that the participant identifier is under the control of the credential holder using the verification method bound to the credential(holder property of Party Credential).
• The issued identity attributes conform with the KYB/KYC rules associated with the issuance of the identifier.
• The identifier issuers are trustworthy parties by checking the Gaia-X Registry and optionally other Verifiable Data Registries extending the Gaia-X rules.
• The check of credentialStatus property to be not equal to revoked/suspended (see Party Credential Status and W3C Verifiable Credentials Status List v2021 for additional information)

4.4.1 Dataspace / Federation onboarding and offboarding

The onboarding and offboarding of entities - participants, services, resources - within a Data Space or Federation is under the responsibility of the Data Space and Federation authorities which are autonomous from Gaia-X.

The above onboarding and offboarding processes are convenient optional ways for the participants themselves to request, demonstrate, collect, and revoke attributes/properties about themselves, their services, and their resources.

Those attributes/properties are expressed and exchanged via the Membership Party Credential specialization.

Gaia-X does not mandate nor enforce a particular timeline to gather Gaia-X Credentials.

Those could also be gathered at the time of contract negotiation, on the fly, depending on the policies being negotiated.

4.4.1.1 Layered identity and access management

The identity and access management relies on a two-tiered approach. In practice, this means that participants use a few selected identity systems for mutual identification and trust establishment, SSI being the recommended option for interoperability. After trust has been established, underlying existing technologies already in use by participants can be federated and reused, for example Open ID Connect (using OpenID4VP and SIOPv2) or domain-specific X.509-based communication protocols.

Gaia-X participants might need to comply with additional requirements on the type and usage of credentials management applications, such as mandatory minimum-security requirements, like multi-factor authentication. Server-to-server communication plays a crucial role in Gaia-X.

4.4.1.2 Architecture principles for this approach

Mutual trust based on mutually verifiable Participant identities between contracting parties, Provider and Consumer, is fundamental to federating trust and identities in the End User (PartyCredential holder) layer. Heterogeneous ecosystems across multiple identity networks in the participant layer must be supported as well as heterogeneous environments implementing multiple identity system standards. The high degree of standardization of participant building blocks provided by the mandatory attributes defined by Gaia-X must ensure that there is no lock-in to any implementation of identity networks and identity systems.

4.4.1.3 Chain of trust and identity

In the participant layer, the Gaia-X specifications indicate how to resolve and verify the participant identity of the contracting parties. The Consumer verifies the Provider’s identity, the Provider verifies the Consumer’s identity. Successful mutual participant verification results in a verified participant Token representing the trust between Provider and Consumer. The token payload contains one or more Gaia-X Credentials.

4.5 Data Exchange Services

4.5.1 Data Product

Gaia-X aims to promote open innovation through sovereign data sharing based on trust between all involved actors. Trusted data sharing requires specific mechanisms because (a) it is difficult (or practically impossible) to technically un-share data when they have been shared and (b) it must comply with specific regulations (e.g. GDPR and the various European acts on data). The Gaia-X Data Product concept and Operational model provide such appropriate mechanisms.

4.5.1.1 Data Product Conceptual Model

Figure 4.4 - Data Product conceptual model

Data are furnished by Data Producers (who are either data owners or data controllers in the GDPR sense) to Data Providers who compose these data into a Data Product to be used by Data Consumers.

A Data Usage Agreement (DUA), including usage terms and conditions associated with these data, is signed by both the Data Producer and the Data Provider and gives the Data Provider the legal authorization to use these data in accordance with the specified constraints. If a specific data license is attached to the data (for instance when the data is liable to GDPR), then this co-signed Data Usage Agreement constitutes a legal usage agreement and must refer to the explicit license rights from the Data Licensor (data subject or Data Controller as per GDPR, data owner, …). Signed Data Usage Agreements are notarized by a Data Usage Agreement Trust Anchor.

Data Products are described by a Data Product Description, which must be a valid Gaia-X Credential. This description is stored in a (searchable) Federated Data Catalogue. Each Data Product Description contains a Data License defining the usage policies for all data in this Data Product – it also contains other information related to billing, technical means, service level, etc. Hence a Data Product Description constitutes a data usage contract template.

Before using a Data Product, the Data Consumer negotiates and co-signs a Data Product Usage Contract (DPUC) with the Data Provider. This Data Product Usage Contract is based on the Data Product Description but may differ from the original one: the Data License of the Data Product Description is sub-licensed, possibly after modification during the negotiations, by enforceable Terms of Usage contained in the Data Product Usage Contract. For each licensed data included in the Data Product, the Data Product Usage Contract must include an explicit Data Usage Agreement signed by the corresponding Data Licensor (in case of data liable to GDPR, the signed Data Usage Consent must contain all information required by the regulation).

The Data Product Usage Contract is a Ricardian contract: a contract at law that is both human-readable and machine-readable, cryptographically signed and rendered tamper-proof, and electronically linked to the subject of the contract, i.e., the data. The parties can (optionally) request this contract to be notarized in a federated Data Product Usage Contract Store.

After such a contract has been agreed upon and has been signed by both parties, the Data Consumer can start accessing and using the data, realizing the Data Product Usage Contract. The Data Product Provider must check the Data Usage Agreement validity each time the data is provided to a Data Consumer, especially for recurrent data usage.

Such Data Usage with the associated Data Product Usage Contract corresponds to a Data Transaction as defined by the Data Spaces Support Centre (cf. DSSC Glossary).

The contract negotiation can lead to both parties agreeing on a Data Usage Logging Service (these logs might also include information needed for billing, inc. service level details, even if billing is outside Gaia-X perimeter).

Note: mapping between the Gaia-X Data Product concepts and the terminologies used in the various European regulations is given in Annex D.

4.5.1.2 Cascading agreement and right to oblivion

The above conceptual model can be applied recursively: the Data Consumer can integrate the Data into a new Data Product that can be used by other Data Consumers, who can in turn create new Data Products. It provides convenient mechanisms for data licensors or data controllers to control who is using their data and to revoke usage agreements.

The above model blocks subsequent data transmissions between the Data Provider and the Data Provider when the Data Usage Agreement is revoked and hence provides a more robust mechanism than the usual cascading mechanism where the chain of revocations will be broken if one of the participants in the usage chain is deficient.

In order to better support the right to oblivion, it is recommended that the Data Space defines a general policy mandating each participant to check the Data Usage Agreement validity before reusing the data. How a participant implements this policy depends on its own internal data management procedures and is outside the scope of Gaia-X.

4.5.1.3 Data Intermediaries

Data intermediary services are explicitly mentioned as an important concept in European Commission acts around data. Their definition is quite broad: “Data intermediation services may support users or third parties in establishing a commercial relation for any lawful purpose on the basis of data of products in the scope of this Regulation e.g., by acting on behalf of a user” (cf. Regulation (EU) 2022/868).

Compared to the general Gaia-X Conceptual Model, a Data Intermediary is an actor who combines several roles: Data Product Provider acting as a proxy between the Data Producer and the Data Consumer, Federator operating a Data Product Catalogue (often named data marketplace), Data Usage Agreement Trust Anchor acting as a trusted proxy between the Licensor and the Data Consumer, etc. A generic operational model is detailed in the Operating Models section later in the document.

Several Gaia-X Lighthouse projects are implementing this concept of Data Intermediary, with different perimeters and operating models adapted to their ecosystem specificities. Accordingly, it was decided to stick here to basic data exchange concepts and to let Lighthouse projects define higher level concepts like Data Intermediary according to their needs.

4.6 Gaia-X Trust Anchors

Gaia-X Trust Anchors are bodies, parties, i.e., Conformity Assessment Bodies or technical means accredited by the Gaia-X Association to be trustworthy anchors in the cryptographic chain of keypairs used to digitally sign statements or claims about an object.

For each accredited Trust Anchor, a specific scope of attestation is defined.

The list of valid Trust Anchors and rules is available via the Gaia-X Registry.

There are cases where the Trust Anchor is relative to another property in a claim.

Example: In the case of a gx:DataResource, the consent property must be signed by the gx:Participant identified by the dataController property, itself signed by the gx:Participant identified by the producedBy property, itself signed by the credential’s issuer with a keypair from a chain of certificates with at its root a Gaia-X accredited state Trust Service Provider.

Ecosystem Trust Anchors follow the same principle, but are defined by the ecosystem-specific governance.

---
title: example of multiple Trust Anchors for a Resource class 
---

erDiagram
    gxDataResource {
        ODRL consent "claim signed by the dataController"
        DID dataController "claim signed by the producedBy"
        DID producedBy "claim signed by the issuer of the credential"
    }

In this example, the dataController‘s participant, producedBy‘s participant and the TSP are Trust Anchors because they are mandatory fixed anchors in the credential chain of signatures. In this same example, all the claims could also be signed by the issuer if the dataController‘s participant, producedBy‘s participant and issuer are the same participant.

4.6.1 Gaia-X Trusted Data sources and Gaia-X Notaries

When an accredited Gaia-X Trust Anchor is not capable of issuing cryptographic material nor signing claims directly, then the Gaia-X Association accredits one or more Notaries, which will perform a validation based on objective evidence from a Gaia-X Trusted Data sources and will issue a declaration about the previously made attestation from the Trust Anchors.

The Notaries are not performing audit nor verification of the object of conformity.

The Notaries are converting “not machine readable” proofs into “machine-readable” proofs.

Example: The European Commission provides several APIs, including one to check the validity of EORI number. Unfortunately, those APIs are not returning Verifiable Credentials. Hence Gaia-X accredited the GXDCH to act as a Notary for EORI verification using the European Commission API as the Gaia-X Trusted Data source for EORI validation.

Example: For a CAB or a set of CABs performing third-party conformity assessment activities but not capable of digitally signing the attestations, the Gaia-X Association could accredit one or more Notaries. The role of those Notaries is to digitalize an assessment previously made. The Notaries are not performing the assessment. The Verifiable Credential signed by such a Notary will be a second-party conformity assessment activity and have as credentialSubject a statement of a third-party conformity assessment activity.
The overall trust level of such a Verifiable Credential will be lower than if the CAB was able to digitally sign the Verifiable Credential directly without involving a Notary.

4.6.1.1 Evidence

It is expected that the credentials issued by the Notaries contain the evidence of the validation process.

The Gaia-X Trust Framework provides the definitions and means to manage Gaia-X Conformity, Gaia-X Labels and Ecosystem Trust. The Architecture Document describes the technical means to digitally notarize claims by a Gaia-X participant based on the W3C Verifiable Credentials Data Model Recommendation.