Skip to content

10. Annex A — Technical concepts and standards

(informative)

This annex collects technical concepts, standards and (other) specifications referenced by this specification. Normative requirements and mandatory compatibility criteria are defined in the Verifiable Credential compatibility, Verifiable Presentation compatibility and Extension compatibility chapters. Standards, technologies and practices relevant to Gaia-X technical compatibility but not assessed by the compatibility criteria defined by this version are described in Technical recommendations.

10.1 A.1 Identity and identifiers

10.1.1 A.1.1 Decentralized Identifier (DID)

Globally unique identifier defined by W3C DID Core that enables decentralised digital identity and can be resolved to a DID document containing verification methods and related metadata.

Source: W3C Decentralized Identifiers (DIDs) v1.0

10.1.2 A.1.2 did:web

DID method that uses web infrastructure (e.g., publicly accessible endpoints delivering files) and HTTPS-based resolution to make a DID document available which is – more or less strictly – bound to an organisation.

Referenced by: VC-2.1 and VP-1.3.

10.1.3 A.1.3 JSON Web Key (JWK)

JSON representation of cryptographic keys defined in IETF RFC 7517, used in this specification for the publication and resolution of verification key material.

The compatibility criteria use publicKeyJwk or jwks_uri to make verification key material available.

Source: IETF RFC 7517

Referenced by: VC-1.3, VC-2.3, and VP-1.3.

10.1.4 A.1.4 JSON Web Signature (JWS) and JSON Web Algorithms (JWA)

Signature format and algorithm registry used to construct and verify cryptographic proofs for credentials and presentations.

The alg property identifies the signature algorithm, using values defined in IETF RFC 7518.

Source: IETF RFC 7515; IETF RFC 7518

Referenced by: VC-1.1, VC-1.2, VC-1.4, VP-1.1, VP-1.2, , and VP-1.4

10.2 A.2 Credential formats

10.2.1 A.2.1 Verifiable Credential (VC)

Tamper-evident set of claims made by an issuer, cryptographically signed and machine-verifiable, conforming to the W3C Verifiable Credentials Data Model.

Source: W3C Verifiable Credentials Data Model v2.0

10.2.2 A.2.2 Verifiable Presentation (VP)

information aggregated from one or more verifiable credentials, packaged by a holder in such a way that allows the issuer of the information to be verified.

Source: W3C Verifiable Credentials Data Model v2.0

10.2.3 A.2.3 W3C Verifiable Credentials Data Model 2.0

The W3C Verifiable Credentials Data Model 2.0 defines the data model used by the Verifiable Credential and Verifiable Presentation compatibility criteria in this specification.

Referenced by: VC-3.1.

10.2.4 A.2.4 VC-JWT

In this specification, VC-JWT denotes the JWT-based encoding used for Verifiable Credentials and Verifiable Presentations, with cryptographic protection provided through JSON Web Signature (JWS). The applicable compatibility criteria define the required encoding, signature, key material and validity checks.

Referenced by: VC-1.1, VP-1.1, EXT-3.2.

Source: IETF RFC 7519 (JSON Web Token); IETF RFC 7515 (JSON Web Signature); W3C Verifiable Credentials Data Model v2.0.

10.3 A.3 Semantics and validation

10.3.1 A.3.1 JSON-LD

JSON-LD provides the linked-data representation used by credential compatibility criteria for context-based interpretation and semantic validation.

Referenced by: VC-4.1, VC-5.1.

10.3.2 A.3.2 Shapes Graph

Set of SHACL shapes against which a data graph (e.g. a credential) is validated for structural conformance.

Where an applicable shapes graph is available, structural conformance against that graph is assessed by validating the credential data graph in accordance with the SHACL specification.

Source: W3C Shapes Constraint Language (SHACL)

10.3.3 A.3.3 SHACL

The Shapes Constraint Language (SHACL) is used for structural validation of credentials expressed as RDF data graphs. Where a shapes graph applicable to the credential is available, the credential is validated against it in accordance with SHACL. Where no applicable shapes graph is available, the corresponding compatibility criterion is not applicable and semantic conformance is established through the ontology-based criteria.

Referenced by: VC-3.2.

10.3.4 A.3.4 OWL ontology

In this specification, the vocabulary used by a credential is represented by an OWL ontology that is resolved and parsed under VC-5 and used for semantic validation under VC-6.

The ontology supplies the term declarations and, where present, the rdfs:domain and rdfs:range information against which the credential’s asserted triples are checked under VC-6. These are applied as validation constraints rather than as RDFS entailment.

Referenced by: VC-5.2, VC-6.1 to VC-6.3.

10.3.5 A.3.5 Referenced ontology

The current mandatory credential compatibility criteria do not require the use of the Gaia-X Ontology. A credential is assessed against the ontology referenced by its JSON-LD context. The applicable requirements for resolution, parsing and semantic validation of that ontology are defined in VC-5 and VC-6.

Referenced by: VC-5.1, VC-5.2, VC-6.1 to VC-6.3.

10.3.6 A.3.6 HTTP content negotiation

