Enhancing Federated Data Trading via Trustworthy Identity and Access Management Framework

Abstract

Trustworthy Identity and Access Management (IAM) is a foundational requirement for federated data trading platforms, yet existing solutions often rely on centralized Identity Providers (IdPs), lack cross-border interoperability, and offer limited support for user-friendly authorization management. These limitations hinder secure onboarding, fine-grained access control, and regulatory compliance, especially within European Union (EU) data spaces governed by the Electronic Identification, Authentication, and Trust Services (eIDAS) 2.0 framework. This work presents a comprehensive IAM framework designed for federated data trading environments, developed within the EU-funded PISTIS project. The framework is based on Keycloak IAM and offers three major capabilities: (i) a novel IAM architecture tailored to distributed data trading scenarios; (ii) full integration of eIDAS-compliant cross-border authentication and initial support for European Digital Identity (EUDI) Wallets; and (iii) a standalone, web-based Access Policy Editor (APE) that abstracts Keycloak’s policy engine and enables non-technical users to define fine-grained, owner-driven access rules. The approach is evaluated across real-world mobility, energy, and automotive industry pilots, demonstrating its effectiveness in enhancing trust, interoperability, and usability within regulated data-sharing ecosystems.

1. Introduction

With data markets rapidly emerging as fundamental enablers of the digital economy, establishing security, trust, and regulatory compliance in cross-organizational data sharing has become a critical challenge. Federated data trading platforms, such as those envisioned in major European Union (EU) initiatives, aim to facilitate the exchange of sensitive, high-value data across national and organizational boundaries. Their success, however, hinges on the availability of robust IAM mechanisms capable of supporting heterogeneous stakeholders operating across multiple jurisdictions.

Data trading platforms are digital marketplaces that enable the secure exchange, monetization, and sharing of data assets between organizations, while enforcing privacy, access control, and regulatory compliance. In federated environments, such platforms support controlled data publication, ingestion, and trading across distributed nodes, preserving data sovereignty and organizational autonomy.

A central challenge is Identity Management (IDM) in federated data trading environments, a challenge [1] that is shared with other similar federated data spaces. Traditional IAM systems, built around single-domain authentication models, lack the interoperability and cross-border assurance required in distributed data ecosystems. They do not easily integrate high-assurance identity schemes, cannot guarantee consistent trust across organizational boundaries, and struggle to enforce sovereignty-preserving principles essential in regulated data-sharing scenarios. This creates fragmentation, prevents seamless onboarding of external actors, and undermines confidence in the federated platform.

A second major challenge concerns the definition and management of fine-grained access control policies. Data trading platforms rely on precise, context-aware authorization to protect high-value assets, yet existing policy engines [2] are often too technical for the data providers and administrators who must use them. Business users face complex rule syntax, fragmented User Interfaces (UIs), and inconsistent abstractions that hinder policy creation and auditing. As a result, organizations either oversimplify policies—weakening security—or rely heavily on technical specialists, slowing down data trading and reducing operational agility.

A third challenge involves integration and compliance with the eIDAS [3] framework, which is essential for enabling trusted cross-border authentication in Europe. Achieving interoperability with national eIDAS Nodes requires significant customization and administrative coordination. Without eIDAS-compliant authentication, federated platforms cannot guarantee the level of trust, legal recognition, or user assurance mandated for regulated data trading across EU Member States. Additionally, eIDAS 2.0 [4] introduces the EUDI Wallet as a central mechanism for storing, presenting, and selectively disclosing Verifiable Credentials (VCs). Federated data trading platforms must therefore integrate wallet-based authentication and verifiable presentations into their IAM flows. Their IAM infrastructure should support the combination of federated identities with decentralized, user-controlled credential management. Without wallet integration, platforms cannot align with eIDAS 2.0’s requirements for user-centric identity, high assurance, selective disclosure, and cross-border interoperability.

To address these gaps, this work presents a comprehensive IAM framework tailored for federated data trading environments, developed within the EU-funded “PISTIS” project [5]. PISTIS provides a distributed infrastructure for secure and value-driven data sharing, trading, and monetization. Building within this enthronement, our work extends the Keycloak IAM platform [6] with capabilities that directly respond to the challenges outlined above.

1.1. Main Contributions

The main contributions of this work are as follows:

• Identity and Access Management (IAM) Framework: We designed and implemented a novel IAM framework specifically for federated data trading platforms, enabling secure management of user identities and access controls.
• eIDAS Authentication Integration: We extended Keycloak with support for eIDAS-based authentication, enabling certified cross-border login compliant with European Union (EU) trust frameworks.
• eIDAS 2.0 EUDI wallet Support: We implemented prototype EUDI wallet integration following the eIDAS 2.0 specifications and the usage of OpenID Connect for Verifiable Presentation (OIDC4VP) and OpenID Connect for Verifiable Credentials Issuance (OIDC4VCI) protocols for decentralized, privacy-preserving authentication.
• Access Policy Editor (APE): We developed a standalone, web-based APE for federated data trading platforms that abstracts Keycloak’s policy engine and enables non-technical administrators to define fine-grained, owner-driven access rules at the data trading node level.

All of the above were implemented as modules of a federated data trading platform and were deployed and evaluated in real-world industry sectors such as mobility, energy, and automotive. The evaluation resulted in a number of observations regarding the real-world usage of identity management and access control in data trading platforms. We also conducted a qualitative analysis on the usage of eIDAS and EUDI-based authentication in federated data trading as well as a comparative analysis of such major existing platforms. Finally, we conducted a usability analysis of our user-driven APE.

1.2. Paper Structure

The rest of the manuscript is organized as follows: Section 2 presents the related work as well as background concepts that are relevant to IDM and access control in federated data platforms. Section 3 presents the implementation details of the main modules of this work. Section 4 shows how this work was deployed in real-world environments and presents a comprehensive analysis of the security benefits of the eIDAS and EUDI wallet integration approaches as well as the usability benefits of this work’s access control policy management approach. It also presents a comparative analysis of major data trading platforms including PISTIS and their approaches in IDM and access control. Section 5 presents future directions and conclusions.

All the relevant implementations are available in the PISTIS project GitHub repository [7].

2. Background and Related Work

This section reviews foundational concepts and related work in federated data trading and management platforms, with a focus on IDM and access control as two core enablers of trust, interoperability, and regulatory compliance.

2.1. Identity Management (IDM) in Federated Data Trading and Management Platforms

Modern federated data trading and management platforms rely on federated IDM to ensure trust, interoperability, and regulatory compliance. The International Data Spaces (IDS) framework [8,9] provides a reference architecture for sovereign data exchange through certified connectors and X.509-based participant authentication. The Data Market Austria project [10] extends IDS principles to a national-scale marketplace, emphasizing semantic cataloging and interoperability. By contrast, Ocean Protocol [11] adopts a decentralized identity using blockchain wallets and Decentralized Identifiers (DIDs) for data access and control.

In a broader federated context, Gaia-X introduces a trust layer grounded in Self-Sovereign Identity (SSI) [1], utilizing VCs and DIDs for cross-domain authentication and service verification. Through Self-Issued OpenID Provider (SIOP) mechanisms [12] and secure digital wallets, users can authenticate and selectively disclose attributes, ensuring privacy and data sovereignty. This SSI paradigm supports interoperable, privacy-preserving access across European data infrastructures aligned with eIDAS 2.0.

The FIWARE ecosystem [13,14] further implements OAuth 2.0/OpenID Connect (OIDC)-based IAM (Keyrock), supporting organizational roles and external IdP integration.

Collectively, these initiatives illustrate a transition from centralized IAM systems toward decentralized, verifiable identity models, enabling trusted and cross-border data federation.

2.2. Access Control in Federated Data Trading and Management Platforms

Recent advances in access control for federated data platforms focus on combining adaptive and context-aware mechanisms to secure dynamic, multi-stakeholder environments. Traditional access control models such as Role-Based Access Control (RBAC) and Mandatory Access Control (MAC) provide foundational security but lack the flexibility required for modern federated architectures [15]. Contemporary research explores attribute-centric and risk-aware models that dynamically adjust permissions based on contextual factors including device trustworthiness, user behavior patterns, and data sensitivity levels [16,17,18].

