4. Gaia-X Trust Framework Architecture¶

Trust
As per ISO/IEC DIS 20151-1 as well as CEN/CENELEC EN 18235-1, trust refers to a decision by an entity “to assume that a product, service or entity will behave as expected for a given circumstance”.

The Gaia-X Trust Framework architecture consists of two elements: - The Gaia-X Trust Protocol provides the generic means to allow ecosystems to establish mutual trust in a standardized interoperable way. - The Gaia-X Trust Framework provides the means to validate the assumptions underlying trust based on sets of criteria and rules defined by governance authorities for an individual ecosystem or data space.

In the following, we first describe the Gaia-X Trust Framework and subsequently introduce the Gaia-X Trust Protocol, which generalises the trust concepts and mechanisms used across ecosystems.

4.1 Gaia-X Trust Framework¶

The Gaia-X Trust Framework comprises the technical and organisational standards and open-source software for its operationalisation, allowing the establishment of trust in digital ecosystems.

It comprises two complementary elements:

• Specification of Gaia-X technical compatibility at the level of technical standards with an interoperable trust architecture, an open-source reference implementation (Reference Software Toolkit), and a corresponding compatibility test (Technical Compatibility Kit (TCK)).
  This specification includes blueprints for a digital ecosystem or data space authority to define its own governance framework and rulebook. See DSSC Blueprint v3.0: Data space governance framework/Data space rulebook.

• Specification of Gaia-X Compliance: A definition of specific criteria that ICT services and participants must fulfill and are evaluated by a Gaia-X Digital Clearing House (GXDCH), to be characterised as Gaia-X compliant with “Gaia-X Standard Compliance” and/or a “Gaia-X Label Level” for currently three label levels.
  This specification includes an extension mechanism (“Gaia-X Geography and Domain Extensions”) allowing certain organisations, so-called custodians, to define additional Gaia-X “labels” and compliance regimes.

Figure 4.1 - The Gaia-X Trust Framework

Trust service providers (TSPs) such as the Gaia-X Digital Clearing Houses (GXDCH) are approved by ecosystem governance authorities and operationalize ecosystem compliance rules. Requiring these TSPs to provide their services conforming to Gaia-X technical compatibility ensures that attestations issued by the TSPs are easily acceptable by all ecosystem participants without any need for intermediation or translation.

Gaia-X Technical Compatibility is also a key enabler for technical interoperability at the trust level across different ecosystems with different rule sets (e.g. European data spaces versus Asian trade corridors) and constitutes an integral part of the Gaia-X Trust Protocol (see later in this chapter).

The Gaia-X Framework offers key advantages in the following areas:

Digital Ecosystems:

• Validates ecosystem compliance against established criteria
• Verifies that enabling and federation services meet ecosystem governance criteria, ensuring trust in these services

Individual Participants:

• Supports self-determination in data and service usage by collecting and verifying credentials demonstrating compliance with ecosystem rules
• Enables credential verification during negotiations between participants

Interoperability:

• Promotes agreement on common ontologies and trust service providers across ecosystems

Extension and Delegation:

• Provides mechanisms for extending and delegating trust to enhance ecosystem flexibility

4.2 Using the Trust Framework¶

The sections in this chapter describe some relevant applications of the Trust Framework.

4.2.1 Performing automated onboarding and offboarding¶

Trust Frameworks can be used to automatically provide validation that all criteria of the onboarding process for participants and services, as defined by the ecosystem governance authority, are met.

The ecosystem governance authority defines criteria for onboarding, examples include:

• Gaia-X participant credential
• Identity credential issued by a regulatory authority (e.g. eIDAS in Europe)
• Ecosystem-specific criteria (e.g.):
  • Signature of a legal framework contract
  • Payment of the membership fee
• Attestations of conformity to specific standards or regulations
• Verifiable credentials issued by Trust Service Providers for which mutual trust has been declared

Proof of validation of criteria can be achieved through various methods:

• using the Gaia-X Trust Framework to validate Gaia-X Compliance with the help of the Gaia-X Technical Compatibility

• using the “Gaia-X Technical Compatibility Specifications” to validate ecosystem criteria

• Using an alternative Trust Framework (e.g. eIDAS, iShare,…) which provides an interoperable credential format.

