8. Technical recommendations¶
The standards, technologies and practices described in this chapter are relevant to Gaia-X technical compatibility but are not part of the mandatory compatibility criteria defined by this version of the specification. Mandatory compatibility criteria are specified in the Verifiable Credential compatibility, Verifiable Presentation compatibility and Extension compatibility chapters.
The fact that an item is not part of the mandatory compatibility criteria defined by this release does not determine its applicability or normative status in other Gaia-X contexts. Other Gaia-X specifications or ecosystem-specific profiles may define requirements concerning some of these items for particular services or use cases. Future versions of this specification may extend the set of mandatory compatibility criteria accordingly.
8.1 OID4VC¶
OID4VC may be used to standardise interactions between issuers, holders, wallets and verifiers.
OID4VC is particularly relevant to interoperability of credential issuance, presentation and verification flows beyond static credential validation. It is used by the EUDI (European Digital Identity) wallet and the forthcoming European Business Wallet (EUBW).
8.2 ODRL¶
ODRL is used to express permissions, prohibitions, or obligations. It is relevant for data exchange or service interactions where it may be used to specify (participant level) access and usage policies and ecosystem-specific governance rules.
The Gaia-X Architecture supports the use of ODRL for the automated processing of Data Licence constraints, in combination with an ontology defined by the ecosystem (Architecture Document 3.1, 6.8.3 ODRL). The Data Exchange Document further specifies its use for usage policies (25.07, 7 Policies). ODRL-based policy conformance is not assessed by the compatibility criteria defined in this version of the specification.
8.3 Rego¶
Rego may be used as a declarative policy language for expressing executable policy rules. Contrary to ODRL, there exist generic policy execution engines based on Rego (e.g., the CNCF Open Policy Agent, OPA).
It is not prescribed by the mandatory compatibility baseline defined in this specification, but it can be useful for automated policy evaluation in ecosystem-specific extensions and other automated policy-processing scenarios. Even though Rego policies can be evaluated by policy decision engines (see above), this recommendation concerns the policy language only and does not prescribe any particular execution or evaluation engine.
8.4 DCAT¶
DCAT 3 supports catalogue interoperability, data (product) descriptions, discovery and metadata exchange.
The Gaia-X Architecture Document identifies DCAT 3 as a relevant standard for Data Product descriptions and catalogue interoperability (3.1, 6.8.2 DCAT), while the Data Exchange Document covers its use for data product cataloguing (25.07, 5 Data Products Catalogue). Catalogue conformance to DCAT 3 is not assessed by the compatibility criteria defined in this release.
8.5 Key-status endpoints¶
Implementations should provide a jwks_uri and status endpoints so that verifiers can fetch current keys, confirm key rotation, and check revocation before authorising access.
The current mandatory compatibility criteria require only the publication of key material — see VC-2.3. Key rotation and revocation status are not checked.
Source: ICAM Document 25.11, 4.4.1 Verification Method (JSON Web Key).
8.6 Presentation lifecycle: short-lived, challenge-bound presentations¶
A Verifiable Presentation should be extremely short-lived and bound to a challenge provided by the verifier, to mitigate replay of previously captured presentations.
Neither the lifetime of a presentation nor the binding of a challenge can be established from the presentation alone: what counts as short-lived, and whether the challenge was genuinely issued by the verifier for that exchange, are judgements about the exchange in which the presentation was used. The requirement is therefore stated as a recommendation, and the mandatory presentation compatibility criteria are those of Verifiable Presentation compatibility. An ecosystem profile may make it binding for its own exchanges.
Source: W3C Verifiable Credentials Data Model v2.0. Adopted by Architecture Document 3.1, 6.6 Gaia-X Credential Format; ICAM Document 25.11, 5.5 Verifiable Presentations.
8.7 Policy reasoning engine standards stack¶
Where a policy reasoning engine is used to compare provider-set policies against consumer usage intentions, the Gaia-X deliverables specify a standards stack comprising W3C ODRL for policy expression, W3C Verifiable Credentials, JSON Path for credential evaluation, RDF for policy representation and SPARQL for querying RDF triples. This standards stack is not part of the mandatory compatibility criteria defined in this version of the specification.
A non-normative open-source reference implementation of the Gaia-X ODRL profile and policy reasoning tooling is available from Gaia-X Lab.
Source: Data Exchange Document 25.07, 7 Policies; Architecture Document 3.1, 4.9 Policies.
8.8 eIDAS-qualified signatures¶
Recognition of eIDAS-qualified electronic signatures, under Regulation (EU) No 910/2014 as amended, may be required by specific ecosystems or jurisdictions.
Recognition is a governance decision and cannot be established by an automated tool alone; it is outside the compatibility criteria.
Source: ICAM Document 25.11, 4.5 eIDAS Integration.
8.9 ISO/IEC 27001¶
Information security management certification may be required of trust service operators by an ecosystem governance authority. It is an organisational requirement, outside the technical compatibility layer.
Source: Architecture Document 3.1, 6.9.1 Trusted Service Operators.
8.10 Standards and vocabularies covered elsewhere in this specification¶
Standards that are already covered by the compatibility criteria, including SHACL, OWL and JSON-LD, are described in Annex and are not repeated as technical recommendations in this chapter.
The current mandatory credential compatibility criteria do not require the use of the Gaia-X Ontology. By design, criteria are (ecosystem) rule agnostic and, therefore, ecosystem-neutral: a credential is checked against the ontology referenced by its JSON-LD context. The Gaia-X Ontology remains the preferred vocabulary for Gaia-X-specific concepts and, currently, is the only ontology available and implemented for expressing cross-ecosystem trust propositions. Ecosystem-specific (trust) profiles may require its use.
CAP is used in this specification as the vocabulary for expressing the cap:Certification defined in Proof of compatibility. See Architecture Document 3.1, 6.8.4 CAP.