Skip to main content

MyData Operator reference model

The MyData operator reference model describes nine core functional elements of operators as illustrated in the figure below (Reproduced "as-is" from MyData Operator paper[3]). These elements either independently or collectively make it possible to utilise personal data in a transparent and human-centric manner and support interoperability between data operators via open and standardised interfaces.


These functional elements are selected elements for inclusion in the reference model based on the criteria that they are relevant in the context of MyData and are directly valuable to individuals. Not all operators will have all functional elements - it is not intended as template for a single, complete implementation. OpenAPIs are classified as per the MyData Operator functional elements and is published at:

Identity management

The identity management handles authentication and authorisation of individuals and organisations using the data exchange and verification services. The supported user roles are owners, admins, developers, auditors, verifiers and DPOs. IDM is implemented using the Keycloak open-source IAM platform - see which offers OpenID connect / OAuth 2.0 protocols and end-points. It provides functions to federate different identity solutions compliant with OpenID Connect/OAuth2.0 and SAML, compliant with Web 2.0 standards. For example, the Data Source and Data Using service could be using different national identity solutions. In Sweden, the solution already integrates with BankID and the intention is to integrate with other national ID systems including eIDAS.

The solution also enables self-sovereign identity via the use of decentralised identifiers (DIDs) with a DID Registry and Verified Credentials (VC), all as per the Web 3.0 (W3C specification).

Permissions and consents

Permission management enables human-centric control of personal data where individuals can view, grant, revoke, and modify different kinds of permissions related to data flows. It enables individuals to manage and have an overview of data transactions, interactions and to execute their legal rights (e.g. as per GDPR).

Being a consented data exchange platform, permission management is a foundational component in This is released via the concept of "Data Agreements" (DA) that records the conditions for an organization to process personal data in accordance with privacy regulation (e.g. GDPR) captured in a signed receipt given to the individual.

Using services, organisations can manage DAs and its lifecycle. With a DA, an organisation can be transparent about what data is being used and based on what lawful basis the data is processed, e.g. contract, legal obligation, vital interests, public task, legitimate interests and consents as per Article 6 in the GDPR. Using the DA, the individual is able to transparently view all different usage purposes for which their personal data is used. For data exchange with consents, the individual can opt-in/opt-out to any purpose, down to the attribute level. The Data Agreement is based on standards like Kantara. It's being enhanced to cater towards granular consents and is being standardised via ISO27560 and via DIF (Decentralised Identity).

The typical end to end use case for enabling permissions and consents in is described below:

  1. Organisation (admin) registers their data model and configures the data agreement that consists of the usage purpose, the data attributes used by the ageement, legal basis, data policy configurations etc. In this case, the legal basis for the data agreement is "Consent".

  2. The org publishes the purpose to its individual users.

  3. The individuals are able view at the relevant granularity levels (aka attribute level e.g. name, phone number) respective data. It allows individuals to exercise their rights (their data subject rights as per GDPR Article 12-23) and they can opt-in and opt-out of any data usage at various granularity levels, where consent is used as a lawful basis. This can be done in real-time.

In the use of Data Agreement with consent as the legal basis, complies to Kantara and emerging ISO standards for Data Agreement (or consent) receipts.

With, an organisation can be transparent about what data is being used and based on what lawful basis the data is processed, e.g. contract, legal obligation, vital interests, public task, legitimate interests and consents as per Article 6 in the GDPR. The individual is then able to transparently view all different usage purposes for which their personal data is used. For data exchange with consents, the individual is able to opt-in/opt-out to any purpose, at the attribute levels.

Service management, as a MyData Operator or Data Intermediary, operates in an ecosystem with Individuals, Data Sources and Data Using Services. In order to navigate this ecosystem, the various actors are linked through the service registry. Service management onboards the various actors within the ecosystem. The human-centric manifestation of service management is the possibility for individuals to manage the relationships and connections to different data sources and data using services in the ecosystem. enables a multi-operator environment via a distributed service registry at two levels: one at the individual level, the other at the organisational level.

In figure above, A, B and C are organisations (Data Sources and Data Using Services) while the dotted circle represents the ecosystem and the governance framework facilitating data exchange via the use of data agreements. has filed an international patent on facilitating a consented data exchange.