Note that alignment on credential formats and credential exchange protocols allows mutual acceptance of validations across trust service providers.

Figure 4.2.1 - Automated Onboarding

Use of the Trust Framework for automated onboarding requires:

• A specific schema that contains the criteria and the accepted trust service providers
• An API that makes the individual credentials linked to the participant or service available to the compliance engine evaluating the onboarding criteria
• In general, a Wallet (e.g. EUDI Wallet, managed wallets by ecosystem providers, individual organizational or personal wallets) providing the credential store that interacts via defined Credential Exchange Protocols (see the Appendix)
• A compliance engine evaluating the defined onboarding schema

Successful verification of the onboarding criteria results in the issuance of an ecosystem membership credential, which can be used to authorize participants to operate within the ecosystem.

The ecosystem governance authority may set specific constraints. For example:

• Credentials may have a specific validity period and the membership credential’s validity may be dependent on a rule set evaluating the different validity end dates
• A credential may include or be associated with one or more roles, enabling the holder to perform authorized operations within the ecosystem
• The compliance engine may periodically re-evaluate (verify) the individual credentials (e.g. check for revocations) and revoke an issued membership credential before the end of the original validity period (automated offboarding)

Prerequisites for the automated onboarding to work are:

• Interoperability of the Credential formats used by the different Trust Service Providers
• Interoperability of the Credential Exchange format between Credential Issuer, Wallet and Compliance Engine
• Interoperable Credential Verification methods

Please also refer to Chapter 3.4 for considerations on how compliance with ecosystem rules can be established by combining verifiable credentials issued by different Trust Service Providers.

4.2.2 Performing credential verification¶

Credential verification is executed by the Compliance Engine in conjunction with the Registry.

The ecosystem or data space defines credential schemas that specify the vocabulary for expressing claims about credential subjects. These schemas are represented as SHACL shapes, in accordance with the W3C Shapes Constraint Language (SHACL).

Credential schemas are published and maintained in the Registry to ensure consistent access and reuse.

At any point where Verifiable Credentials are issued or processed, the applicable SHACL shapes are known and constitute the shapes graph. Each Verifiable Credential constitutes a data graph. Verification is performed by validating the data graph against the shapes graph, as defined by the SHACL specification.

4.2.3 Identifying Ecosystem trust services¶

The discoverability of Ecosystem Trust Services can be enhanced using a catalogue of trustworthy registries following the Gaia-X Technical Compatibility specifications.

By facilitating the identification of ecosystem trust services, also enabled by the Gaia-X Trust Protocol, federation and cross-ecosystem integration of trust are supported.

Examples of ecosystem trust services are credential stores, Auditing and Observability services, Marketplaces, Authorization and Access services, together with standard services provided by Identity and Catalogue Providers.

4.3 GXDCH¶

The Gaia-X Digital Clearing House (GXDGH) is the mechanism adopted by the Gaia-X Association to provide running software to assert compliance without becoming a host or a point of centralization for the ecosystem.

Each GXDCH instance must be operated by a service provider according to rules defined and approved by the Gaia-X Association.
The instances are non-exclusive, interchangeable, and operated by multiple market operators from different geographical locations and different industries.

The GXDCHs are connected in a network to ensure both free access and selection by Gaia-X adopters, and consistency of the compliance data managed by these nodes.

Each GXDCH must provide public services to implement the compulsory elements necessary to achieve Gaia-X compliance under the sole governance of the Gaia-X Association. Furthermore, each GXDCH can offer (or resell) services to support the extended adoption of Gaia-X (out of the governance of the Gaia-X Association).

The mandatory components to be included in the GXDCH can vary from one release to another, as more services become available over time. The updated list of components is available here.

All the components that go into the GXDCH are open-source, either reused or developed by the Gaia-X Association.

The following page displays, for each Gaia-X Digital Clearing House, the version of its components along with their health status (UP or DOWN).

4.4 Gaia-X Conceptual Model¶

4.4.1 Terminology sources¶

The terminology employed in this section is informed by various sources, including the following recognised standards:

ISO/IEC 17000:2020 – Conformity Assessment — Vocabulary and General Principles This international standard, developed by the ISO Committee on Conformity Assessment (CASCO), provides standardized definitions and general principles related to conformity assessment activities, including the accreditation of conformity assessment bodies.

