Skip to content

2. Introduction

2.1 Gaia-X technical compatibility

Gaia-X technical compatibility provides a common technical baseline supporting interoperable trust mechanisms within and across digital ecosystems.

This specification defines the technical requirements and compatibility criteria applicable to the artefacts and interfaces covered by this release. These requirements build on the Gaia-X Trust Framework and Trust Protocol architecture and on the technical specifications developed by the relevant Gaia-X Working Groups.

2.2 Purpose of this specification

This document defines the Gaia-X Technical Compatibility Specification. It establishes a common technical baseline and the criteria for assessing conformity with that baseline.

A Technical Compatibility Kit (TCK) provides the means to assess conformity with the requirements of a technical compatibility specification. Different TCK implementations may use different software components and testing approaches and may be provided by Gaia-X or by other parties. Conformity is assessed against the requirements and compatibility criteria defined by this specification, independently of the TCK implementation used.

This release focuses on compatibility criteria for:

  • Verifiable Credentials;
  • Verifiable Presentations; and
  • ecosystem-specific extensions.

The specification is intended to support interoperability by defining common requirements for credential formats, identity and verification mechanisms, semantic validation and the integration of ecosystem-specific extensions.

2.3 Specification basis

The requirements in this specification are derived primarily from the following Gaia-X specifications and technical artefacts:

  • Gaia-X Architecture Document;
  • Identity, Credential and Access Management (ICAM) Document;
  • Data Exchange Document; and
  • Gaia-X Ontology.

Other Gaia-X specifications and technical artefacts are referenced where relevant.

These sources provide the architectural and technical basis from which the compatibility requirements defined in this specification are derived. External standards adopted or referenced by Gaia-X are identified together with the applicable requirements.

2.4 Scope and evolution

This release establishes a core technical compatibility baseline centred on Verifiable Credentials, Verifiable Presentations and ecosystem-specific extensions.

The specification is designed to evolve modularly. Future releases may introduce additional compatibility areas and criteria as Gaia-X technical specifications and relevant standards evolve.

In addition, API route conventions for credential exchange and querying, or registry specifications (e.g. revocation registries, trust anchor registries, schema registries), are not yet covered by the current scope. In the meantime, we inform the reader that many relevant elements bridging technical compatibility and Gaia-X compliance are already available in the Architecture Document, such as the description of the Compliance Engine as the main GXDCH entry point, or concrete Registry endpoints such as /api/trustAnchor and /api/trusted-issuers. We are currently working on identifying the areas between the two documents that still need to be covered, with the aim of addressing them in future releases of this specification.

Technical compatibility requirements defined by this specification are independent of their implementation in any particular TCK, test tool or software component.

2.5 Reading this document

Throughout this document, the verb “shall” indicates a requirement to be strictly followed in order to conform to this specification; “should” indicates a recommendation; “may” indicates a permission; and “can” indicates a possibility or capability. The formal interpretation of these terms is provided in Guiding principles.

Each compatibility criterion also identifies the applicable verification method:

  • Automated verification: conformity can be established entirely through machine-executable checks;
  • Human verification: conformity requires judgement, evidence assessment or a governance decision that cannot be fully automated;
  • Mixed verification: conformity combines machine-executable checks with human assessment.

These classifications describe how conformity with a requirement can be established; they do not alter the normative status of the requirement itself.

2.6 Structure of the Technical Compatibility Specification

The Technical Compatibility Specification is structured around a core technical baseline and a set of compatibility areas containing applicable requirements and criteria. It also includes technical recommendations and provisions for conformity evidence and reporting.

Technical Compatibility Specification
│
├── Core Baseline
│   ├── JWT VC signature verification
│   ├── did:web resolution and DID document validation
│   ├── VC Data Model 2.0 validation (SHACL / ontology)
│   ├── JSON-LD validity and ontology resolution (OWL + JSON-LD)
│   └── Ontology conformance (terms, rdfs:domain, rdfs:range)
│
├── Compatibility Areas
│   ├── Verifiable Credential compatibility      (VC-1 … VC-6)
│   ├── Verifiable Presentation compatibility    (VP-1 … VP-3)
│   └── Extension compatibility                  (EXT-1 … EXT-5)
│
├── Technical Recommendations
│   ├── OID4VC flow testing
│   ├── ODRL policy validation
│   ├── Rego rule execution
│   └── DCAT catalogue validation
│
└── Conformity evidence and reporting
    ├── Human-readable report
    ├── Machine-readable report
    └── Proof of Compatibility
        (cap:Certification in a signed VC-JWT)

Each compatibility area is designated by a unique identifier consisting solely of letters such as VC, VP, and EXT.
Each compatibility area contains one or more area groups designated by a numeral unique within the respective compatibility area such as VC-1, or EXT-4.
Each compatibility area group contains one or more testable criteria designated by a unique numeral unique withing a specific compatibility area group.

This ensures that every single criterion can be unambigously identified by identifiers of the following structure:

<compatibility-area-identifier> - <compability-area-group-number> . <criterion-number>

Examples - VC-2.3 refers to “Publication of key material” - VP-3.1 refers to “Compatibility of every contained credential”. Here, compatibility area VP-3 only contains a single criterion, namele VP-3.1. - EXT-4.2 refers to “Compatibility of the returned credential“

Each criterion identifies - the requirement to be assessed - the applicable verification method, and - relevant source(s) or reference(s).

The structure above reflects the compatibility areas covered by the current release of this specification.

Suggest a modification