Mechanism defined in IETF RFC 9110 by which a client indicates, through request header fields such as Accept, which representation of a resource it prefers, and the server selects the representation it returns. A single IRI can thus serve several representations of the same resource, for example the JSON-LD context, the OWL ontology and the SHACL shapes graph of an ontology.

The shapes graph applicable to a credential is requested from the IRI of the referenced ontology with the Accept header set to text/turtle.

Source: IETF RFC 9110 (HTTP Semantics), Section 12; Gaia-X Ontology, Using through w3id.org

Referenced by: VC-3.2.

10.4 A.4 Registries

10.4.1 A.4.1 registry

In the Gaia-X Architecture, a registry is a trust service component acting as a source of truth for ecosystem trust artefacts such as shapes, trust anchors, approved trust service providers and revocation information.

A registry is not required for credential compatibility: the criteria in Verifiable Credential compatibility resolve keys, contexts and ontologies directly from the credential, without consulting a registry.

10.4.2 A.4.2 meta-registry

Cross-ecosystem registry that collects and publishes the ecosystem trust profiles of participating ecosystems. Each ecosystem trust profile consists of a set of trust propositions.

Referenced by: EXT-1.1 to EXT-1.3, EXT-5.1

10.4.3 A.4.3 Trust profile record applicable to an extension

Meta-Registry record applicable to an extension through which the relevant trust propositions and extension-specific technical information are made discoverable. In this specification, the record carries the information required by EXT-1 and is used to declare the addressing information required by EXT-2.2 and to reference the Proof of Compatibility required by EXT-5.1.

Referenced by: EXT-1.1 to EXT-1.3, EXT-2.2, EXT-5.1

See also ecosystem trust profile in Annex B.

10.5 A.5 Compatibility

10.5.1 A.5.1 technical compatibility

Conformance of an artefact, interface or implementation with a common technical baseline of requirements and compatibility criteria supporting interoperable trust mechanisms within and across digital ecosystems.

Technical compatibility is defined by the applicable technical compatibility specification. A Technical Compatibility Kit may provide means to assess conformity with that specification, independently of the particular TCK implementation used.

10.5.2 A.5.2 Eclipse Conformity Assessment Policy and Credential Profile (CAP)

Ontology for expressing conformity assessment information. In this specification, CAP is used as the vocabulary for the cap:Certification representing a Proof of Compatibility.

Source: Eclipse Dataspace Working Group, Conformity Assessment Profile (CAP) Ontology; Architecture Document 3.1, 6.8.4 CAP.

Referenced by: Proof of compatibility.

10.6 A.6 References

[1] Gaia-X European Association for Data and Cloud AISBL. Gaia-X Architecture Document, Release 3.1.

[2] Gaia-X European Association for Data and Cloud AISBL. Identity, Credential and Access Management (ICAM) Document, Release 25.11, 28 November 2025.

[3] Gaia-X European Association for Data and Cloud AISBL. Data Exchange Document, Release 25.07.

[4] Data Spaces Support Centre (DSSC). DSSC Blueprint v3.0: Data Space Governance Framework / Data Space Rulebook.

[5] Gaia-X Policy Rules Committee (PRC). Geography and Domain Extension White Paper, July 2025 (available to Gaia-X members only).

[6] W3C. Verifiable Credentials Data Model v2.0. World Wide Web Consortium Recommendation.

[7] W3C. Shapes Constraint Language (SHACL). World Wide Web Consortium Recommendation.

[8] W3C. Decentralized Identifiers (DIDs) v1.0. World Wide Web Consortium Recommendation.

[9] W3C. Open Digital Rights Language (ODRL) Information Model. World Wide Web Consortium Recommendation.

[10] W3C. Data Catalog Vocabulary (DCAT), version 3. World Wide Web Consortium Recommendation.

[11] IETF. RFC 7515 — JSON Web Signature (JWS).

[12] IETF. RFC 7517 — JSON Web Key (JWK).

[13] IETF. RFC 7518 — JSON Web Algorithms (JWA).

[14] IETF. RFC 7519 — JSON Web Token (JWT).

[15] Eclipse Dataspace Working Group (EDWG). Conformity Assessment Profile (CAP) Ontology.

[16] European Union. Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation), as amended.

[17] ISO/IEC 17000:2020, Conformity assessment — Vocabulary and general principles.

[18] ISO/IEC 27001, Information security, cybersecurity and privacy protection — Information security management systems — Requirements.

[19] ISO/IEC FDIS 20151-1 Cloud computing and distributed platforms — Dataspaces Part 1: Concepts and characteristics

[20] CEN-CENELEC EN 18235-1:2026 Trusted data transactions - Part 1: Terminology, concepts and mechanisms

[21] LinkML (Linked Modeling Language) documentation, used for generation of SHACL, OWL and JSON-LD serializations of the Gaia-X Schema.

[22] Gaia-X Meta-Registry (current version). Available online.

[23] Gaia-X Lab. Open-source reference implementation of the Gaia-X ODRL profile and policy reasoning library.

[24] W3C JSON-LD 1.1

[25] W3C OWL 2 Web Ontology Language

[26] W3C RDF Schema 1.1

[27] IETF. RFC 9110 — HTTP Semantics.

[28] Gaia-X European Association for Data and Cloud AISBL. Gaia-X Ontology, development version.

Suggest a modification