Verifiable Credentials Data Model v2.0 – World Wide Web Consortium (W3C) This specification defines a data model for expressing verifiable credentials on the Web in a cryptographically secure, privacy-respecting, and machine-verifiable manner. It outlines key concepts such as credentials, presentations, and associated roles like issuers, holders, and verifiers, facilitating interoperability and trust in digital credential ecosystems.

4.4.2 Definitions¶

4.4.3 Model Core¶

The diagrams describe the organisations and concepts foundational to the translation of the rules in the conformity assessment schema defined by the governance authority into digital credentials and their subsequent verification.

The (Ecosystem/Data Space) Governance Authority:

• Defines one (or multiple) conformity assessment schemes, which are translated into a machine-readable format and stored in the Registry
• Approves CABs as a validation method for specific scopes and purposes
• Approves Trust Service Providers (TSPs) for given scopes and purposes
• Selects and approves Trusted Digital Identities where a Trusted Digital Identity is bound to a cryptographic key
• Approve Notaries for given scopes and purposes

The Conformity Assessment Body:

• Acts as a validation method
• Has a scope
• May use a Notary
• If it can issue verifiable credentials, it will also act as a Trust Service Provider

Figure 4.4.3 (a) - Conceptual Model-1

The definition of compliance criteria (e.g. for participants and services offered in the ecosystem/data space) encompasses both the definition of conformity rules and the definition of required validation methods. The definition of accepted validation methods may involve the definition of existing standards that can be used to assess conformity, or the identification of attributes that can be technically verified, and the definition of the type of assessment required (e.g. declaration or certification performed by a Conformity Assessment Body). While establishing a conformity assessment schema, the Governance Authority also defines the list of Trust Service Providers that are approved as trusted issuers for specific scopes and purposes.

Figure 4.4.3 (b) - Conceptual Model-2

From an implementation perspective, the Participants issue claims on themselves and the services they provide according to the format defined in the Registry. These claims are signed by approved Trust Service Providers, and the validation of compliance criteria is performed by the Compliance Engine based on the information (credential schemas/shape graphs) that are maintained and made available through the Registry. The Notary service supports the issuance of credentials.

4.5 Gaia-X Trust Protocol¶

4.5.1 Problem Statement¶

Trust frameworks – including the Gaia-X Trust Framework described above – are typically defined by the ecosystem or data space governance authority for a specific ecosystem and its participants. Due to the interlinked nature of today’s supply networks, however, current experiences and expectations indicate that a single organization participating in one data space or ecosystem will have to exchange data (and access services) simultaneously with many different ecosystems and their participants.

As ecosystems are completely autonomous when specifying their trust framework, the question then arises how these sovereign ecosystems can establish mutual trust with other ecosystems on behalf of their participants without any explicit bilateral or overarching governance. (This is often called the cross ecosystem trust dilemma.)

The Gaia-X Trust Protocol provides a generic way for an ecosystem governance authority

1. to define common rule sets for the ecosystem,
2. to define the methods to validate those rules,
3. to describe the methods to issue and verify digital attestations by which trust service providers attest conformance to these rules, and
4. to make these accessible to other ecosystems and their participants in a standardized and interoperable way.

It specifies a reference model to render trust-related communication interoperable between different ecosystems ³ without forcing ecosystems to accept anything from others. By complying with the Gaia-X Trust Protocol, different ecosystems may chose to accept digital attestations issued by one or more trust service providers of another ecosystem based on a common specification⁴.

The Gaia-X Trust Framework is a specific instantiation of the Gaia-X Trust Protocol. In this case, the Gaia-X Policy Rules Committee as governance authority defines

• the rule sets for Gaia-X compliance (i.e., as stated in the Gaia-X Compliance Document with its associated schemas, validation rules and permissible standards) and
• the trust service providers (i.e., the Gaia-X Digital Clearinghouses, GXDCH).

4.5.2 Gaia-X Trust Protocol Technical Specification¶

4.5.2.1 Ecosystem Trust Profiles¶