Organisation level

For organisations, it involves the controller and processor agreement handling as part of a data ecosystem. This includes functions like organisation onboarding/provisioning, managing organisation users, adding end users or consumers to organisation, data agreement handling between organisations and individuals for data exchange, data regulation and compliance management etc.

Individual level

For individuals, the service management function lies in enabling a decentralised application (dApp). This includes functions like registrations, user profile management, subscription to a specific organisation etc. Every use of personal data is handled via a Data Agreement.

Value exchange

A sustainable business model is a requisite for any ecosystem. In a MyData Operator ecosystem, this means that all of the actors in the ecosystem need to have more benefits than mere costs. Both benefits and costs can be also non-monetary in nature.

The current value exchange features focus on an end-user based licensing model helping organisations to be compliant with regulations while enabling data exchange. Enhanced value exchange offering is driven by specific customer cases and their business models. In our current offering, the platform has a fully auditable transaction model that builds the ecosystem for deriving value from a personal data exchange scenario in a lawful manner.

For individuals, time and effort spent can be a big cost and benefits often come in the form of services that makes their lives easier, for e.g. providing better convenience. As data operators provide technical infrastructure for making multi-party data transactions possible, they are in a natural position to keep track of such transactions for the purposes of payments and billing or creating other forms of rewards, such as loyalty and bonus points. Operators may provide a standard ‘accounting’ mechanism which transparently keeps a log of the data transactions so that the different parties in the ecosystem may use it as the base for payments between the parties. Using data as the means of payment and paying individuals for their data are contentious issues. platform keeps track of all data agreement transactions and data exchange. This can be accessed via respective APIs and the current model is to let organisations decide the value exchange model. The “monetisation” is dependent on the customer scenarios, for example, discounts for providing a consented sharing of personal data.

Data model management

Data model management, as an operator functionality facilitates translation of one data model to another with the target to enable scalability, interoperability, and re-usability.

In data exchange services, organisations define their data models via Data Agreements implemented via standardised protocols such as DIDComm and SSI Agents (E.g. Aries protocols stacks). Every data transaction has an associated auditable and verifiable Data Agreement that records conditions for an organization to process personal data in accordance with data regulations and are often formulated automatically following a Data Protection Impact Assessment (DPIA). It is captured as a signed receipt given to the individual. supports all CRUD operations on Data Agreements to enable services for managing data models for any organisation. It also supports the translation of one data model to another with the target to enable scalability, interoperability, and re-usability. The services are used for transparency, compliance, facilitating agreement handling between ecosystem players and exercising personal data rights in a standardised manner.

For more information on data agreements and related W3C standards, refer the Data Exchange open specs, contributed as part of European Union NGI-Trust eSSIF-Lab infrastructure project engagement.

Personal data exchange

Personal data exchange, facilitated by a MyData Operator, is key to data portability, as well as the access and re-use of personal data. This functionality realises the interfaces that allow data exchange between Data Sources and Data Using Services in a standardised and secure manner.

In the model, personal data transfers from a Data Source to a Data Using Service are endorsed via Data Agreements. Data agreements are based on different legal bases, (e.g. consent, lawful purpose, contract, legal obligation, vital interests, public task and legitimate interests etc). If they’re without consent, individuals will only have limited or no rights to withdraw the consent, however, the individual can still follow what data is processed and why. For more information on data agreements and related W3C standards, refer to the Decentralised Data Exchange open specs, contributed as part of European Union NGI-Trust eSSIF-Lab ADA project.

Data exchange can be of two types active and passive, depending on the individual’s involvement in real-time, 1) Active Data Exchange and 2) Passive Data Exchange:

Active Data Exchange

In an Active Data Exchange, the individual is actively involved in the exchange of data in real-time, for example via a Data Wallet. A Data Agreement is signed during any data exchange. This can further be of two types:

  1. Active Data Exchange using a Data Wallet: In this form of Active Data Exchange, the individual holds the data and uses the data to any Data Using Service.

  2. Active Data Exchange using notifications: In this form of Active Data Exchange, the individual is notified of a request to use their data by the Data Using Service and the individual agrees to a data exchange from a given Data Source.

The picture below illustrates the active data exchange with the use of a data wallet.

