Mechanisms

The transition from requirements to mechanisms connects the requirements for secure data transfer to a small, standards‑based set of candidate mechanisms that can satisfy those requirements in a vendor‑neutral and interoperable manner.

Approach

The initial list of candidate mechanisms was identified by reviewing existing, widely used specifications and reference architectures that already support secure data exchange in smart‑city and data‑space contexts. The selection was limited to mechanisms addressing data in transit and aligned with the scope of MIM6.

Identified key source documents that were used: LDT Toolbox (D05.02) Identifies transport protection via TLS and authenticated, secure access using OAuth 2.0 and OpenID Connect (OIDC). Dataspace Protocol (DSP) Identifies TLS for transport protection and OAuth 2.0 with signed JWTs for token‑based access control. Eclipse Dataspace Components (EDC) Implements DSP in the control plane; for data in transit, relies on TLS and OAuth 2.0 with signed JWTs. Gaia‑X Architecture / Trust Framework (v25.05) Identifies OpenID Connect for Verifiable Credentials (OIDC4VCI / OIDC4VP) for authenticated exchanges; no additional transport protocol specified.

Candidate mechanisms (summary mapping)

Table 8, Requirements to mechanisms (high‑level)

Requirement ID : Candidate Mechanism(s) R1 : M1.2 R2 : M1.3, M1.4 R3 : M1.1, M1.2, M1.3 R4 : M1.2 R5 : M1.1 R6 : M1.3, M1.4

Note: The table shows coverage relationships only.

Mechanism candidate (M1)

M1.1: The Transport Layer Security (TLS) Protocol, Version 1.3 M1.2: The OAuth 2.0 Authorization Framework M1.3: OpenID Connect 1.0, Identity layer for authentication on OAuth 2.0 M1.4: OIDC4VCI / OIDC4VP, OpenID for Verifiable Credential Issuance and Presentations