The Gaia-X Trust Protocol is based on the premise that ecosystems need to be able to decide for themselves whether they trust (entirely or even just partially) the trust framework of another ecosystem or not. In order to allow the ecosystem to actually reach this decision, the “trusting” ecosystem (called trustor) needs to be able to obtain and understand the relevant elements of the other “trusted” ecosystem (called trustee). This is realizable in a scalable way when each trustee makes available the core elements of its individual trust framework in a common “language”. Potential trustors then are able to access and understand a foreign trust framework and base their decision to trust (parts of this) trust framework on this information.

Based on our work with several ecosystems, the smallest set of technical concepts required to allow this decision process to take place comprises a set of triples with the following elements:

We shall call one such triplet a trust proposition and the list of all the trust propositions (= triplets) for a specific ecosystem an ecosystem trust profile.

4.5.2.2 Example¶

For the Gaia-X Trust Framework itself, the Gaia-X ecosystem trust profile recognizes the following elements.

The full version of the Gaia-X ecosystem trust profile may be retrieved from the Gaia-X Meta-Registry here.
The ontology subset for specifying an ecosystem trust profile is part of the Gaia-X ontology and defined here.

As is evident from the example, the Gaia-X Trust Protocol defines the generic means for linking the (verifiable) credentials of arbitrary content to different validation methods (e.g. as defined in ISO/IEC) using various ecosystem-specific criteria and verification methods.

The implementation of these elements is supported by the Gaia-X ICAM Semantic Model (ref. ICAM Document), which provides the semantic constructs required to describe trust scopes, credential types, trusted issuers, and trust relations in a consistent and interoperable way.

4.5.2.3 Establishment of Mutual Trust¶

Mutual trust, where one ecosystem (the trustor) commits itself to trust another ecosystem (the trustee), is then simply established by having the trustor – in full autonomy – select and accept a suitable subset of the TSPs of the trustee using some particular credential types for one or more trust scopes. The trustor will then simply add these “triplets” to its own ecosystem trust profile. Participants of the trustee ecosystem will then be able to recognize that specific credentials issued by specifics TSPs for a trust scope are also approved by participants of the trustor ecosystem.

4.5.2.4 Gaia-X Meta-Registry¶

In order to allow different ecosystems and, especially, their participants, to easily identify potential areas of mutually shared trust, all trust propositions (the triplets) of the ecosystem trust profile adopted by a particular ecosystem are collected into and published through a dedicated Gaia-X Meta-Registry.

Retaining their autonomy, ecosystems may publish their own trust propositions to the Gaia-X Meta-Registry. Other ecosystems participants will then be able to identify which of their own TSPs for a specific trust scope are at the same time also accepted by another ecosystem they want to exchange data with.

The Gaia-X Meta-Registry specifications and implementation will be further extended and refined in future releases based on requirements gathered from ecosystems and adopters. This includes governance, publication and validation processes, provenance and authenticity of published artefacts, and trust establishment mechanisms.

The current version of the Gaia-X Meta-Registry can be accessed here. Instructions on how to integrate an ecosystem trust profile into the Gaia-X Meta Registry are available here.

4.5.2.5 Gaia-X Trust Protocol Architecture¶

The resulting cross-ecosystem trust framework architecture is depicted in the following figure. The critical observation here is that, since ecosystems and data spaces may vary in their individual compliance rules at the intra-ecosystem trust layer, successful establishment of cross-ecosystem trust requires consensus on a common Gaia-X technical compatibility layer (as specified in this Architecture Document) as well. Without it, transport and syntactical interoperability of the trust propositions shared between different data spaces cannot be automatically ascertained. Compliance with the Gaia-X technical compatibility specification is assured by conforming to a Gaia-X technical compatibility (test) kit (indicated as “Gaia-X TCK” in the figure below). This can be attested by a suitable “Gaia-X technical compatibility” credential (forthcoming).

Figure 4.5.2.5 - Gaia-X Trust Protocol

4.5.2.6 Evolution of the Gaia-X Trust Protocol¶

Evidently, the Gaia-X Meta-Registry conflicts somewhat with the assumed autonomy of ecosystems. While the Gaia-X Meta-Registry does not constitute any form of supra-ecosystem governance mechanism, its (current) logical and organizational centralization within the Gaia-X Association is at odds with the independence of the individual ecosystems submitting their trust profiles to the Gaia-X Meta-Registry through the Gaia-X Association.