Federated Risk-Based Authentication (F-RBA) frameworks leverage federated machine learning to provide privacy-preserving, real-time risk assessments across distributed devices, balancing security requirements with usability constraints in digital ecosystems [19]. These adaptive models improve upon static policies by integrating continuous risk evaluation and dynamic decision-making, enabling fine-grained governance that responds to evolving threat landscapes.

Blockchain-integrated access control mechanisms further strengthen federated platforms by embedding policies within smart contracts, ensuring tamper-resistant, decentralized enforcement, and auditability of data-sharing agreements [20,21,22]. Such solutions facilitate transparent, accountable access management across trust boundaries without reliance on centralized authorities, addressing key challenges in multi-organizational data exchange scenarios.

Hybrid approaches combining RBAC’s administrative simplicity with Attribute-Based Access Control (ABAC)’s flexibility have been proposed to address scalability and complexity challenges, enabling context-informed constraints and policy delegation in federated ecosystems [23,24]. These models support hierarchical policy administration while maintaining granular control over resource access, critical for environments where multiple stakeholders with varying security requirements must collaborate.

3. System Architecture and Implementation

This section presents the system architecture and implementation of the core IAM components of the PISTIS platform. It focuses specifically on the design and realization of the PISTIS Identity Manager and the APE, which together underpin authentication, authorization, and policy enforcement in the federated data trading environment. The section first outlines the high-level architectural context of the PISTIS platform in which these components operate and then details their technical implementation, including integration with eIDAS and EUDI Wallet-based authentication mechanisms.

3.1. PISTIS High-Level Description and Architecture Overview

The PISTIS platform is realized as a federated environment of collaborating stakeholders, governed by a central cloud-based entity. PISTIS constitutes a data space where stakeholders will be operating a “PISTIS Data Trading Node” deployment on their premises, either locally or on their own cloud resources (colored in green in Figure 1 below, with the blue indicating the data storage facilities of each stakeholder). Stakeholders use their data trading nodes to manage their own data; all data trading nodes connect through the “PISTIS Cloud Platform” (colored in orange in Figure 1 below), which is used to provide services that facilitate data monetization and transaction execution. This macroscopic view of the architecture is shown in Figure 1 below. Blockchain nodes are made available to facilitate and record transactions. The use of those blockchain nodes in PISTIS is of no relevance to this paper’s topics and is mentioned only as part of the general PISTIS functional description.

Figure 1. PISTIS macroscopic architecture [5].

It is noted that the actual flow of data (e.g., of the “data assets”) is performed only via a peer-to-peer communication channel set-up between the different “PISTIS Data Nodes” of the data provider and of the data consumer, thus increasing the overall security and trust of the PISTIS platform and supporting data sovereignty and privacy.

The PISTIS architecture relies on several external platform modules that interact with the IAM infrastructure through dedicated adapters, as described in the next paragraph. A central concept in PISTIS is the Data Factory, which represents the local infrastructure deployed on the premises of each participating organization. Each Data Factory serves as the organization’s autonomous data management hub, enabling data ingestion, transformation, quality assessment, cataloging, and preparation for trading, while maintaining full data sovereignty. Organizations retain complete control over their data assets, which never leave their Factory unless explicitly shared through peer-to-peer exchanges governed by smart contracts.

A specific module within the PISTIS IAM infrastructure (Factory Adapter) facilitates the registration and lifecycle management of Data Factories within the federated ecosystem, communicating with the central registrant to onboard new organizational nodes, validate their connectivity, and synchronize their identity and access configurations with the central Keycloak instance. This adapter ensures that each Factory is properly authenticated and authorized to participate in the PISTIS data space, enabling seamless integration between distributed organizational infrastructures and the centralized identity management layer.

3.2. Technical Implementation Details

The following subsections present the technical implementation of the PISTIS IAM infrastructure, its extension with eIDAS authentication through GRNET’s Keycloak module [25], the integration of the EUDI Wallet into the IAM system, and the standalone web-based APE.

3.2.1. Identity and Access Management (IAM) in PISTIS

The PISTIS IAM infrastructure implements a comprehensive framework for identity provisioning, validation, and access control across the federated data trading ecosystem. Built on Keycloak’s foundation, the system extends core capabilities with PISTIS-specific requirements for data trading scenarios, supporting both human users and automated system components through unified authentication and authorization mechanisms.

Keycloak [6] is an open-source IAM platform providing single sign-on (SSO), authentication, and authorization services based on widely adopted standards such as OAuth 2.0, OIDC, and Security Assertion Markup Language (SAML). It offers native support for managing users, groups, and custom roles, as well as fine-grained authorization capabilities that enable expressive access control policies.

A key feature of Keycloak for the PISTIS platform is its support for identity brokering, which allows it to operate as a service provider (SP) toward external IdPs. This enables delegation of authentication to third-party components, such as national eIDAS Nodes, while maintaining centralized access control and session management. During the authentication flow, Keycloak redirects the user to the external IdP and, upon successful authentication, provisions the user locally, optionally storing selected identity attributes subject to user consent. Identity brokering in Keycloak is implemented using standard federation protocols, including SAML v2 and OIDC.

Keycloak is released under the Apache License, making it fully open-source and well suited for the needs of PISTIS, where deep customization and the development of platform-specific extensions (e.g., for eIDAS and EUDI Wallet integration) are essential [26].

The architectural design of PISTIS IDM, depicted in Figure 2, employs a layered approach where Keycloak serves as the core IdP, deployed in a containerized environment. A custom Spring Boot-based IAM Application Programming Interface (API) layer abstracts Keycloak’s complexity, exposing RESTful services tailored to data-trading-driven operations, thus fulfilling PISTIS requirements for seamless integration with other modules through standardized adapters and ensuring consistent IDM across heterogeneous components.

Figure 2. Internal architecture of the PISTIS Identity Manager.

The supported authentication mechanism relies on OIDC for standardized single sign-on, with tokens issued as signed JSON Web Tokens (JWTs) containing both standard OIDC and PISTIS-specific claims. The system implements fine-grained authorization through multiple models, namely: (i) User-Based Access Control (UBAC) for PISTIS platform users, (ii) Group-Based Access Control (GBAC) for PISTIS Organizations, and (iii) ABAC for dynamic, context-aware permissions on tradable data assets of the platform. This multi-model approach enables flexible policy definition that accommodates varying requirements across different data trading scenarios.

The IAM infrastructure has also been extended with eIDAS VC authentication to ensure compliance with European regulations and support cross-border interoperability. This integration is based on GRNET’s Keycloak module [25] and allows PISTIS users to authenticate using their national eIDs. The technical details of this extension are presented in one of the following subsections.

Beyond core authentication and authorization, the IAM API layer exposes a comprehensive set of RESTful endpoints organized into specialized adapters that serve the external PISTIS modules presented in Figure 2. These adapters abstract Keycloak’s administrative complexity while enforcing consistent identity and access semantics across the platform.

The Factory Adapter provides endpoints for Data Factory lifecycle management within the federated ecosystem. It supports the registration of new Data Factories through the Factory Registrant component, including organizational metadata provisioning (such as country, domain, size, and type attributes), connectivity validation, and the automatic creation of corresponding Keycloak realm clients and service accounts. The adapter also exposes endpoints for retrieving registered Factory information, updating organizational attributes, and managing the activation status of Data Factories within the PISTIS network. Each registered Factory receives a unique identifier and cryptographic credentials that enable secure machine-to-machine communication with the central platform.

The Data CheckIn and Asset Bundler Adapter integrate with the respective components to synchronize resource representations with the IAM system. When a data asset is created in a Factory, this adapter automatically provisions the asset as a protected resource within Keycloak’s authorization services, associating it with the owning organization and applying default access scopes (such as READ and TRADE). During publication of said asset, the adapter updates resource metadata and links the asset with any access policies defined through the APE, ensuring that authorization decisions reflect the data owner’s specified restrictions before the asset becomes visible in the PISTIS marketplace catalog.

The APE Adapter serves as the bridge between the standalone APE web application and Keycloak’s policy engine. It exposes endpoints for creating, retrieving, updating, and deleting access policies expressed in PISTIS-specific terms—such as organizational attributes (country, domain, size, type) and dataset attributes (format, Traffic Light Protocol (TLP) classification)—which are then translated into Keycloak’s native policy representations. The adapter supports three policy archetypes: organization-based exclusion policies (GBAC), attribute-based policies for organizations (Organizational ABAC), and attribute-based policies for resources (Resource ABAC). Additionally, it provides endpoints for managing organizational entities and user memberships, ensuring that the APE maintains a synchronized view of the platform’s identity landscape for policy definition purposes.

