7. Enabling and Federation Services

Enabling Services facilitate the operation of ecosystems. There are multiple technologies, products and implementations of each of the enabling services available. This document defines the components, the interactions among them and specific requirements towards Gaia-X.

Enabling services operated under the specific rule of ecosystem governance are defined as “Federation Services”.

7.1 Wizard Service

UI to sign Verifiable Credentials in a Verifiable Presentation on the client side. Calling the Gaia-X Compliance Service is integrated with the Wizard, making it possible to obtain Gaia-X Compliant Credentials by directly using this tool. Depending on the implementation, a Wizard can support signing with a hardware module via PKCS#11 or other like Web eID.

7.2 Credential Manager

Application that allows the user to store their Credentials and present them to third parties when needed. This is also sometimes called an Agent, CredentialRegistry or IdentityHub.

7.3 Federated Catalogues

The goal of the Federated Catalogue is to:

• enable Consumers to find best-matching offerings and to monitor them for relevant changes in the offerings
• enable Producers to promote their offerings while keeping full control of the level of visibility and privacy of their offerings.
• avoid a gravity effect with a lock-out and lock-in effect around a handful of catalogue instances.

7.3.1 Publication / Subscription service

For the Gaia-X Catalogues to be notified about new, updated, revoked credentials, a functionally speaking central Publication / Subscription service (pubsub service) must be deployed via the GXDCH instances.

The exact software stack to create and deploy such a service will be detailed in further technical specifications.

It is expected that the pubsub service will have different implementations over time from a distributed service during the pilot phase - Apache Kafka or similar - to a decentralized one - a Gaia-X consortium blockchain like for the Gaia-X Registry.

The deployed solutions have to accommodate for convenience from a user point of view and for security from a federator point of view.

The credential holders are responsible for directly - via their agents or wallets - or indirectly - via a wizard, a catalogue or other - pushing in the pubsub service either the credentials or the credentials’ IDs they wish to publish.

If the holder does not want to make their credential available to the wider community, the holder can decide to use another mechanism or not publish it at all.

If the holder publishes a credential, the credential is directly made available to the subscribers of the pubsub service.

If the holder publishes a credential’s ID, the subscribers of the pubsub services have to resolve the ID and request access to the holder for the credential.
The service storing the credential - agent or wallet - is from a functional point of view a Policy Decision Point¹ leaving full control of the credential access to the holder.

7.3.2 Catalogue service

The implementation of the catalogue can vary from one catalogue owner to another and offers different user experiences.

The requirement to be listed in the Gaia-X Registry as a valid Gaia-X Catalogue is to keep the network of Gaia-X Catalogues up to date by publishing in the pubsub service the credential ID of the credential being created, updated or revoked.

A future testbed will be implemented to perform dynamic validation of the above behavior.

7.3.3 Retention

To have a basic data curation mechanism, the retention period in the pubsub service is one-year maximum.

It means that a holder, to have their credentials discoverable, should publish them at least once per year, even if the credentials have not changed.

7.3.4 Snapshot

To speed up the onboarding of new catalogue instances, it is expected that timestamped snapshots of the pubsub service data are made and stored publicly via IPFS. The URIs of the snapshots are available via the Gaia-X Registry.

7.3.5 Trust Indexes

While “Trust” is used as a building block in every Data Space and Federation related document, there are two main challenges:

• There is no unique definition of Trust; Trust is context-dependent
• The market has and will always move faster than the rules

While the Gaia-X Policy Rules provide a baseline translating European values into objectives and measurable criteria, Data Spaces and Federations need to extend this baseline for their own market, vertical domain and local regulations.

In this context, the Trust Indexes are a means to measure trust interoperability across dataspaces and federations adopting and extending the Gaia-X Policy Rules.

Four indexes are proposed:

• Veracity
• Transparency
• Composability
• Semantic Match

7.3.5.1 Veracity

The Veracity index is a function of:

• for a given claim, the length of the signing key chain (root → intermediate → intermediate → … → leaf)

flowchart LR
    keychain1[root]
    keychain2[intermediate]
    keychain3[...]
    keychain4[leaf]

    keychain1 --> keychain2 --> keychain3 --> keychain4

• for a given claim, the number of signatures on that claim (root → … → leaf ← … ← root)