Recognizing this we suggest replacing the Gaia-X Meta-Registry with a suitable Gaia-X Trust Registry Protocol enabling different ecosystems to exchange information contained in their respective (ecosystem trust) registries (see the figure below).

Figure 4.5.2.6 - Gaia-X Trust Protocol - evolution

However, from an adoption-oriented point of view we believe that the Gaia-X Meta-Registry is a much needed intermediate step towards deploying the Gaia-X Trust Protocol version 2. Our experiences during several events indicate that ecosystems very much appreciate the concrete embodiment of the abstract concept of ecosystem trust profiles in the form of a browsable catalog, i.e., the Gaia-X Meta-Registry. During further adoption of cross-ecosystem trust using the Gaia-X Trust Protocol version v1, ecosystems will gradually start to understand and realize the (even more abstract) solution to this centralized element present in version v1 of the Gaia-X Trust Protocol.

4.5.2.7 Model for Federated Ecosystems¶

The Gaia-X Trust Protocol establishes the foundation for interoperable trust across different ecosystems and domains. It enables ecosystems to federate their trust frameworks by adhering to this common model. Conformance with the Gaia-X technical compatibility specification (as captured in this Architecture Document) then allows any ecosystem to make use (“operationalize”) the trust information contained in the Gaia-X Meta-Registry.

As a mechanism for federation between two ecosystems, the governance authority of Ecosystem A shall agree on the equivalence of the scope of specific properties between the individually defined schema, and ecosystems A and B shall mutually agree on the Trust Service Providers (and their validation methods) for the respective scope.

Mutually trusted services may be published in joint catalogues.

Figure 4.5.2.7 - Ecosystem Federation

4.6 Cross-Ecosystem Interoperability¶

Cross-ecosystems interoperability can be defined as “the ability of participants to seamlessly access and/or exchange data and services across two or more ecosystems.

This covers the cases where a use-case requires implementation across domains and geographies, across isolated environments (e.g. a factory shopfloor or a hospital), and an integration of data across domains to provide an integrated view of a product:

Figure 4.6.a - Cross-Ecosystem Interoperability - Use case scenarios

Cross-ecosystems interoperability addresses the governance, business and technical frameworks to interconnect multiple ecosystem instances seamlessly.” (adapted from the definition of “cross-data spaces interoperability” in the Glossary of the DSSC Blueprint v3.0).

This includes:

• trust in services that exchange data across ecosystems
• trust in services that are provided by a single ecosystem, but relied upon by other ecosystems
• mutual acceptance of identities

The Meta Registry defined in the Gaia-X Trust Protocol provides a common and interoperable way to publish and access ecosystem trust profiles and related information.

Mutually recognized Trust Service Providers and the capability to accept validations across ecosystems serve as enablers for cross-ecosystem interoperability.

Interoperability across ecosystems is further supported by adopting the Gaia-X Trust Framework, which provides specifications facilitating both technical and semantic interoperability. It also offers multiple sets of compliance criteria that can be selected, combined, and extended by ecosystem governance authorities to meet their specific needs.

Finally, the Eclipse Conformity Assessment Policy (CAP) Ontology, which provides a standardised framework for expressing and verifying conformity assessment policies, represents another important asset for interoperability in data-sharing ecosystems.

4.7 Inter-Ecosystem Interoperability¶

Trust Frameworks in general - not just limited to the Gaia-X Trust Framework - intend to increase interoperability at the following four layers (ref. European Interoperability Framework):

• legal interoperability: specifying criteria related to jurisdictions or domain- or ecosystem-relevant legislation (e.g., GDPR, Data Act, Data Governance Act)

• organizational interoperability is enhanced by better aligning data transactions with (i) business processes and their (user) requirements and (ii) with common domain or ecosystem governance rules

• semantic interoperability is supported by ensuring that the meaning of the exchanged information is preserved throughout exchanges between parties (for instance, by the definition of semantic models and common ontologies)

• technical interoperability derives from the use of international standards widely adopted and recognised

In the approach chosen by Gaia-X, these four layers are addressed in a two-pronged configuration:

• Gaia-X Compliance addresses legal and organisational interoperability (of trust)
• Gaia-X Technical Compliance addresses semantic and technical interoperability (of trust)