All adapter endpoints are secured using OAuth 2.0 bearer token authentication, with fine-grained scope validation ensuring that only authorized PISTIS components and users can invoke specific operations. The IAM API implements request validation, error handling, and audit logging to support compliance and troubleshooting in production deployments.

In a nutshell, PISTIS IAM system is based on four components that work synergistically: (i) the Access Policy Engine extends Keycloak’s authorization services with custom evaluators for PISTIS-specific rules; (ii) the IdP/Validator authenticates users against local accounts, federated identities via eIDAS, and external IdPs such as GitHub; (iii) the Resource Manager maintains synchronization between IDM and data asset lifecycles; and the Secure Services and Key Store manages cryptographic material for token signing and secure inter-module communication. This architecture ensures that IAM requirements are met consistently across all layers of the PISTIS platform.

3.2.2. eIDAS Integration in PISTIS

This subsection describes the integration of eIDAS-compliant authentication within the PISTIS platform, focusing on interoperability between a federated IAM infrastructure and the European cross-border electronic identification infrastructure. It details the implementation of eIDAS support in Keycloak through the GRNET eIDAS Keycloak extension, the architectural and protocol-level adaptations required for the eIDAS SAML v2.0 profile, and the practical steps for connecting to a national eIDAS Node. The subsection also discusses the technical and operational challenges arising from protocol extensions, national variations, and compliance requirements.

In this context, the Keycloak-based IAM system within PISTIS has been extended to support authentication in compliance with the European Union (EU) framework for Electronic Identification, Authentication, and Trust Services (eIDAS), as defined under Regulation (EU) No 910/2014. While Keycloak natively supports OIDC and standard SAML 2.0, eIDAS mandates an extended SAML v2.0 profile that introduces additional attribute definitions, assurance level semantics, and protocol elements not available in standard implementations, necessitating the use of custom extensions and authentication components.

The integration described in this subsection is grounded in the original eIDAS 1.0 regulatory framework, formally established by Regulation (EU) No 910/2014. Adopted in 2014, eIDAS 1.0 introduced the first comprehensive European legal framework for electronic identification (eID) and electronic trust services, including electronic signatures, seals, timestamps, and website authentication. Its primary objective was to enable the cross-border mutual recognition of notified national eID schemes, allowing citizens to securely authenticate to public sector services across Member States (MSs) using their domestic electronic identities. While eIDAS 1.0 laid the foundation for interoperable and high-assurance authentication in the public sector, its adoption remained largely limited to government services, reflecting both the voluntary nature of national scheme notification and its limited alignment with private-sector and decentralized identity ecosystems.

To address this, we integrated the eIDAS Keycloak extension developed by GRNET, which provides a custom IdP compatible with the eIDAS SAML v2.0 profile (v1.2). The extension introduces several components essential for interoperability with national eIDAS Nodes: (i) an “eIDAS SAML v2.0” IdP, extending the default SAML IdP with eIDAS-specific features; (ii) a Username Template Importer Mapper for federated user lookup; (iii) an Attribute Importer Mapper for integrating eIDAS attributes; and (iv) a Citizen Country Selection Authenticator, which collects the user’s country prior to authentication. Together, these elements enable compliance with the Once-Only Principle (OOP), allowing users’ identity data, registered once with their national eID providers, to be securely reused within the PISTIS platform [25,26].

The GRNET eIDAS Keycloak extension is implemented using Keycloak’s Service Provider Interfaces (SPIs), enabling the extension of core server functionality without modifying the codebase. Through SPIs, the extension augments the standard SAML authentication flow to support the eIDAS Profile by introducing custom protocol handlers, authenticators, and attribute mappers. In particular, it extends the default SAML IdP to generate and process eIDAS-compliant authentication requests and responses, including mandatory elements such as Levels of Assurance (LoA), minimum dataset attributes, and country-specific identity information.

The extension integrates at multiple layers of the Keycloak authentication pipeline. Custom authenticators enforce the eIDAS-specific login sequence, including pre-authentication country selection, while specialized attribute mappers transform received eIDAS attributes into Keycloak-compatible user profiles. A username templating mechanism ensures deterministic user identification across repeated federated logins, preventing duplicate account creation while preserving compliance with the OOP.

As a first step in European Union (EU) integration of eIDAS, following administrative approval from the Greek eIDAS Single Point Of Contact (SPOC), PISTIS was integrated with the Greek national eIDAS Node. Each Member State (MS) operates its own SPOC [27], and while this authority is always the entry point for integration, the application and onboarding process varies across EU countries, depending on national administrative, legal, and technical requirements. Through the Greek SPOC connection, Greek users can authenticate to PISTIS using their national eIDAS credentials, which correspond to their Taxisnet digital identity. Taxisnet, widely deployed for tax and public administration services in Greece, provides a trusted and high-assurance authentication method. In addition, all EU citizens holding credentials from notified eID schemes pursuant to Article 9(1) of Regulation (EU) No 910/2014 (as listed in Commission Implementing Decision C/2025/4227 [28]) are also able to authenticate, ensuring broad European interoperability.

The integration of eIDAS authentication into PISTIS posed several technical and operational challenges. A primary difficulty was aligning Keycloak’s generic SAML processing model with the stricter requirements of the eIDAS Profile, including mandatory attributes, minimum assurance levels, and country-specific identity schemas.

Additional complexity arises from the heterogeneity of national eIDAS implementations. Although a common protocol is defined, practical differences exist between Proxy- and Middleware-based eIDAS Nodes in terms of attribute availability, user consent handling, and error reporting, requiring extensive testing and iterative adaptation.

From an operational perspective, integration is further complicated by administrative requirements imposed by national SPOCs, such as formal onboarding procedures, security assessments, and conformance testing. Managing certificates, metadata exchange, and environment-specific configurations also introduces non-trivial overhead.

Finally, to accommodate evolving eIDAS specifications, the implementation was designed to minimize hard-coded assumptions and isolate eIDAS-specific logic within well-defined extension components, facilitating future updates and cross-border expansion.

At a broader level, the eIDAS Network enables cross-border authentication by interconnecting national eIDAS Nodes, each of which extends the SAML 2.0 protocol in compliance with Regulation (EU) No 910/2014. Once a service provider (SP) is connected to a national node, it becomes interoperable with the entire European network. Importantly, such integration requires coordination with the national SPOC, whose procedures differ across EU Member States (MSs), with some requiring additional contractual or conformance testing steps before granting access.

As part of the PISTIS project, three participating data trading organizations—Germany, Spain, and Austria—have been evaluated for future cross-border integration, which is planned as the next step. Germany relies on the “Personalausweis” national identity card, offering a high-assurance eID function; Spain uses both the DNIe card and the Cl@ve authentication platform; and Austria employs ID Austria, a mobile-centric system that evolved from Handy-Signatur and Bürgerkarte. All three national eID schemes are notified at the “high” assurance level, enabling their use within PISTIS under the eIDAS framework once SPOC-mediated integration is finalized.

This integration provides PISTIS with a high-assurance, privacy-preserving, and interoperable authentication mechanism that aligns with EU regulations while supporting the federation of data trading across borders.

While the eIDAS 1.0-based integration enables high-assurance, cross-border authentication through centralized national infrastructures and extended SAML exchanges, it also highlights structural limitations in terms of user-centric control, protocol flexibility, and applicability beyond the public sector. These limitations directly motivate the evolution toward eIDAS 2.0 and the introduction of the EUDI Wallet, which shifts authentication and attribute disclosure toward decentralized, wallet-based interactions using modern protocols such as OIDC4VP. The following Section 3.2.3 builds upon the experience gained from the eIDAS 1.0 integration in PISTIS and explores how EUDI Wallet-based authentication addresses these limitations while enabling tighter integration with federated IAM platforms such as Keycloak.

Figure 3 below illustrates the eIDAS-based user authentication workflow for the Greek and German data trading organization nodes participating in the PISTIS project.

Figure 3. eIDAS-based user authentication workflow for selected data trading organizations in PISTIS using Keycloak [26].

The eIDAS-based authentication process proceeds as follows:

1.

The user visits the PISTIS platform.

2.

The user logs in using their eIDAS credentials by selecting their nationality (only certified PISTIS users are permitted to log in).

3.

