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 Compliance Document defines the Gaia-X Policies for 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 this embedded additional information in service descriptions in the Gaia-X service catalog. 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. The service composition model shall also allow for the portability of applications among cloud Providers, adhering to the high-level objectives described in the Franco German position on Gaia-X.

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 “Operator” 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 the Gaia-X service catalog. The search for matching services may concern other service catalogs 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 catalog itself. Note that the discovery can be basic and limited to consumers selecting services by themselves or more elaborate via intelligent service discovery based on demands expressed using natural language or intent based paradigms. Such service discovery services as well as composition and orchestration engines are out of the scope of Gaia-X but found in the Gaia-X federated services catalog offerings proposed by providers, digital clearinghouses and third parties.

End users or tenants express theis initial service 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 the 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
• Custom Party Credential (domain specific party credential)

Another important type of credential is represented by the TrustAnchorCredential that provides a semantic description, the scope, the issuer(trust anchor), and any additional needed information by the PartyCredential. The TrustAnchorCredential mainly defines:

• The Scope where the PartyCredentials are considered valid.
• The TrustedIssuer entitled of issuance of the PartyCredential in the above Scope
• The Vocabularies (expressed in SHACL) that semantically defines the PartyCredential extended properties and the embedded attributes
• The Trusted List of issued PartyCredential in the scope by the trusted issuer.

Like for the PartyCredential, there are also several specializations of the TrustAnchorCredential, here are some examples:

• Organization Trust Anchor – a self issued credential that entitles an organization to define:
• scope - Organization Credential Management (OCM).
• trusted issuer - itself.
• vocabularies - defines the semantics of Roles/Identity Attributes and Domain Specific Credentials valid in the defined scope.
• trusted list - to assign and revoke Roles/Identity Attributes to its parties (users, natural persons, endpoint services, etc) issuing PartyCredential (referencing vocabularies and embedding the above Roles/Identity Attributes)
• Ecosystem Trust Anchor - a self issued credential that entitles an Ecosystem operator to define:
• scope - manage an Ecosystem (onboarding/offboarding/role assignement etc.).
• trusted issuer - itself.
• vocabularies - defines the semantic of Roles/Identity Attributes and Domain Specific Credentials valid in the defined scope.
• trusted list - to assign and revoke Roles/Identity Attributes to its members (other Participants) issuing MembershipPartyCredential (referencing vocabularies and embedding the above Roles/Identity Attributes)
• Labelling Trust Anchor - a Gaia-X issued credential that entitles a Participant to act as a CAB entitled to issue attestations related to services conformity labels.
• scope - issue Gaia-X conformity labels .
• trusted issuer - the Participant selected by Gaia-X to operate as CAB.
• vocabularies - defines the semantic of Labels that are valid in the defined scope.
• trusted list - to assign and revoke Labels issued to other Participants

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 Bitstring Status List v1.0 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 Products and Data Exchange Services¶

Gaia-X aims at promoting 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 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, or data holders in the Data Act sense) to Data Providers who compose these data into a Data Product to be used by Data Consumers.

If a specific data license is attached to the data, then a Data Usage Agreement (DUA), including usage terms and conditions associated with these data, shall be signed by the Data Licensor (data subject or data controller as per GDPR, user as per Data Act, data owner as per copyrights laws, …) giving (a) to the Data Producer the right to distribute the data and (b) to the Data Consumer the legal authorization to use these data in accordance with the specified constraints. The Data Usage Agreement concept is a general concept which addresses every kind of licensed data and hence encompasses also the concepts of Consent from GDPR and of Permission from the EU Data Act (more detail in Annex C). In case of data liable to GDPR or Data Act, the Data Usage Agreement must contain all information required by the regulation (in particular the purpose of usage). Data Usage Agreements are notarized by a Data Usage Agreement Trust Anchor and might be revoked at any time by the data licensor.

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 (if the Data Product contains data from serveral Data Licensors, then the Data Product Usage Contract must include a Data Usage Agreement from each Data Licensor).

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. The Data Consumer must also check the Data Usage Agreement validity each time it uses the data (to make sure that the agreement has not been revoked).

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.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.

Indeed, the above model blocks subsequent data transmissions between the Data Product Provider and the Data Consumer when the Data Usage Agreement is revoked and hence it 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.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
    gx:DataResource {
        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 Trust Service Provider 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 source and will issue an attestation 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.