4. Gaia-X Trust Framework Architecture¶

4.1 Elements of a Trust Framework¶

A (generic) trust framework provides the methodology and technical specifications for collecting, organising, and verifying information to support trust decisions - that is, decisions about whether an entity, piece of information, or transaction can be trusted.

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 v2.0: Data space governance framework/Data space rulebook).

• Specification of Gaia-X Compliance: A definition of specific criteria that ICT services, data exchange, 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

Gaia-X Technical Compatibility, operated by trust service providers accepted by ecosystem Governance Authorities, can be used to implement ecosystem compliance rules.

Gaia-X Technical Compatibility is also an enabler for technical interoperability at the trust level across different ecosystems with different rule sets (e.g. European data rooms versus Asian trade corridors).

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 for compliance with ecosystem rules
• Enables credential verification during participant negotiations

Interoperability:

• Promotes agreement on common ontologies and trust anchors 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 an individual criterion 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
• alignment on credential formats and credential exchange protocols allows mutual acceptance of validations across trust service providers
• Using an alternative Trust Framework (e.g. eIDAS, iShare,…) which provides an interoperable credential format.

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 rules
• In general, this is implemented through 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 (e.g. OID4VC, Eclipse DCP, DIDComm; 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:

• 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
• 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 rules can be built 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, 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. Such providers then have the role of Federator. The Gaia-X Association is not a Federator itself.

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 with 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 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¶

Entity: item relevant to the operation of a domain that has recognizably distinct existence (source: ISO/IEC 24760-1:2019)

Participant: entity that is onboarded and has a Gaia-X Participant Credential. A Participant can take on one or more of the following roles: Provider, Consumer, and Operator.

Provider: a Provider operates Resources in the Gaia-X Ecosystem and offers them as services through Gaia-X Service Offering credentials. For any such service, the Gaia-X Provider defines the Service Offering, including terms and conditions as well as technical policies. Furthermore, it provides the Service Instance, which includes a Credential and associated policies. A Gaia-X Provider is responsible for conformity to the claims made. If third-party data, services or infrastructure are part of the service offerings, the Gaia-X Provider can make those resources available (e.g., through Service Composition) but remains responsible and shall ensure coverage through appropriate back-to-back coverage.

Trusted Service Operator (TSO): Trusted Service Operators (TSO) are Gaia-X Providers that have been approved by the ecosystem governance authority to authoritatively provide one or more services to the ecosystem. There can be one or more Trusted Service Operators for a given type of service, e.g., a catalogue service. In that sense, other ecosystem Participants will trust this operator for this designated set of services.

WARNING: Do not mix Trusted Service Operators with Trust Service Providers (TSP): The first one (TSO) provides services you can trust, the last one (TSP) provides core elements of trust (in the form of verifiable credentials) for the ecosystem, e.g., identity or compliance credentials. See the Model Core later in this section.

Consumer: A Consumer is a Participant who searches Service Offerings and consumes Service Instances in the Gaia-X Ecosystem to enable digital offerings for End-Users.

Governance Authority: an ecosystem or data space Governance Authority (GA) is the body of a particular data space or ecosystem, consisting of participants, that is committed to the governance framework for the data space or ecosystem, and is responsible for developing, maintaining, operating and enforcing the governance framework (source: DSSC Glossary)

Conformity assessment: demonstration that specified requirements are fulfilled (source: ISO/IEC 17000:2020)

Object of conformity assessment: entity to which specified requirements apply (source ISO/IEC 17000:2020)

A Conformity Assessment Scheme is a set of rules and procedures that describes the objects of conformity assessment, identifies the specified requirements and provides the methodology for performing conformity assessment (source ISO/IEC 17000:2020)

Attestation: issue of a statement, based on a decision that fulfilment of specified requirements (5.1) has been demonstrated (source ISO/IEC 17000:2020)

Declaration: first-party attestation (source:ISO/IEC 17000:2020)

Certification: third-party attestation related to an object of conformity assessment, with the exception of accreditation (source ISO/IEC 17000:2020)

Accreditation: third-party attestation related to a conformity assessment body, conveying formal demonstration of its competence, impartiality and consistent operation in performing specific conformity assessment activities (source ISO/IEC 17000:2020)

Validation: confirmation of plausibility for a specific intended use or application through the provision of objective evidence that specified requirements have been fulfilled (source ISO/IEC 17000:2020)

Verification: confirmation of truthfulness through the provision of objective evidence that specified requirements have been fulfilled (source [ISO/IEC 17000:2020])(https://www.iso.org/obp/ui/#iso:std:iso-iec:17000:ed-2:v2:en:term:6.6)

Conformity Assessment Body (CAB): a Conformity Assessment Body (CAB) is a body that performs conformity assessment activities, excluding accreditation. Source: ISO/IEC 17000:2020.

Trust Service Provider (TSP): a Trust Service Provider is an entity (not necessarily a Participant) approved by the Governance Authority to authoritatively issue verifiable credentials for a given scope and purpose

• is itself identified by a Trusted Digital Identity
• issues (verifiable) credentials/certificates
• some TSPs act as Trusted Identity Providers and issue digital identities in this capacity
• in case a Conformity Assessment Body (CAB) is capable of issuing verifiable credentials for a given scope and purpose, it also qualifies as a TSP
• TSP may use validation-by-code

Notary: Notaries are entities (not necessarily a Participant) approved by the Governance Authority, which perform validation based on objective evidence from Trusted Data Sources, digitalizing an assessment previously made. The Notaries are converting “non-machine-readable” proofs into “machine-readable” proofs, i.e., verifiable credentials.

DUA Notary: A Data Usage Agreement (DUA) Notary is a specialization of a Notary validating the existence of a legally binding (e.g., signed by both parties, not revoked) Data Usage Agreement (DUA) between a Data Producer and a Data Consumer.

Data Producers have to submit a DUA to a DUA Notary; Data Consumers then may (or, if an ecosystem Governance Authority mandates it, have to) check with the respective DUA Notary before a data access whether the DUA is still valid. See Chapter 5 for more details.

Issuer: a role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. (source W3C, Verifiable Credentials Data Model v2.0)

A Conformity Assessment Scheme is a set of rules and procedures that describes the objects of conformity assessment, identifies the specified requirements and provides the methodology for performing conformity assessment (source ISO/IEC 17000:2020)

The Conformity Assessment Scheme generates Label/Criteria based on the following conformity rules:

• List of permissible standards
• Technically verifiable attributes (e.g., GLEIF)
• Rulesets

A Label is a machine-readable, structured and signed document issued by the ecosystem-accredited Compliance services in case of a valid verification and validation of the criteria for a specific assessment scheme (source: generalisation from the Gaia-X Compliance Document). A label collects a set of criteria.

Note: The criteria for Gaia-X Labels are defined in the Gaia-X Compliance Document.

Label / Criterion is validated by the following validation methods:

• Self-declaration
• Validation by code
• Conformity Assessment Body
• Existing credential/certificate

Evidence can be included by an issuer to provide the verifier with additional supporting information in a verifiable credential. This could be used by the verifier to establish the confidence with which it relies on the claims in the verifiable credential. It is expected that the credentials issued by the notaries contain the evidence of the validation process. (source: W3C Verifiable Credentials Data Model v2.0)

A Trusted Data Source is a source of the information used by the issuer to validate attestations. Notaries perform validations and issue attestations based on objective evidences from Trusted Data sources. The accepted Trusted Data Source categories and Notaries are determined within the Gaia-X Compliance document, while the detailed list of valid Trusted Data Sources and Notaries resides in the Gaia-X Registry.

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.4.4 Model for Federated Ecosystems¶

The Gaia-X Trust Framework establishes the foundation for interoperable trust across different ecosystems and domains. It enables ecosystems to federate by adhering to Gaia-X technical compatibility and by accepting a shared set of rules and associated Trust Service Providers for defined scopes and purposes.

As a mechanism for federation between two ecosystems, the governance authority of Ecosystem A may choose to recognize Ecosystem B’s membership credential as valid proof for onboarding into Ecosystem A.

4.5 Cross-Ecosystem Interoperability¶

Cross-ecosystems interoperability can be defined as “the ability of participants to seamlessly access and/or exchange data across two or more ecosystems. 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 v2.0).

A common semantic framework for describing participants, the services offered within an ecosystem, and for expressing policies is essential. Interoperable rulebooks, characterized by a commonly identified set of rules and mutually recognized Trust Service Providers, serve as additional 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 modularized 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.6 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.7 Services and Service Composition¶

4.7.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.8 Policies¶

4.8.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 Compliance Document defines the Gaia-X Policies for Service Offerings. They cover, for example, privacy or cybersecurity policies and are expressed indirectly as attributes of the Resources, Service Offerings, and Service Instances. The specific Policies have to be in line with the general Policies defined by Gaia-X.

4.8.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 the most complicated user scenario, with multiple providers, consumers, federators, data intermediaries, data subjects, business legal representatives, employer/employee 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.8.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.8.4 Policy Decision Point (PDP)¶

4.8.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.8.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.8.5 Rights Delegation¶

The rights are delegated based on the types of credentials and their usage.
The Party Credential is based upon the Verifiable Credentials Data Model v2.0 and is the basis for all IAA Parties such as Natural Persons, Services, Legal Persons, etc. The general purpose Party Credential can be extended into specialised credentials, for example:

• Private Party Credential: The Party Credentials containing PII are not considered to be published and reachable via their id to everybody, 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, with the purpose to entitle 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 organization/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 array 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 newer issuance datetime.
• active only if none of the above.

For more details, refer to the ICAM document.

4.9 Ecosystem Trust Functions¶

In addition to the core elements, trust frameworks typically contain additional 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/element

4.9.1 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 the 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, and
• semantic match

These indexes are designed to be utilized 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 as an Appendix to the document. (see Appendices - Trust Indexes)

4.10 Data Space Architecture using the Gaia-X Trust Framework¶

Data Spaces can leverage the Gaia-X Trust Framework to onboard participants by verifying compliance with their Data Space Rulebook and issuing corresponding proofs of membership 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.10 - Data Space architecture enabled by the Gaia-X Trust Framework