If the user selects German nationality, the authentication request is redirected to the German national eIDAS Middleware service; if Greek nationality is selected, the request is redirected to the Greek eIDAS Proxy service.

4.

The respective eIDAS Middleware or Proxy then contacts the appropriate national eID server to verify the user’s identity.

5.

Upon successful authentication, the user is redirected back to the PISTIS platform.

An eIDAS Node consists of an eIDAS Connector and either an eIDAS Proxy Service or an eIDAS Middleware Service. The Connector initiates cross-border authentication requests, while the Proxy or Middleware Service provides authentication responses. This architecture implements the eIDAS four-corner model, which connects service providers (SPs) in one Member State (MS) with electronic IdPs in another through standardized SAML-based exchanges.

In this model, an SP in the requesting MS (SP Country) generates an authentication request, which is first forwarded to the national eIDAS Connector. The Connector transforms this request into a standardized eIDAS SAML AuthnRequest and transmits it to the eIDAS Node of the user’s MS via HTTPS redirection or browser auto-POST mechanisms. The user’s national eIDAS Node—operating either a Proxy or Middleware Service—translates the incoming eIDAS request into its domestic eID protocol and invokes the national IdP for user authentication. Upon successful authentication, a SAML Assertion containing the verified identity attributes is created and returned through the same route to the SP’s Connector, which validates the response and delivers the user identity data to the SP.

Depending on the technical implementation of each MS, two primary configurations exist. In a Proxy-to-Proxy connection, both MSs operate eIDAS Proxy Services that exchange eIDAS SAML messages directly between their Nodes. In a Proxy-to-Middleware configuration, one MS’s eIDAS Connector interacts with the Middleware Service of another, which performs the national-level authentication and returns the SAML Response. The Middleware process may also involve attribute selection and explicit user consent for attribute release, depending on the national eID implementation.

All communication within the eIDAS Network is browser-mediated over secure HTTPS, ensuring interoperability and confidentiality throughout the process. This architectural model was implemented and validated within the PISTIS platform, which leveraged its interconnection with the Greek eIDAS Node to enable secure, privacy-preserving, and interoperable cross-border user authentication among participating MSs. By enabling both Proxy- and Middleware-based configurations, eIDAS provides a flexible and standardized framework that ensures secure, privacy-preserving, and interoperable cross-border authentication across diverse national identity systems within the European Union (EU) [26,29,30].

3.2.3. EUDI Wallet Integration with Keycloak Using OIDC4VP and OIDC4VCI

This section presents the design and implementation of EUDI Wallet-based authentication within the PISTIS IAM infrastructure. It introduces the regulatory and technical foundations of the EUDI Wallet under the eIDAS 2.0 framework and details how wallet-based authentication and credential issuance are integrated into Keycloak using the OIDC4VP and OIDC4VCI protocols. The subsection further discusses the resulting system architecture, authentication workflow, and key implementation challenges encountered when bridging decentralized wallet-based identity with a federated IAM platform.

The regulatory foundation for this integration is provided by eIDAS 2.0, formally adopted through Regulation (EU) 2024/1183. This revision represents a shift toward a user-centric, wallet-based digital identity model. At its core is the EUDI Wallet, which Member States (MSs) are mandated to offer as a secure means to store, manage, and present digital identity data and attributes. Beyond authentication, eIDAS 2.0 introduces Qualified Electronic Attestations of Attributes (QEAA), enabling selective disclosure of VCs across public and private services. This framework strengthens user sovereignty, enhances privacy, and expands the applicability of European digital identity beyond public administration, addressing key limitations of eIDAS 1.0.

The new eIDAS 2.0 Regulation, which establishes the framework for the EUDI [31], builds upon the 2014 eIDAS Regulation [3] but addresses its key limitations. Unlike eIDAS 1.0, where national electronic identification schemes were voluntary and interoperability was achieved only through a complex superstructure prone to technical issues, eIDAS 2.0 mandates Member States (MSs) to provide digital wallets. These wallets enable citizens and businesses to link their national digital identities with additional personal attributes such as driving licenses and diplomas, and can be issued by both public authorities and recognized private entities. This approach enhances user control over personal data, improves privacy through selective disclosure, and facilitates seamless cross-border recognition and acceptance of digital identities for public and private services. This represents a fundamental step towards a user-centric, interoperable, and secure digital identity ecosystem in Europe [32,33].

From a technical perspective, EUDI Wallet is a secure application that allows EU citizens and organizations to store, manage, and present VCs—such as digital identities, organizational attributes, or qualifications—across borders in a privacy-preserving manner [34]. By incorporating the EUDI Wallet into Keycloak’s authentication flow, this work enables user login via Verifiable Presentations (VPs) rather than traditional credentials, aligning federated identity with SSI principles.

This integration extends Keycloak with support for OIDC4VP, enabling it to verify and consume VCs [35], and OIDC4VCI, allowing it to issue VCs to user wallets [36]. The process enhances privacy and user control through selective disclosure of attributes and passwordless authentication.

Within the PISTIS ecosystem, this implementation provides a pathway for transitioning from eIDAS 1.0 to eIDAS 2.0, supporting user-centric and cross-border authentication. The approach leverages open-source components to ensure interoperability and reusability across EU systems.

The architecture involves three core components:

1.

Keycloak—the central IdP managing user authentication and authorization. It is extended to delegate VC verification to an external OIDC4VP Verifier and to issue claims through an OIDC4VCI-compatible Issuer.

2.

walt.id—an open-source SSI framework providing Issuer, Verifier, and Wallet APIs. It handles the issuance of VCs via OIDC4VCI and the verification of VPs via OIDC4VP, serving as the bridge between the EUDI Wallet and Keycloak [37].

3.

Talao Wallet—a conformant EUDI Wallet implementation that allows users to receive, store, and present VCs during login to the PISTIS platform [38].

The authentication process comprises two key phases, as illustrated in Figure 4.

Figure 4. EUDI Wallet-based user authentication workflow in PISTIS.

Initially, during the OIDC4VCI phase, the user authenticates to Keycloak using methods such as passwords, GitHub, or eIDAS, prompting Keycloak to activate the walt.id Issuer to generate a credential offer. The user then accepts this offer via the Talao Wallet and securely stores the issued VC. Subsequently, in the OIDC4VP phase, the user selects the “Login with Wallet” option, scanning a presentation request (via QR code or deep link) shown by Keycloak. The wallet sends the VP to the walt.id Verifier, which validates it and returns a verified token to Keycloak, thus completing the login process.

From an implementation perspective, the integration of the EUDI Wallet into Keycloak required the extension of Keycloak’s authentication and identity brokering mechanisms to support wallet-mediated login flows. A custom authentication flow was introduced, adding a dedicated “Login with Wallet” execution step that initiates an OIDC4VP presentation request and suspends the authentication process until a VP is received and validated. This required adapting Keycloak’s session handling model to accommodate asynchronous verification results originating from the external verifier infrastructure.

Upon successful verification of a VP by the walt.id Verifier, the resulting verified claims are returned to Keycloak as a signed token, which is then consumed by a custom authenticator component. This component is responsible for mapping credential claims to Keycloak user attributes, resolving user identity (e.g., account linking), and establishing a local authenticated session. The implementation supports flexible claim-to-attribute mappings, enabling selective use of wallet-derived attributes for authentication, authorization, or policy evaluation without requiring persistent storage of all disclosed data.

In addition, the OIDC4VCI-based issuance flow was integrated into Keycloak using service accounts and confidential clients, allowing Keycloak to act as the authoritative source of user attributes during credential issuance while delegating cryptographic operations to the external Issuer. This separation ensures that Keycloak remains agnostic to credential formats and signature schemes, while still controlling issuance policies and eligibility criteria. The overall design preserves Keycloak’s role as the central policy decision point while enabling wallet-based authentication as a first-class login mechanism.

Despite its conceptual clarity, the integration of EUDI Wallet-based authentication into an existing federated IAM system posed several technical challenges. A primary difficulty concerned interoperability between Keycloak, the walt.id framework, and the Talao Wallet, all of which evolve independently and implement emerging specifications under active standardization. In particular, differences in supported credential formats (e.g., JWT-based versus JavaScript Object Notation (JSON)-LD credentials), proof types, selective disclosure mechanisms, and signature algorithms required careful alignment of presentation requests, schemas, and trust anchors across components.