Depending on the particular configuration of an ecosystem’s trust framework, an ecosystem may also implement certain elements of organisational and legal interoperability using Gaia-X technically compliant mechanisms. For instance, an ecosystem may extend the Gaia-X core ontology for ecosystem participants to include certain credentials (e.g., a Business Partner Number) allowing the automated recognition of an organisation as a valid ecosystem participant; such an extended ontology may also include credentials specifying certain roles a participant may hold within an ecosystems, e.g., service provider or service consumer.

4.8 Services and Service Composition¶

4.8.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, and so on
• Instantiated Virtual Resource: an instance of a Virtual Resource. It is equivalent to a Service Instance and is characterised 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

Services can be selected and composed across different ecosystems which rely on a common Trust Framework. This approach enables the creation of new service offerings that meet specific compliance requirements, as these are satisfied by the constituent services.

For example, a software provider might offer a service that utilizes multiple Cloud Service Providers, each of which complies with the requirement to use only data centers certified under ISO/IEC 27001.

4.9 Policies¶

4.9.1 Policy Definition¶

A Policy is a statement of objectives, rules, practices, or regulations governing the activities of participants within a given ecosystem or data space. From a technical perspective, Policies are statements, rules or assertions that specify the correct or expected behaviour of an entity¹².

The Gaia-X Compliance Document defines the general Gaia-X Policies applicable to Participants and Service Offerings. These policies cover, for example, privacy and cybersecurity requirements and are expressed indirectly as attributes of Resources, Service Offerings, and Service Instances.

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

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]

Policies are expressed by one or more parties about one or more assets. An asset can also be a party, making this simple model recursive and capable of handling even the most complicated usage scenarios, with multiple providers, consumers, federators, data intermediaries, data subjects, business legal representatives, employer/employee relationships, and much more.

flowchart TD
    party(Party)
    policy(Policy)
    rule(Rule)
    asset(Asset)
    action(Action)

%%    party -- expresses --> policy
    policy -- a non-empty set of --> rule
    rule -- ability/inability/obligation to exercise --> action
    action -- is an operation on --> asset
    asset -- subjects to --> rule
    party -- has role in --> rule
    asset -. can also be a .-> party

The workflow above is the generic representation of the Open Digital Rights Language (ODRL) model.

The main aspects to be considered from a technical point of view are:

• Policy representation: interoperable access and usage policies that are specified in a human and machine-readable format. Policies generally express three possible restrictions: prohibitions, obligations, and permissions. Constraints defining a rule can be combined into more complex rules, which then form the applicable policy.
• Decision-making/policy engine: during the execution of a data transaction, the policies need to be evaluated. This decision typically requires context information. With the decision context, the policy engine will decide whether the request or usage is permitted. The evaluation process is handled by the policy engine, which is instantiated by the data product provider and the data consumer or a trusted third party.
• Enforcement and execution of policies: the enforcement and execution of policies is a key capability which needs to be implemented for both access and usage policies.

Realization of Policy Definition and Policy Enforcement follows the W3C ODRL specifications; the definition of the execution components follows NIST (see PDP and PEP)

4.9.3 Gaia-X Policy Reasoning Engine¶

The Gaia-X Policy Reasoning Engine allows for a comparison between policies set up by the provider of a service and usage intentions declared by a consumer, by leveraging the following standards:

• W3C ODRL (Open Digital Rights Language) to express policies
• W3C Verifiable Credentials
• JSON Path to evaluate the credentials
• RDF to represent the policies as triples (subject, predicate, object)
• SPARQL to query the RDF triples

An open-source library to perform policy reasoning is provided by the Gaia-X Lab.

4.9.4 Policy Decision Point (PDP)¶

4.9.4.1 Reference implementation¶

A specific ODRL profile is built by the Gaia-X Lab with the purpose to refer in a clear and precise way to verifiable credential claims in an ODRL Policy. This gives assignors of policies a way to enforce policies using trustworthy and verifiable claims from an assignee, and in doing so, having more trust and confidence in the enforcement of the policy.

4.9.4.2 Policy Enforcement¶