flowchart LR
    keychain1[root #1]
    keychain2[intermediate #1]
    keychain3[root #2]
    keychain4[intermediate #2]
    keychain5[leaf]

    keychain1 --> keychain2 --> keychain5
    keychain3 --> keychain4 --> keychain5

7.3.5.2 Transparency

The Transparency index is a function of:

• the number of exposed optional properties of an object versus mandatory - in terms of the Gaia-X Policy Rules - properties of the same object. This ratio is always greater or equal to 1.
• the shape of the graph formed by the linked claims, measuring its eccentricity and depth.

7.3.5.3 Composability

The Composability index is a function of two or more service descriptions, computing:

• the capacity of those services to be technically composed together, e.g.: software stack, compute, network and storage characteristics, plugin, and extension configurations, …

This index is computed, for example, by instances of the Federated Catalogues, by analysing and comparing the characteristics of several service descriptions.

This index can be decomposed for each service description into several sub-functions:

• the level of detail of the Software Bill of Material
• the list of known vulnerabilities such as the ones listed on the National Vulnerability Database.
• Intellectual Property rights via the analysis of the licenses and copyrights.
• the level of stickiness or adherence to specific known closed services
• the level of readiness for lift-and-shift migration.

7.3.5.4 Semantic Match

The Semantic Match index is a function of:

• the use of recommended vocabularies (Data Privacy Vocabulary, ODRL, …)
• the unsupervised classification of objects based on their properties
• Natural Language Processing and Large Language Model analysis from and to Domain Specific Language (DSL)
• Structured metadata information embedded in unstructured data containers (PDF/A-3a, …)

7.4 Notarization service(s)

Notarization services are built to support the validation claims to verifiable credentials by allowing to review attestations by “Trusted Data Sources” and issuance of a verifiable credential once all conditions of the policies are met (e.g. the compliance service of the GXDCH uses the “Gaia-X registryNumber notarization API” to validate the company registration number).

A more generic set of services is provided by the Eclipse XFSC project which provides components to define a complex workflow and manage the chain of attribute validations and issuance of the VC through the NOT, TSA and WFA components.

7.5 Data Exchange Services

Data product usage in Gaia-X is enabled by a set of Data Exchange Services that are realized by each Participant and can be supported as Federation Services. Not all Data Exchange Services are mandatory.

1. Authentication (mandatory) is essential to connect two Participants. Authentication is provided by The Identities and Trust Framework: Identities provide general information on the Participant, and the Trust Framework appends additional claims, like verified location, or verified application of other standards or regulations.

2. Policy negotiation and contracting (mandatory) includes the ability to negotiate access and usage policies between two parties. This should be a sequence between the parties, but a contracting service can support here when one or multiple parties do not have the technical abilities for this. ODRL is used to support contracting as (a) it provides interoperability (all parties must be able to understand the policies to enforce them later) and (b) it enables computerised policy enforcement during the transaction.

3. A catalogue (mandatory) provides mechanisms to publish Data Product Descriptions (metadata) and support search or query of the Descriptions. A catalogue may be realized as a centralized or decentralized service, but the capability can also be realized as a distributed functionality.

4. Vocabularies (optional) provides additional metadata to the Data Product Descriptions. The Descriptions should contain a limited amount of information as a common denominator but must be extensible with vocabularies from different (business or technical) domains.

5. Observability abilities (optional) - logging and audit data - are required to provide an auditable framework for transactions.

6. Data Exchange protocols are required to exchange data between Participants and enable Data Usage. Data exchanges are realized on a peer-to-peer basis. Gaia-X does not promote any technical protocol - the actual protocol must be agreed between the parties during the contracting phase.

Detailed descriptions of these services are provided in the Gaia-X Data Exchange Services Specifications document.

7.5.1 Auditing

7.5.1.1 Data Contract Services

Data Contract Services act as a broker of data delivery contracts between Data Providers and Data Consumers. They facilitate and enable agreements about data deliveries.

7.5.1.2 Data Exchange Logging Services

Data Exchange Logging Services provide evidence that data has been (a) submitted and (b) received and (c) rules and obligations (Data Usage Policies) were enforced or violated. This supports the clarification of operational issues, but also eventually the clarification of fraudulent transactions. The Data Provider can track that, how, and what data was provided, and the consumer can be notified. A Data Consumer can track that data was received or not received. Additionally, the Data Consumer can track and provide evidence on the enforcement of data usage policies or violation of data usage policies.