Another challenge is related to the integration of OIDC4VP into Keycloak’s authentication model, which is traditionally centered on redirects and token exchanges rather than wallet-mediated presentation flows. Adapting Keycloak to initiate wallet-based authentication, manage asynchronous verification results, and bind verified VPs to local user sessions required custom extensions and careful handling of session state and error conditions.

Maintaining compliance with the evolving eIDAS 2.0 requirements further increases complexity. As the regulatory framework and technical specifications for the EUDI Wallet ecosystem continue to mature, design decisions have to anticipate stricter requirements regarding assurance levels, trust frameworks, and credential verification sources. To address this, the implementation follows open standards, avoids vendor-specific assumptions, and clearly separates VC issuance, verification, and trust resolution concerns, thereby facilitating future alignment with officially recognized infrastructures. These challenges further motivate the planned evolution towards European-level trust infrastructures, such as the European Blockchain Services Infrastructure (EBSI), which are expected to provide harmonized trust frameworks and authoritative verification services for natural-person credentials under the eIDAS 2.0 ecosystem.

This integration showcases how existing federated systems like Keycloak can interoperate with SSI frameworks, enabling a secure, privacy-preserving, and user-centric authentication flow fully aligned with eIDAS 2.0 and the emerging EUDI Wallet ecosystem.

It should be noted that while walt.id currently acts as both Issuer and Verifier within the prototype, the long-term objective of the PISTIS IAM infrastructure is to integrate the European Blockchain Services Infrastructure (EBSI) [39] as the authoritative verification source for credentials related to natural persons, fully aligning with the eIDAS 2.0 specifications.

3.2.4. Access Policy Editor (APE) in PISTIS

The PISTIS APE represents an implementation of user-centric access control management for federated data trading environments. APE has been designed as a web-based application, aiming to address the complexity gap between technical policy engines and business-level requirements by providing an intuitive interface for policy definition and management.

The primary goal is to simplify the definition of scope-based policies through an intuitive web-based UI editor. By doing so, administrators gain the ability to tailor access controls for specific use cases, encompassing user roles and access to targeted resources within the PISTIS ecosystem. This functionality ensures that the access policies align with the unique organizational structure and requirements so that data living in the PISTIS platform are findable with proper access to other organizations.

Access policies generated by the APE provide a multifaceted approach to access control. Firstly, they dictate who has the privilege to access distinct PISTIS Organization resources, ranging from specific features within the PISTIS Platform to exclusive datasets owned by the organization. Secondly, these policies define the scope or rights associated with accessible PISTIS Organization resources. This extends beyond conventional permissions, including Create, Read, Update, Delete, and Admin, to incorporate any data trading platform-specific policies such as Trading, Transformation, Pricing, and more. Additionally, the editor allows administrators to finely tune access on nested objects or attributes within a specific PISTIS Organization’s resource. For example, an administrator can grant read access to an entire data stream while restricting update permissions to a specific attribute, providing granular control over resource accessibility.

Internally, the PISTIS APE relies on Keycloak’s infrastructure and PISTIS IAM. Keycloak employs a secure and scalable database system to store and retrieve the intricate policies defined by administrators. This ensures that policy information is organized, quickly accessible, and securely managed. Furthermore, Keycloak leverages its advanced indexing service to optimize the efficiency of policy enforcement during runtime. The indexing service plays a pivotal role in accelerating the retrieval of policies, contributing to the overall responsiveness and performance of the APE within the PISTIS platform. These internal components work seamlessly to provide a dynamic, responsive, and secure access control mechanism tailored to the specific needs of organizations utilizing the Keycloak-based APE in the PISTIS environment.

Policy modeling within the editor supports three distinct policy archetypes:

(i)

Organization-based policies (GBAC) to enable institutional access control.

(ii)

Attribute-based policies for organizations (Organizational ABAC) to provide fine-grained control through attributes such as country of origin, organizational size, business domain, and organization type.

(iii)

Attribute-based policies for resources (Resource ABAC) to tune access control based on resources’ attributes such as format (binary, text, Comma-Separated Values (CSV), and JSON) and TLP (red, amber, green, and clear).

The above-described policy modeling within the editor extends beyond traditional Create Read Update Delete (CRUD) operations to support PISTIS-specific actions, like Trading, which can be further expanded to match certain operations in data trading (i.e., actions to reflect legal or reselling aspects).

Within the PISTIS ecosystem, APE is realized as described in Figure 5 and is used to (i) allow all users to define exclusion access policies for members of their organization during data ingestion, (ii) allow all users to define group-based or attributed-based policies at organizational level, and (iii) allow Organizational Administrators to manage users and policies of their organizations. The negative policy logic intends to leverage the data trading mission; thus, by default, the allow-all concept is applied unless special criteria are met, defined in the APE.

Figure 5. Internal architecture of the PISTIS APE.

More specifically, the following scope-based policies can be defined to serve PISTIS as a data trading platform by allowing administrators to define exclusions as follows:

• Specific User(s);
• Specific Organization(s);
• Organization(s) meeting a set of criteria, like: (a) country of origin, (b) type of organization, (c) domain of activity, and (d) size of the organization;
• Dataset-specific attributes, like: (a) format (binary, CSV, text, JSON) and (b) TLP categorization (red, amber, green, clear).

Table 1 below summarizes the available organizational and dataset attributes that are available for policy definition.

Table 1. Available attributes for defining access policies regarding organizations and datasets.

Refers to	Attribute	Available Options
Organization	Size	Small, Medium, Large
Organization	Country	Austria, Germany, Greece, Spain, United Kingdom (reflecting PISTIS project consortium’s end-users for demonstrative reasons)
Organization	Domain	Consumer Finance, Consumer Goods, Education, Electricity, Healthcare, Oil and Gas, Transportation
Organization	Type	Education & Research Sector, Intergovernmental Organizations, Non-Profit Sector/Third Sector, Private Sector For-Profit, Public Sector/Governmental
Dataset	Format	Binary, CSV, Text, JSON
Dataset	TLP	Red, Amber, Green, Clear

APE has been developed as a NuxtJS [40] (version 3) application (part of PISTIS Cloud Platform) with Vue’s [41] (version 3) Composition API. The editor integrates seamlessly with the Keycloak-based IAM system (described in Section 3.2.1) through a dedicated Representational State Transfer (REST) API, enabling real-time policy updates without service interruptions. Policy changes are immediately persisted in Keycloak’s authorization services; however, previously issued JWT access tokens remain valid until expiration (typically 5–15 min), ensuring that active user sessions are not abruptly terminated. For critical operations such as data trading transactions, other components downstream (such as the Data Factory Connector) perform additional authorization checks against current policies at execution time, ensuring that sensitive operations always reflect the most recent access restrictions regardless of token issuance time. The editor’s architecture implements a comprehensive three-tier design pattern with clear separation of concerns.

The presentation layer, built with NuxtJS, provides a responsive web interface for policy management and validation. It utilizes Vue 3 composables for state management and reactive data binding, featuring specialized components for each policy type and corresponding variants. Each component implements granular form validation with real-time error feedback, ensuring data integrity at the client level. The resource selection mechanism incorporates intelligent autocomplete functionality with filtered suggestions drawn from the backend resource registry, which dynamically queries available assets based on user input patterns.

Beyond access policy definition, the PISTIS APE also serves as a central component for managing organizations and their associated users within the platform. It maintains a platform-level view of organizations, users, and relevant attributes that are required for expressing meaningful, domain-aware access policies.

Examples of the policy definition and the organization description can be seen in the screenshots in Figure 6, Figure 7 and Figure 8.

Figure 6. Definition of a data-trading-oriented policy during dataset publication using PISTIS APE.

Figure 7. PISTIS Organizations listed using PISTIS APE.

Figure 8. Managing organization attributes using PISTIS APE.

The backend integration layer provides a unified interface by forwarding authenticated requests to the PISTIS IAM system using the OAuth 2.0 [42] bearer token authentication scheme for all service calls. This way, synchronization is maintained between the editor’s resource registry and Keycloak’s authorization services, while pagination is also supported to efficiently handle large resource catalogs.

The editor incorporates advanced User Experience (UX) patterns to simplify complex policy definition workflows. The policy creation wizard guides users through a multi-step process: policy identification (name and description), resource selection with type-ahead search, scope definition through intuitive check-boxes, and attribute specification via drop-down selectors populated from organizational registries. The resource interface transforms raw Keycloak resource objects into user-friendly representations, mapping technical identifiers (like _id) to display names while preserving the underlying resource Universal Resource Identifiers (URIs) for backend compatibility. Conditional rendering based on policy type ensures that only relevant attribute fields are displayed, reducing cognitive load and preventing configuration errors.