The complete scenario of an active data exchange with an interoperable Data Wallet is described in the following demonstration video.


Passive data exchange

In Passive Data Exchange, the data is exchanged between the Data Source and Data Using Service based on a Data Agreement that was mutually endorsed between the Individual and the organisations (Data Source or Data Using Service) involved.Here, facilitates the direct transfer based on a individual’s valid permission or consent (If consent is the legal basis for such transfer).

The picture below illustrates the active data exchange with the use of a data wallet.


With, a Data Using Service can engage in agreements with various Data Sources, facilitating the relationship between a data controller or data processor (as defined in the GDPR). takes a data minimisation approach to personal data transfer where only the consent and transaction logs are stored as well as identity data. does not store the actual data that is being exchanged.

Personal data storage

A Personal Data Store (PDS) helps individuals to gather, store, manage, use and share information needed to manage and organize one’s life better. It provides the individual tools to control what information is shared with whom and when. This data is originally issued by a Data Souces and helps data to be integrated from multiple sources in the individuals device – harmonising, using and re-sharing it under the individual’s control. platform client SDKs and a decentralised PDS (dPDS) Data Wallet that acts as data source for individuals. In the dPDS models, the individual aggregates and holds personal data from multiple Data Sources without storing it in the cloud. Using services, individuals can grant permission and transfer that data to any Data Using Service in real-time or otherwise. An individual's personal data can be exchanged between different organisations based on the individual’s preference and all transactions are fully auditable.

Although provides any data that can be added to a personal data wallet by the individual, as a platform, has a data minimalistic posture and stores only data relevant to identify a person (e.g., email ID and mobile number) and to federate that identity within an ecosystem. also stores an individual’s consent and various transaction logs which can also be reused as a data source if the individual so desires.

Using this model, Data Sources and Data Using Services are connected via the individual. This configuration reduces legal liabilities whilst enabling greater control to individuals. As the person with the PDS is technically in the centre of the data transactions, it can be considered also a highly human-centric approach for data transactions.

Governance support

A governance support framework helps mediate the relationships between people and organisations. The framework builds on the MyData principles, facilitates compliance with regulations and honours individual rights, supporting individuals, organisations as well as ecosystem partners. In, Data Agreements records conditions for an organization to process personal data.

The key governance aspects are:

  • Data Agreement between Data Sources and the individual with a set of governance mechanisms to ensure sustainable data usage and data exchange

  • Data is cryptographically signed and can be verified for its authenticity and origin

  • Every data transaction is associated with a cryptographically signed Data Agreement that can be traced, is tamper-proof and can be audited by independent third parties

  • Tamper-proof logging of all data agreements and data exchange enables multi-party trust handling via decentralised identifiers (DID) and verified credentials (VC)

Webhooks-based event dispatchers uses event-based dispatchers where organisations can configure their receiving payload URLs. Any user or other events will result in notification to the organisation that can be integrated as part of the IT workflow.

Event notifications provides organisations to issue notifications for specific events. This could be used to comply to GDPR during data breaches. These APIs can be integrated to an organisations to enable self governing notifications towards users as part of automating compliance.

Accountability and logging

Transparency and accountability are important principles and prerequisites in many legislations. Accountability can enhance assurance and logging can mitigate risks of misuse or unintended use. Logging is not the sole responsibility of the operators and has counterparts in data sources and data using services.

Accountability arrangements may flow from the rules and regulations in the underlying governance framework, but many proto-operators work without an explicit governance framework. Even in those cases, operators have to comply with the relevant legislation that often includes logging and accountability obligations. In general, governance implies some accounting obligations; but if no explicit governance applies, logging and accountability are still needed for auditability and transparency. provides logging of all data transactions in the form of signed data agreements. Organisations can opt to choose a DLT-based or non-DLT based immutable logging. Access logging, security logs and various other types of logs are stored and made available only for organisations. These logs are available in a decentralised manner (implemented via user and organisation agents) for both individuals and organisations. roadmap items include interoperability towards selected industry verticals. The target is to collaborate with organisations working with standards, such as the Trust Over IP decentralised semantics working group of which is a member. The ambition is also to be an active contributor in the MyData community towards achieving interoperability.