The Policy Enforcement Point (PEP) intercepts the request from the data product provider. To verify the request, the decision context is set up and processed through the Policy Decision Point (PDP). After retrieving the relevant context information, the data request is verified. If the request is invalid, the data product provider sends a rejection, which is processed by the data consumer. If the request is valid and certain actions are required, these actions are executed before granting data access or starting the transfer. The response is then processed by the data consumer. If the request is valid, the same interception and processing steps as on the Data Product Provider side are executed (involvement of PAP, PDP, PEP, PIP). In the last phase, the data consumer provides proof of the implemented policy enforcement, which the data product provider verifies. In case of an invalid proof, the data product provider can and must reject the interaction and may initiate further actions. If everything is valid, the transaction is complete.

The enforcement phase starts when the actual data transaction is executed, and it takes place throughout the data transaction. The goal of the enforcement phase is to evaluate the relevant rules of the policy and decide whether the data transaction may proceed unless an agreement or contract has already been negotiated, in which case, only the contract’s validity must be verified.

For different types of rules, evaluation may occur at different stages of the data transaction:

• Access rules are primarily evaluated by the data provider before any data is exchanged. The data consumer may also check these rules when receiving data to ensure compliance with access conditions.
• Usage rules are evaluated by the data consumer when the data is used. Depending on the usage rule, evaluation might be required at initial data usage and constantly throughout the lifecycle of the data usage.
• Consent rules require the evaluation of consent of third parties, which might be revoked during the data transaction or data use. Therefore, evaluation should occur on both the data product provider and consumer sides.

4.10 Ecosystem Trust Functions¶

In addition to the core elements, trust frameworks typically contain supplementary trust-related functions that accomplish or facilitate more specific tasks. Here, we explain two functions included in this version of the Architecture Document, namely:

• means for rights or trust delegation and consent management

• computation of indexes providing interoperability metrics and information on the potential trustworthiness of an entity or other ecosystem element.

4.10.1 Rights Delegation¶

The delegation of rights takes place within a Trust Scope, which defines the scope in which credentials, trusted issuers, identity providers, and associated semantic definitions are considered valid. It also identifies the trusted issuers, vocabularies, and schemas that participants use to interpret and validate credentials within that scope.
The rights are delegated based on the type of credential and its usage.
The Party Credential is based on the Verifiable Credentials Data Model v2.0 and is the basis for all IAA Parties such as Natural Persons, Services, and Legal Persons. The general purpose Party Credential can be extended into specialised credentials, for example:

• Private Party Credential: Party Credentials containing PII are not considered published or reachable via their identifier by everyone. Instead, they are intended to be stored in secure storage such as a wallet, secure storage device, secure vault storage, etc. An example of this type of credential is the NaturalPersonCredential, issued by a Legal Participant to one of his users/employees for the purpose of authorising a Natural Person to interact with Relying Parties (RP) in a certain context.
• Public Party Credential: The Party Credential contains data that can be publicly accessed and queried.
• Trust Scope Credential: This credential enables the usage of Party Credentials by defining their accredited issuers. Furthermore, the Trusted Scope Credential supports the cooperation and interoperability between organizations/ecosystems/data spaces, by easing the use of external Trust Service Providers.

Credential Statuses

A Verifiable Credential can have one of the following statuses:

• expired if the validUntil attribute is older than the current datetime or the certificate containing the key used to sign the claim has expired.
• revoked
• if the keypair used to sign the credential is revoked.
• if the credentialStatus has the statusPurpose property set to “revocation” and the value of status at position credentialIndex is true
• suspended if the credentialStatus has the statusPurpose property set to “suspension” and the value of status at position credentialIndex is true
• deprecated if another verifiable credential with the same identifier and the same signature issuer has a more recent issuance datetime.
• active only if none of the above conditions apply.

For more details, refer to the ICAM document.

4.10.2 Trust Indexes¶

Traditional assessment schemes defined by ecosystem authorities often face limitations:

• They do not automatically adapt to market dynamics, which typically evolve faster than established rules
• They fail to capture the complexities of organizational and semantic interoperability, effectively reducing interoperability to the most basic commonly accepted denominators.

To address these challenges, four Trust Indexes are introduced:

• veracity
• transparency
• composability
• semantic match

These indexes are designed to be used by all stakeholders — licensors, licensees, producers, providers, and consumers — as metrics for assessing interoperability and trust relative to other offerings within ecosystem catalogues. The intention is for the ecosystem to assist the market by providing measurement tools, enabling market participants to converge towards optimal solutions.

