Gaia-X Federation Services – what are they?
Gaia-X does not operate itself on the market to compete with market incumbents. We do not develop a company like a stand-alone cloud provider, neither do we implement data spaces collecting the data from our members. Instead, Gaia-X develops the software components necessary to sets up a federated system that inter-connects several Participants with each other, aiming to develop new services and innovative products. Such ecosystems consist of joined interconnected data and infrastructure ecosystems, aggregated in so-called Federations that are individually orchestrated and operated with the help of Federation Services.
Federations and Self-Descriptions as core concepts of GXFS
A Federation is a group of Participants that work together and collaborate on an equal level. The Federation is not owned by anyone; instead, the Participants cooperate based on joint rules. A participant of the Federation or an external service supplier is appointed to become the so-called Federator, with its role being to facilitate the coordination of the group and to provide the necessary operational Federation Services. Gaia-X Federations will be based on different industries and can consist of a large group of Participants.
Self-Descriptions are the basis for the functioning of the Federations. Put in simple terms, they are user profiles for all Participants and, where applicable, their service offerings. Participants are asked to share information about their business, their data and their service offering in their Self-Descriptions that can be verified by others in the Federation. Each Federation can manage a so-called Services Catalogue that is a repository of all Self-Descriptions offered within this Federation. The access rights are set by the Federation based on the core governance rules. It can be linked with Service Catalogues for generic public service offerings.
The GXFS Toolbox
It is important to understand that the Federation Services will not be provided by a central authority, but that each Federation will be able to use the reference open-source code of the Gaia-X Federation Services toolbox to then build apps and services that match the requirements in their respective Federation. In any case, the GXFS source code should be seen as reference implementation point to achieve inter ecosystem interoperability. The functional implementation can also be achieved with other implementations that conform with the Gaia-X technical and functional specifications. The final compliance of a Gaia-X service will anyway be verified through the aforementioned Decentralized Services, thus not allowing any possibility to modify the Federation Services open-source code to obtain a competitive advantage.
The Federator of a Federation will be tasked with providing these services. This is because requirements towards the specific tools may diverge depending on the industry in question. For instance, an Automotive Federation might have very different requirements than an Insurance Federation. Through the development of open-source code, the Participants of a Federation are enabled to develop Gaia-X conformant services, and can flexibly design the user interface in a way that’s best suited to serve a Federation’s needs.
The Gaia-X association maintains a repository of the Federation Services. Interested parties can gain access and build services based on the GXFS open-source code. Through this open-source implementation, all Participants and interested Gaia-X supporters can improve and continuously adapt the services developed under the GXFS umbrella to meet the Federations’ needs.
The following section provides additional insights into the functionalities and benefits of each Federation Service and presents how such services could be of benefit to Gaia-X users.
Work Package: Identity & Trust
Identity and Trust based on a Self-Sovereign Identity (SSI) concept enables handling of decentralised identities and digital trust establishments for identities and assets. The decentralised identity management based on w3C Verifiable Credentials and Distributed Identifier (DID) enables Gaia-X Participants to keep control over their digital identities. The following services are specified as part of the Federation Services for Identity & Trust:
Service functions enable Gaia-X Participants to authenticate users and systems in a trustworthy and decentralised self-sovereign manner.
Organisation Credential Manager (OCM)
The OCM establishes trust between the different Participants within the Gaia-X ecosystem by offering credentials to company Participants and managing credentials of the organisation.
Personal Credential Manager (PCM)
PCM acts as a user representative, securely holding the acquired distributed identity credentials and identity attributes, providing the technical means to selectively disclose the attributes for authentication and service consumption. The PCM as a Gaia-X component is used by a natural person – typically in the form of a personal wallet for a user. The PCM enables users to interact with the SSI-based ecosystem through VC’S and DID’s in a privacy-preserving way. The PCM form factors are smartphone-based applications and browser-based applications/add-ons for stationary PCs and notebooks.
Trust Services (TRU)
The Trust Services are the technical implementation to enforce policies for the usage of the decentralized and self-sovereign components of Gaia-X. The Trust Services work through cryptographic validation of the provided credentials. The Trust Services’ scope covers the technology functionalities to ensure a consistent level of trust between all Participants in Gaia-X. Further features are verification by applying standards like LD Proof Chains/Sets, establishing policy-driven trust, providing the required trust anchors, and ensuring trust chains between multiple Participants.
Work Package: Federated Catalogue
The Federated Catalogue constitutes an indexed repository of Gaia-X Self-Descriptions to enable the discovery and selection of Providers and their service offerings. The Self-Descriptions are the information given by Participants about themselves and about their services in the form of properties and claims.
The exchange format for Self-Descriptions is JSON-LD. JSON-LD uses JSON encoding to represent subject-predicate-object triples according to the W3C Resource Description Framework (RDF). The Self-Description Graph imports the Self-Descriptions from the Self-Description Storage into an aggregate data structure. This constitutes the basis for advanced query mechanisms that consider the references between and among Self-Descriptions.
Since Self-Descriptions are protected by cryptographic signatures, they are immutable and cannot be changed once published. This implies that, after any changes to a Self-Description, the Participant as the Self-Description issuer, must once again sign the Self-Description and release it as a new version.
Gaia-X Self-Descriptions express characteristics of Resources, Service Offerings and Participants that are linked to their respective Identifiers. Providers are responsible for the creation of Self-Descriptions of their Resources. In addition to self-declared Claims made by Participants about themselves or about the Service Offerings provided by them, a Self-Description may comprise verifiable credentials issued and signed by trusted parties. Such Credentials include Claims about the Provider or Resources claimed by the issuer.
Self-Descriptions in combination with trustworthy verification mechanisms empower Participants in their decision-making processes. Specifically, Self-Descriptions can be used for:
- Discovery and composition of Service Offerings in a Catalogue
- Tool-assisted evaluation, selection, integration and orchestration of Service Instances and Resources
- Enforcement, continuous validation, and trust monitoring together with Usage Policies
- Negotiation of contractual terms concerning Resources of a Service Offering and Participants
Gaia-X Self-Descriptions are characterized by the following properties:
- Machine-readable and machine-interpretable
- Adhering to a generalized schema with expressive semantics and validation rules
- Interoperable, following standards in terms of format, structure and included expressions (semantics)
- Flexible, extendible and future-proof, in that new properties can be easily added
- Navigable and referenceable from anywhere in a unique, decentralized fashion
- Accompanied by statements of proof (e.g., certificates and signatures), making them trustworthy by providing cryptographically secure verifiable information.
Work Package: Sovereign Data Exchange
Data Sovereignty Services give Participants the capability to have full self-determination of their data exchange and sharing.
Informational self-determination for all Participants includes two aspects within the data ecosystem: (1) Transparency, and (2) Control of data usage. Enabling data sovereignty when exchanging, sharing, and using data relies on fundamental functions and capabilities that are provided by Federation Services in conjunction with other mechanisms, concepts, and standards. The Data Sovereignty Services build on existing concepts of usage control that are more than traditional access control. Traditional access control typically focuses on the data access dimension but leaves aside the data processing angle. Gaia-X Data Sovereignty Services seek to expand this concept and fill existing gaps. As such, usage control is concerned with requirements that pertain to future data usage patterns (i.e., obligations), rather than data access (provisions).
Data Contract Service (DCS)
The Data Contract Service constitutes the formal data transaction initiation handshake between the data provider and the data consumer. The DCS validates the entire contract and, if the content is valid and the Participants have both successfully confirmed the contract, adds its signature and distributes the finalised Data Contract to all involved parties. The service allows for negotiation of contracts.
Data Exchange Logging (DEL)
Data Exchange Logging provides evidence that data has been submitted and received, that rules and obligations (Data Usage Policies) were enforced, and on whether these have been complied with or violated. This supports the clearing of operational issues, but also eventually the clearing of fraudulent transactions. The parties involved in the data exchange are the data provider and the consumer of the data; they both receive notifications about the transaction. Some use cases may also require access to the notifications by an eligible third party that has been agreed upon in the Data Contract.
Work Package: Compliance
Gaia-X defines a compliance framework that manifests itself in the form of a Code of Conduct, third party certifications/attestations, or through signing of Terms and Conditions. The compliance framework is made up of rules (e.g., for encryption, data protection standards, and interoperability etc.) that Participants need to adhere to. These rules are the combination of those defined in the Policy Rules’ Document of Gaia-X, and other rules defined by the Labelling & Compliance Working Group within the Gaia-X Association (that collects input from the three key committees of the Association: DSBC – Data Space Business Committee, TC – Technical Committee and PRC – Policy Rules Committee). The main objective of the Compliance Federation Service is to provide Gaia-X users with verification of Compliance to the stated characteristics for each of the specific Service Offerings. Federation Services in the field of Compliance consist of three components:
Onboarding and Accreditation Workflow (OAW)
Ensures that all Participants, Resources and Service Offerings undergo a validation process before being added to a Catalogue. One goal of the OAW is to document the validation process and the generation of an audit trail to guarantee adherence to generally accepted practices in Conformity Assessments.
- Registration of the Gaia-X Participant: Upon successful validation, a verifiable credential (VC) for the entity will be issued to underpin the status as a registered Participant in Gaia-X. Subsequently, principals of those registered providers can register the service offerings for Gaia-X.
- Self-Description and additional evidence: to support adherence to the Gaia-X policy rules (e.g., by Codes of Conduct, third-party certifications/attestations, acceptance of Terms and Conditions) have to be provided.
- Documentation of the validation process and the generation of an audit trail to guarantee adherence to generally accepted practices in conformity assessment.
In addition to the general onboarding workflow, special functions must include:
- Monitoring of the relevant bases for Compliance
- Monitoring of updates to Service Offerings that could trigger revisions / recertifications for Compliance
- Suspension of Service Offerings
- Revocation of Service Offerings
Continuous Automated Monitoring (CAM)
Enables compliance monitoring based on Self-Descriptions mentioned above in the context of the Federated Catalogue. CAM is achieved by automatically interacting with the service-under-test, using standardised protocols and interfaces to retrieve technical evidence.
Notarisation Service (NOT)
The Notarisation Service is designed to manage notarisation requests and issue digital, legally-binding and trustworthy credentials. To issue such notarised credentials (including eIDAS signatures and public keys in the verifiable credentials format), Participants need to provide relevant legal and accreditation documents as defined in the Gaia-X Policy & Rules Compliance Framework.
Work Package: Portal & Integration
The Gaia-X Portal serves as a sample integration layer showcasing the Federation Services and providing a user-friendly access to these services. It will support the Onboarding and Accreditation of Participants, showcase service discovery and sample service orchestration and provisioning.
With the orchestration service, the GAIA-X consumer is able to start instantiating services through the portal out of the catalog search results. The orchestration provides a Life Cycle Management Engine (LCM Engine) and a standardized API for LCM services. While the former is core GAIA-X Service, the latter are managed by Service Providers. They act as an interface between the LCM Engine and the infrastructure of the different service providers.
In order to orchestrate the various GAIA-X services with their associated APIs, we will introduce an API framework to create a consistent user and developer experience for API access and lifecycle. An API gateway will ensure security (e.g. DDoS prevention) to all integrated services, including potential external connected services like authentication provider. The API portal will provide a single point of information in regard to available API services and version management. The Analytics portal will provide short and long-term statistics about usage and quality.
The workflow engine mainly serves according to the onboarding and accreditation process to approve and trace service provisioning. Additionally, it is managing the user interaction loop for user notifications. The administration mainly serves the federator to keep track of request for participation, approval of participation, managing participant interaction, assign/approve participant credentials and additionally track quality of service of Self-Descriptions which are exposed to the public via a catalog function.
Compliance Documentation Service
To show that an Federation Service fulfils all defined requirements, the provision of appropriate evidence is necessary. These evidences can be delivered in different types (e.g. specifications, concepts, test reports or certificates). The Compliance Documentation Service specifies how the fulfillment of security and privacy by design must documented by each Federation Service.