Performance optimization techniques, including policy caching and incremental evaluation, ensure that the editor remains responsive even when managing thousands of policies across multiple organizations.

4. Deployment in Real-World Industry Sectors and Analysis

The aforementioned implementations were evaluated, along with the whole PISTIS platform, in realistic operational settings across three major sectors: mobility, energy, and automotive. All use cases were implemented as pilot deployments involving samples of operational datasets, rather than conceptual demonstrations. Section 4.1, Section 4.2 and Section 4.3 summarize the application context of each use case as well as their implementation and deployment setting, while Section 4.4 presents the evaluation methodology and the main qualitative observations and results.

4.1. Mobility and Urban Planning Sector

The Mobility and Urban Planning sector aims to enable seamless data sharing and trading among stakeholders from multiple domains, including aviation, public transportation, and public administration, typically operating within the same geographic area. Within this context, the PISTIS platform supports data exchange of information on scheduled and actual transfer passengers between airports, ground handlers, and airlines, allowing early detection of operational irregularities and optimization of baggage-handling workflows. Public transportation planning also benefits from exchanged data flows between the local transportation authority and the airport, where access to historical passenger and traffic data enables better understanding of mobility patterns and improved scheduling of services, such as bus routes, aligned with fluctuating airport demand.

More specifically, the use case was implemented and evaluated through pilot deployments in the Athens metropolitan area, involving Athens International Airport (AIA), the ground-handling service provider GOLDAIR, the Athens public transportation authority (OASA), and the City of Athens IT company (DAEM). The PISTIS platform was integrated with the existing airport operational, ground-handling, and public transport information systems of these stakeholders, which acted as data providers and consumers depending on the scenario. Structured datasets related to mobility operations, including passenger, baggage, and aircraft turnaround flows, were exposed through the deployed data trading nodes and exchanged using the platform’s workflows.

4.2. Energy Sector

The energy sector focuses on strengthening grid resilience by leveraging the flexibility provided by local prosumers coordinated through aggregators, while evaluating the real-world benefits of secure and reliable data sharing. The PISTIS platform enables data exchange among distribution system operators, market operators, and aggregators, enhancing coordination and allowing distributed energy resources (DERs) to participate in both long-term and short-term flexibility markets. Through improved collaboration between DERs, aggregators, and market operators, PISTIS supports more informed grid planning and long-term local flexibility markets. Moreover, the platform facilitates transparent local energy exchange, thereby supporting the growth of peer-to-peer energy trading models and energy communities.

More specifically, the energy sector use case was implemented and evaluated through pilot deployments in an Energy Hub environment, integrating the platform with the existing operational systems of market operators, distribution system operators, aggregators, and service providers involved in flexibility market processes. OMIE acted as the market operator, providing a local flexibility market platform, Cuerva operated as the distribution system operator (DSO), and Bamboo fulfilled the role of flexibility aggregator, while CARTIF contributed both DSO-oriented technological functionality and independent flexibility services, supported by meteorological data provided by UBIMET. Within this setting, PISTIS operated as a coordination layer for flexibility-related data exchange, supporting interactions between market, grid, and service actors across multiple operational time horizons. Market, grid, flexibility, and predictive datasets, including consumption forecasts, generation profiles, and contextual weather information, were exchanged through the deployed data trading nodes.

4.3. Automotive Sector

In the automotive sector, modern vehicles are increasingly connected and generate substantial volumes of data, enabling more sophisticated analysis of driving behavior. Trip data collected from smartphone applications and vehicle sensors is examined to identify driving patterns in relation to temporal, spatial, and environmental conditions such as weather and air quality. These insights support urban analytics efforts, including emissions modeling and the detection of stop-and-go traffic hot-spots. In parallel, driver behavior is classified according to driving styles using safety-related event data—for example, speeding incidents, phone usage while driving, reliance on driver-assistance systems, and instances of risky maneuvers. The PISTIS platform enables the efficient trading of analytics data between automotive businesses as well as raw sensor historical datasets.

More specifically, the automotive sector use case was implemented and evaluated through an automotive demonstrator hub integrating connected vehicle data, contextual information, and analytics services. Vehicle trip and sensor data were provided through CARUSO and VIF. The platform was integrated with the existing data provisioning and analytics environments of these stakeholders, without requiring changes to their underlying vehicle data pipelines. PISTIS was used as a federated data trading and enrichment backbone, allowing independently operated analytics services to consume, combine, and exploit these datasets under controlled sharing conditions. To enrich analytics, additional contextual datasets were incorporated, including meteorological data from UBIMET, map data from OpenStreetMap, and air quality measurements from open governmental data platforms. These datasets were shared through the PISTIS platform as tradable assets, covering both raw vehicle data and derived analytics related to traffic quality, driving behavior, and driving risk assessment in urban environments.

4.4. Cross-Sector Evaluation and Results

Across all three evaluated sectors, the PISTIS platform was deployed as a federated data trading environment, where an instance of a PISTIS factory was deployed for each participating organization, totaling 15 individual instances. Each organization managed its own users who were able to check in, transform, monetize, and publish their dataset offerings, as well as search and trade datasets from other organizations via the PISTIS marketplace. All searching and trading operations were governed by the access policies that were created by the organizational end-users via the APE, while those users could authenticate into their PISTIS factories either via standard username/password or via the implemented eIDAS integrations.

The evaluation process followed a multi-stage technical and user-driven methodology. Initially, platform components were verified through component-level functional testing to ensure the correctness of individual services. Subsequently, flow-level testing was performed by grouping individual workflows, reflecting the core business processes of each sector. Finally, full end-to-end testing was conducted on clean installations following complete user scenarios that involve dataset check-in, publication, access policy definition, data search, and dataset trading. During this phase, the end-users actively participated by executing realistic operational scenarios and providing feedback, enabling the identification and resolution of integration and configuration issues.

Beyond technical verification, the process also included a qualitative evaluation of the platform from the end-user’s perspective, following a quality-in-use approach inspired by the ISO/IEC 25010 standard [43]. The evaluation focused on characteristics relevant to data trading platforms, namely effectiveness, efficiency, usability, and user satisfaction. Effectiveness assessed the degree to which PISTIS supported stakeholders in achieving their operational and business goals, efficiency examined perceived effort reduction and time savings compared to existing data-sharing practices, usability captured ease of learning, navigation, and controllability, and satisfaction reflected users’ overall experience and willingness to adopt the platform in future workflows. These aspects were evaluated through structured questionnaires completed after each evaluation phase and complemented by qualitative feedback sessions. Preliminary and intermediate results of the evaluation of the whole PISTIS platform can be found in the project’s public evaluation reports [5].

More specifically, regarding the identity management and access control functionalities, the following five key results were identified:

1.

Although the system supported both user- and organization-based access control, the actual policies that were implemented by the end-users were organization-based. This shows that the predominant need in data trading is to control which companies are the intended buyers and which companies should be excluded from acquiring the offered datasets rather than restricting access to specific users and roles.

2.

The most common attributes that were used, from the set of offered ABAC policies, were the country of origin and the organization domain. This shows that the main focus in data trading was compliance with national regulations (restricting certain countries from accessing the data) and market goals (targeting specific market domains as potential buyers).

3.

The evaluation of the usage of eIDAS 1.0 via the national eIDAS Nodes posed real challenges from the implementation point of view. During platform implementation, the need to integrate the data trading platform with all the national eIDAS Nodes means that, in order to scale the platform IAM on a European level, one needs to follow a lengthy administrative procedure (apply to become a service provider and exchange endpoints and credentials with each national eIDAS Node) approximately as many times as the countries that need to be supported. During the pilot evaluation, we managed to test only one national node (Greece) with limited functionality and were in the process of integrating with one more (Austria).

4.

From the user perspective, using the national form of authentication just to access a commercial data trading platform was met with some initial skepticism mainly because this type of authentication is, at the time of writing, used mainly for accessing government services such as the tax system.

5.

The usage of an EUDI-compatible wallet was met with interest from the usability point of view, but it lacked real integration with official EBSI infrastructure to test its security capabilities. At the time of writing, EBSI/EUDI was still at the stage of large-scale pilot implementation [44] and not in full production.