A more detailed explanation of the four indexes and the way to compute them is provided in an Appendix to the document. (see Appendices - Trust Indexes)

4.11 Data Space Architecture using the Gaia-X Trust Protocol¶

Data Spaces can leverage the Gaia-X Trust Protocol to onboard participants by verifying compliance with their Data Space Rulebook and issuing corresponding proofs of membership and roles to facilitate trusted data exchange.

As illustrated in the figure below, the Data Space Governance Authority defines the Data Space Rulebook, aiming to operationalize regulatory, business, and/or technical requirements.

The Data Space Rulebook must specify, in a machine-readable format, the Criteria, Compliance Rules, Validation Methods (via first-, second-, or third-party assessments, potentially relying also on technical means), and the accepted Trust Service Providers authorized to sign the required claims.

The Registry stores the lists of accepted Trust Service Providers along with the schemas for data space credentials, which serve as the vocabulary for claims about credential subjects (e.g., data space offering credentials and data space membership credentials). The Rules Engine validates data graphs against the shape graphs stored in the Registry to assess compliance with the Data Space Rulebook.

The assessment outcome is issued as a credential under the authority of the Data Space Governance Authority. Participants can store this credential using a Wallet Service (also referred to as a Credential Store) and use it as proof of compliance or for further qualification under a data space Conformity Scheme.

The setup of the Data Space is completed and can be enhanced by utilizing additional Trust Services accessible through a catalogue adhering to the Gaia-X technical compatibility specifications, along with protocols designed to enable contract negotiations and trusted data transactions.

Figure 4.11 - Data Space architecture enabled by the Gaia-X Trust Protocol

4.12 Trusted Artificial Intelligence Environments¶

One scenario which combines the elements defined above is that of an environment where artificial intelligence (AI) services operate on controlled data sets and infrastructures. The following example illustrates how the concepts and mechanisms described in this chapter can be applied to support trust, compliance, and interoperability in AI-enabled environments.

Figure 4.12 - Scenario of a controlled AI environment

4.12.1 Compliance of the data used in AI use cases¶

All machine learning (ML) and AI models rely on (ideally large) data sets for training purposes. This has become even more entrenched with the advent of generative AI (genAI) algorithms and the associated foundation models featuring literally billions of parameters which all have to be trained and calibrated. These data sets are usually provided by different sources (discounting synthetic data for training purposes). Critical applications often rely on data sets provided by a federation of data owners of a specific domain (e.g. Industrial AI, Healthcare…). In such a context, the Gaia-X Trust Protocol can be used to ensure:

• Provenance
• Authorship
• Digital Rights
• Compliance (e.g. Personal use of health data)
• Quality
• Validated correctness and precision
• Scientific value

of the data which is being provided.

To ensure improvements through fine-tuning and reasoning, as well as to avoid degradation and hallucinations, the prompting and inference should also be assessed with respect to the elements listed above.

4.12.2 Compliance of the underlying infrastructure and operators¶

Proof needs to be provided that the companies comply with the regulatory requirements of their region (e.g. AI Act) and domain (e.g. Healthcare), with respect to the underlying infrastructure. This can include:

• Requirements as defined in the Gaia-X Compliance
• Extensions (as defined in Sovereign Cloud Frameworks or specific domain requirements)

Companies training and operating trustworthy AI are required to have measures in place to allow

• Explainability of the output generated
• Validation of ethical principles and guardrails
• Compliance with data protection and privacy regulations

4.12.3 Compliance of AI services (e.g. AI-Agents, Gen AI, ML or Simulation services)¶

• Agents need to be clearly associated with the liable company (e.g. an Agent needs to have a unique ID linking it to the Agent owner, which can be achieved by chaining an Agent ID to an Organizational ID using the Trust Scope Credential Mechanism).
• Proof of permission from the connecting systems or persons to allow Agent operations (e.g. similar to DUA in Data Exchange: for example, an “Agent Usage Agreement” where a patient would authorize an agent to access and process their data and provide a diagnosis).
• Proof that an Agent has been validated by a CAB to operate according to the principles of the AI Act.

Figure 4.12.3 - Agent ID chained from Organization Credential