How MyData Passport works under the hood

1. Overview

MyData Passport is a user-centric control panel for personal data. It lets individuals see which organisations hold their data, trigger legally valid requests (access, deletion, portability) and track verifiable evidence of what happened. Under the hood, it is a federated architecture that avoids centralising raw personal data and focuses instead on secure orchestration and tamper-evident logging.

The platform aligns with key European regulations:

• GDPR – operationalising data subject rights (Art. 15-21)
• Data Act – enabling fair access and portability for IoT/service data
• AI Act – supporting transparency and oversight for high-risk AI
• eIDAS 2.0 / EUDI – strong, cross-border identification and mandates

2. High-level architecture

At a high level the system is split into three trust zones:

• Identity zone – eIDAS / EUDI-based identification, authentication & mandates
• Processing zone – rights orchestration engine and controller integration layer
• Encrypted storage zone – evidence vault and immutable compliance logs

The platform is deliberately API-first and federated: it orchestrates rights and evidence, but does not try to become a giant central data lake of all personal data.

3. Core components & standards

3.1 Identity & Mandates (Identity zone)

Users authenticate using their national eID or the European Digital Identity (EUDI) Wallet. Technically this is implemented with OpenID Connect (OIDC) or SAML 2.0 flows on top of the eIDAS trust framework. The wallet provides high-assurance identity assertions and can also carry mandate credentials (e.g., “this user is authorised to act on behalf of X”).

Identity assertions are passed to MyData Passport as signed tokens (JWT/SAML) and verified against eIDAS trust lists. Once validated, a short-lived session is established; all subsequent rights requests are tied to this verified identity.

3.2 Rights Orchestrator (Processing zone)

The Rights Orchestrator is the “traffic control tower” for all Data Subject Rights (DSR) requests. It:

• accepts requests from the UI/API (e.g. “Access my data from Acme Bank”)
• standardises them into a machine-readable format (JSON / JSON-LD)
• routes them to the relevant data controllers via integration connectors
• tracks state, deadlines and responses
• emits evidence events into the vault at every key step

The orchestrator is built as a stateless microservice with strict zero-trust boundaries: it authenticates to each controller with dedicated credentials, assumes every network call is untrusted by default, and never stores raw exports long-term.

3.3 Controller Integration Layer

Controllers are connected using a small set of integration patterns:

• REST APIs – preferred path; supports standardised DSAR endpoints where available
• Federated data networks – via sectoral data spaces or operator networks
• Secure email/portal flows – for controllers that are not yet API-enabled

Each connector runs in isolation, with mutual TLS and strict rate-limiting. Responses (data exports, confirmations) are streamed directly to the Evidence Vault / user session and not retained unnecessarily.

3.4 Evidence Vault (Encrypted storage zone)

The Evidence Vault is an append-only, tamper-evident log of all DSAR-related events: requests sent, acknowledgements, responses, deletions, and user downloads.

Technically, it can be implemented as:

• an immutable log with cryptographic chaining (hash of previous entry), plus
• optional anchoring on a permissioned blockchain such as EBSI to timestamp batches
• entries encoded as Verifiable Credentials in JSON-LD for independent verification

All payloads are encrypted at rest; public anchoring only publishes hashes and non-personal metadata. The vault provides role-based query APIs so regulators, DPOs and users can generate audit-ready reports per case.

4. Key process flows

4.1 User authentication via eIDAS/EUDI Wallet

In short:

• User selects Login with EU Digital Identity in the web app.
• EUDI Wallet performs high-assurance authentication and issues a signed identity token.
• MyData Passport verifies the token against eIDAS trust anchors and opens a session.
• Optional: mandate credentials are presented if the user acts for someone else.

4.2 DSAR creation and orchestration

The typical access/deletion request runs through these phases:

• Create – user selects a controller, request type, and identifiers; submits the request.
• Dispatch – orchestrator builds a structured DSAR and sends it via the appropriate connector.
• Process – controller verifies identity and executes the request in its internal systems.
• Return – controller sends back data or confirmation; the user is notified.
• Log – all steps are captured as signed events in the Evidence Vault.

4.3 Evidence logging and audits

Every significant event yields a verifiable log record. These can be queried by:

• Users – to see their personal history and download proof per request
• DPOs – to export all DSARs handled within a time window for their organisation
• Regulators – to investigate complaints or run systemic analyses on response times

5. Persona views

The same architecture serves different stakeholders with different value propositions:

6. Conclusion

MyData Passport turns European data protection law into a concrete, operational architecture: eIDAS-backed identity, federated rights orchestration and an encrypted evidence vault for accountability.

It is intentionally user-centric (simple flows for citizens), controller-friendly (standardised DSAR intake & response) and regulator-ready (tamper-evident logs and KPIs), making it a practical blueprint for a trusted personal data intermediary in the AI era.