Those remarks were not only part of the results of the pilot evaluation but were also taken into account during the design and implementation of the PISTIS platform. The prospective end-users were actively involved in the shaping of, mainly, the access control functionality. It was made apparent, for example, that an exclusion-based access control was more practical and useful for a data trading end-user than a more generic RBAC/ABAC approach.

4.5. Analysis of the Use of eIDAS-Based Authentication in Federated Data Trading

In the initial deployment of the PISTIS platform, user authentication relied on locally provisioned Keycloak accounts managed by the platform administrator. While common in centralized IAM systems, this approach exhibits limitations in federated and cross-border data trading environments. To address these limitations, Keycloak was extended with the GRNET eIDAS Keycloak extension and interconnected with the Greek eIDAS Node, enabling authentication using nationally issued eIDAS credentials.

Compared to traditional username/password-based authentication, eIDAS provides significantly stronger identity assurance. User identities are verified by trusted national authorities and delivered with standardized Levels of Assurance (LoA), reducing impersonation risks and eliminating the need for platform-side identity proofing. Moreover, eIDAS-based login removes password management from the platform, mitigating common attack vectors such as phishing, credential reuse, and brute-force attacks, while reducing the operational security burden on the IAM infrastructure. Although eIDAS authentication may involve additional protocol exchanges, it prioritizes identity assurance, interoperability, and regulatory compliance over raw authentication latency.

A key advantage of eIDAS authentication is its inherent cross-border interoperability. Users from different EU Member States (MSs) can authenticate using their national credentials without prior registration or bilateral trust agreements, directly supporting scalable onboarding in federated data trading scenarios and aligning with the objectives of European data spaces.

In addition, eIDAS authentication enhances legal certainty and regulatory compliance. Authentication events are anchored in the eIDAS regulatory framework, providing a legally recognized identity layer that supports auditability, accountability, and non-repudiation in access control decisions—an essential requirement in regulated data-sharing ecosystems.

Overall, integrating eIDAS authentication into the PISTIS IAM framework strengthens security, interoperability, and trust among federated stakeholders, while providing a natural foundation for the subsequent adoption of EUDI Wallet-based and VC-driven authentication mechanisms.

4.6. Analysis of the Use of EUDI Wallet-Based Authentication in Federated Data Trading

While eIDAS-based authentication provides strong, state-backed identity verification, it primarily focuses on user authentication at a single point in time through centralized national infrastructures. In contrast, EUDI Wallet-based authentication introduces a user-centric, credential-based model that enables selective disclosure and reusable identity assertions across federated data trading environments.

A key advantage of EUDI Wallet authentication is the use of VCs that are cryptographically verifiable and issued by trusted authorities. Unlike traditional eIDAS login flows, which typically release a fixed set of identity attributes, EUDI Wallets allow users to disclose only the attributes required for a specific transaction, thereby enhancing privacy and supporting data minimization. As with other high-assurance mechanisms, EUDI Wallet-based authentication prioritizes user consent and cryptographic verification over raw authentication latency.

Furthermore, EUDI Wallet-based authentication reduces repeated dependence on online national IdPs after credential issuance. Once issued, VCs can be presented directly by the user’s wallet to a verifier, enabling more flexible authentication and authorization flows and improving resilience in federated environments where centralized identity services may pose scalability or availability constraints.

From an access control perspective, EUDI Wallets enable tighter coupling between authentication and authorization. VCs can convey domain-specific attributes—such as organizational roles, contractual status, or sector affiliation—allowing access decisions to rely on externally issued, cryptographically verifiable claims rather than locally managed user profiles. This supports fine-grained ABAC across organizational boundaries.

Overall, EUDI Wallet-based authentication complements and extends eIDAS-based login by shifting IDM toward a decentralized, privacy-preserving, and user-controlled model. This evolution aligns with the objectives of European data spaces and provides a future-proof foundation for interoperable and policy-driven access management in federated data trading platforms.

Table 2 compares local account-based authentication with eIDAS-based and EUDI Wallet-based approaches in federated data trading platforms.

Table 2. Comparison of authentication approaches in federated data trading platforms.

Characteristic	Local Accounts	eIDAS	EUDI Wallet
Identity assurance	Low–Medium	High (LoA-based)	High (VC-based)
Authentication model	Password-based	Federated, SAML-based	Wallet-mediated, OIDC-based
User-centric control	Low	Medium	High
Selective disclosure	No	Limited	Yes
Cross-border interoperability	No	Yes (EU-wide)	Yes (EU-wide)
Private-sector applicability	High	Limited	High
Protocol flexibility	High	Low	High
Regulatory grounding	Platform-specific	eIDAS 1.0	eIDAS 2.0
Credential portability	No	No	Yes

4.7. Comparative Analysis of Federated Data Trading and Management Platforms

To position the proposed IAM framework within the broader landscape of federated data trading and management solutions, this subsection presents a comparative analysis of representative initiatives commonly referenced in European data space and data marketplace contexts, as introduced in Section 2. The analysis proceeds in two steps. First, a feature-level comparison examines IAM approaches, support for eIDAS and EUDI Wallet-based authentication, access policy models, user-facing policy management, and data sovereignty considerations. Table 3 provides a compact overview of these features. Second, the subsequent discussion derives comparative insights by elaborating on the most relevant similarities, differences, and architectural implications across the examined platforms.

Table 3. Feature comparison of representative federated data trading and management initiatives.

Feature/System	IDS a	DMA b	Ocean c	Gaia-X	FIWARE	PISTIS
IAM	X.509	IDS	DID	SSI	Keyrock	Keycloak
eIDAS	? *	No	No	? *	Ext	Yes
EUDI	No	No	No	? *	No	Yes
Access Policy	Conn	Cat	SC	SSI	Roles	APE
UI	Ltd	Adm	Web3	Spec	Gen	Yes
SSI	? *	No	Yes	Yes	? *	Hybrid
Data Sov.	Yes	Nat	Web3	EU	IoT	Yes
DLT	? *	No	Yes	? *	No	Log
Token-based	No	No	Yes	No	No	No

^a IDS: International Data Spaces. ^b DMA: Data Market Austria. ^c Ocean: Ocean Protocol. * Entries marked with “?” indicate that the corresponding feature is not explicitly specified or consistently documented in publicly available architectural descriptions.

4.7.1. Feature-Level Comparison of Federated Data Trading and Management Platforms

Regarding the core IAM approach, IDS relies on X.509-based participant authentication implemented through IDS connectors. Data Market Austria builds upon the IDS identity model with catalog-level integration. Ocean Protocol adopts blockchain wallet-based identities and DIDs. Gaia-X is founded on an SSI trust layer leveraging DIDs and VCs. FIWARE employs OAuth 2.0/OIDC-based authentication via Keyrock, supporting role- and organization-based access management. In contrast, PISTIS implements a Keycloak-based IAM framework supporting UBAC, GBAC, and ABAC across users, organizations, and data assets.

Regarding eIDAS-based authentication, IDS does not provide native integration within its reference stack, although conceptual alignment is possible. Data Market Austria does not document native eIDAS support, while Ocean Protocol does not focus on eIDAS-compliant identity. Gaia-X anticipates alignment with eIDAS 2.0 at the architectural level, but practical integrations remain limited. FIWARE relies on external IdPs. In contrast, PISTIS provides operational eIDAS authentication through direct integration with a national eIDAS Node via a dedicated Keycloak extension.

Concerning EUDI Wallet integration, IDS, Data Market Austria, Ocean Protocol, and FIWARE do not support wallet-based authentication in their current implementations. Gaia-X anticipates EUDI Wallet usage through its broader SSI vision, although concrete implementations remain limited. PISTIS, on the other hand, includes a prototype integration using OIDC4VP and OIDC4VCI, enabling wallet-based authentication and VC exchange.

With respect to access policy models, IDS relies on connector-level usage control and contract-based policies configured at the technical level. Data Market Austria employs marketplace-oriented catalog policies. Ocean Protocol enforces access via on-chain smart contracts and tokenized controls. Gaia-X anchors policy enforcement within its SSI-based trust framework. FIWARE uses RBAC through Keyrock. PISTIS introduces a dedicated APE built on Keycloak, supporting UBAC, GBAC, and ABAC with expressive inclusion and exclusion logic.

