GXFS and the XFSC Toolbox

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:

Authentication/Authorisation (AAU)

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 (TSA)

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.

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.

Catalogue (CAT)

A Catalogue stores Self-Descriptions both as stand-alone and as aggregated in a graph data structure. The Self-Description Storage contains the raw published Self-Description files in the JSON-LD(JavaScript Object Notation for Linked Data) format, together with additional lifecycle metadata.

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.

Self-Descriptions

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
• Technology-agnostic
• 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.

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.

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. 

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.

Orchestration

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.

API Management

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.

Workflow Engine

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.