Regarding non-technical policy management, IDS provides limited interfaces focused on connector configuration, while Data Market Austria offers administrator-oriented tools. Ocean Protocol typically requires interaction with Web3 tooling. Gaia-X policy management is mainly addressed at the specification level, and FIWARE provides a generic administrative interface. In contrast, PISTIS offers a web-based APE, enabling business users to define fine-grained access policies through the platform UI.

In terms of decentralized identity, IDS partially addresses SSI through extensions and alignment with Gaia-X. Data Market Austria does not focus on decentralized identity. Ocean Protocol natively adopts DID-based identities. Gaia-X places SSI, DIDs, and VCs at the core of its trust model. FIWARE supports decentralized identity only optionally. PISTIS adopts a hybrid approach, bridging federated IAM with SSI mechanisms via EUDI Wallets and OIDC4VP/OIDC4VCI.

From a data sovereignty perspective, IDS targets sovereign data exchange within data spaces. Data Market Austria focuses on a national data marketplace. Ocean Protocol emphasizes a Web3-oriented data economy. Gaia-X targets pan-European data spaces. FIWARE addresses generic smart-city and Internet of Things (IoT) scenarios. PISTIS is designed for federated data trading with peer-to-peer data flows and organization-level sovereignty.

Regarding Distributed Ledger Technologies (DLTs), IDS supports usage control and logging but does not place Distributed Ledger Technology (DLT) at the core. Data Market Austria is not DLT-centric. Ocean Protocol relies on blockchain as a foundational component. Gaia-X allows DLT integration but does not mandate it. FIWARE does not focus on DLT. PISTIS integrates blockchain components for transaction logging while avoiding full on-chain policy enforcement.

Finally, concerning token-based economic incentives, IDS, Data Market Austria, Gaia-X, FIWARE, and PISTIS do not adopt token-centric models, whereas Ocean Protocol natively supports token-based incentives and on-chain economic mechanisms.

4.7.2. Architectural Implications and Comparative Insights

Based on the feature-level comparison above, the following discussion highlights key architectural implications for federated data trading and management platforms.

Table 3 above shows that existing initiatives provide important building blocks for federated and sovereign data sharing, yet typically address identity, trust, and access control in a fragmented manner. IDS and Data Market Austria emphasize connector-centric security and semantic interoperability but lack integrated eIDAS and EUDI Wallet support and do not offer user-friendly policy management tailored to data trading. Ocean Protocol and Gaia-X advance decentralized identity and SSI but primarily rely on blockchain-native or specification-level mechanisms that are not readily aligned with operational eIDAS 2.0 authentication flows in regulated European Union (EU) data spaces.

By contrast, PISTIS combines a production-grade IAM stack (Keycloak), operational eIDAS integration, and a working EUDI Wallet prototype with a dedicated APE enabling non-technical users to define fine-grained UBAC, GBAC, and ABAC policies directly through the platform UI. This integrated approach provides concrete architectural and functional advantages for federated data trading and management platforms operating under EU regulatory constraints.

Some features intentionally remain out of scope in PISTIS, such as native token-based incentives and fully on-chain policy enforcement, which are central to blockchain-centric ecosystems like Ocean Protocol. These mechanisms are less aligned with the compliance, governance, and risk profiles of regulated Business-to-Business (B2B) data spaces, where legal agreements and organizational accountability take precedence over token-based incentive schemes.

4.8. Architectural Benefits of Decoupled Policy Management in APE

In a traditional approach, relying solely on Keycloak, access control policies are tightly coupled with Keycloak’s interface and Permissions/Policies interpretation. While this is effective and generally covers most of the cases, it requires specific concepts to be adopted by the users, often requiring them to dive into Keycloak’s concepts to understand, modify, or audit access rules. In contrast, the PISTIS APE introduces a centralized and domain-aware policy management layer, providing a single place where all access policies can be defined, viewed, and managed independently of the underlying IAM technology. Policies are expressed in business and data-centric terms—such as organizational and dataset attributes—rather than low-level IAM constructs. This separation of concerns allows Keycloak to remain focused on identity, authentication, and enforcement, while policy semantics and governance are handled at the platform level. As a result, policy management becomes more transparent, auditable, and aligned with data governance requirements, and it reduces configuration errors, improves portability across IAM solutions, and better supports federated and data space environments where access decisions must reflect contractual, organizational, and contextual conditions beyond simple identity-based authorization.

This decoupled architecture also enhances system maintainability and evolution. Since access policies are defined using platform-specific abstractions rather than Keycloak-native constructs, the underlying IAM technology can be upgraded, reconfigured, or even replaced with minimal impact on existing policy definitions. Furthermore, the separation enables independent versioning of policy logic and IAM infrastructure, allowing security patches or Keycloak updates to be applied without requiring policy migration or re-validation. This modularity is particularly valuable in federated environments where different Data Factories may operate on varying infrastructure versions while maintaining consistent policy semantics across the ecosystem.

At the same time, the APE complements rather than replaces the underlying IAM system by synchronizing organizational and user information with the IdP, which remains responsible for authentication and credential management. This separation of responsibilities allows IAM systems such as Keycloak to focus on secure identity enforcement, while the APE governs how users and organizations are represented and utilized within the platform’s access control model. As a result, administrators can manage users, organizational context, and access policies from a single platform interface, reducing configuration complexity, improving maintainability, and ensuring that organizational changes are consistently reflected across all policy definitions and enforcement points.

This centralized management approach also streamlines auditing and compliance workflows. Rather than correlating policy information scattered across Keycloak realms, clients, and authorization configurations, auditors can review all access rules from a single interface with clear visibility into which organizations, users, or attributes are affected by each policy. The APE maintains a complete history of policy modifications, including timestamps and the identity of administrators who performed changes, enabling comprehensive audit trails that satisfy regulatory requirements common in data trading environments and scenarios. This consolidated view is able to significantly reduce the effort required for periodic access reviews and facilitates rapid response to compliance requirements.

An additional advantage of the PISTIS APE is the improved user experience it offers to platform administrators and data owners, as it eliminates the need to access and manage policies through a separate environment. Instead of logging into a different system such as Keycloak to configure or inspect access rules, users can define and manage policies directly within the same platform environment where they already perform their operational tasks, such as data onboarding, publication, and governance. This unified interaction model reduces cognitive load, shortens configuration cycles, and minimizes the risk of misalignment between platform-level intentions and IAM-level implementations.

5. Conclusions and Future Directions

This work presented a comprehensive IAM framework for federated data trading platforms developed within the EU-funded PISTIS project. The following four main contributions were introduced: (i) a novel Keycloak-based IAM system tailored for distributed data trading scenarios; (ii) operational eIDAS integration, enabling certified cross-border authentication with a national eIDAS Node; (iii) prototype EUDI Wallet integration using OIDC4VP and OIDC4VCI protocols for decentralized, privacy-preserving authentication; and (iv) a standalone web-based Access Policy Editor (APE) that enables non-technical users to define fine-grained access policies directly from the UI of the data trading platform.

These components were tested across real-world scenarios in mobility, energy, and automotive sectors, demonstrating enhanced trust, interoperability, and usability in regulated data-sharing ecosystems. The framework addresses key limitations of existing solutions by combining production-grade IAM infrastructure with operational eIDAS/EUDI support and domain-specific policy management.

The integration of eIDAS into PISTIS demonstrates the feasibility of high-assurance, standards-based authentication in federated data trading. As described in Section 3.2.3, the integration of the EUDI Wallet within PISTIS constitutes a major step toward unifying federated and decentralized IDM. Building upon this foundation, future developments will further align the PISTIS authentication framework with the upcoming eIDAS 2.0 ecosystem while extending the existing implementation to interconnect with more eIDAS Nodes of participating Member States (MSs), thereby enhancing cross-border interoperability. At the same time, we will interconnect the EUDI Wallet implementation presented in this work with infrastructures such as the European Blockchain Services Infrastructure (EBSI). By utilizing EBSI, our solution will gain access to its decentralized registries for live credential verification and revocation, realizing a hybrid trust model that balances regulatory compliance with robust privacy, interoperability, and user control.

Although designed for federated data trading, the contributions of this work are broadly applicable. The IAM system with user-friendly fine-grained access control can support secure IDM in domains such as healthcare, finance, or public administration. The APE enables domain experts across sectors to define and manage complex authorization rules with ease. Finally, the integration of eIDAS-based authentication and the EUDI Wallet ensures high-assurance, cross-border interoperability relevant to any regulated sector.