A Data Disclosure Agreement (DDA) enables automated agreement handling for data exchange between a Data Source (DS) and Data Using Service (DUS). It helps organisations to continue leveraging their data assets while being transparent and legitimate in their data usage. Automated agreement handling is a requisite for a scalable and regulatory-compliant data marketplace… It also provides individuals control over how their data is used and exchanged.
It aims to enhance data governance to increase transparency and authenticity as critical elements for digital trust. This documentation describes the overall process how organisations can dynamically build trust in a dataspace or a data ecosystem, including the key actors involved.
Data Disclosure Agreement lifecycle actors
These actors are involved in the Data Disclosure Agreement lifecycle.
| Actor | Description | SSI Role / Other names |
|---|---|---|
| Data Source | The organisation collecting personal data and storing it | Issuer or Data producer |
| Data Subject | who can manage their preferences and follow their data, should know who is consuming what, when and why. | Holder |
| Data Using Service | The organisation processing personal data from one or more data sources to deliver a service. | Verifier or Relying party or Data consumer |
Additionally, there are two more actors participating in the data agreement lifecycle.
| Actor | Description |
|---|---|
| Assessor | The individual who reviews the practices of an organisation (data source or a data using service), conducts a DPIA and drafts data agreements and inter-company agreements for third parties |
| Auditor | The individual who may be called in to review the data agreements and ensure they are in place in case of data breaches or regular inspection handled |
| Data marketplace | The platform in a dataspace where organisations (DUS) can discover the data sources, and get into a trust relationship. Here the DS offers their data to potential DUS’. |
Data Exchange Agreement overview
Figure 1 below illustrates a typical scenario where an organisation, Org. A, uses a DA to share data externally to Org B and Org C. Individual instances of the DA are signed by individuals X and Y. A DDA is used to govern the data exchange between Org A and Orgs B and C.
Figure 1. Data exchange and provenance scenarios
Data Exchange Agreement (DEXA) high-level workflow
As described in the background section, iGrant.io provides a decentralised data exchange service based on self-sovereign identity (SSI), OpenID Connect and OAuth protocols. The service enables organisations to exchange data in a transparent, secure and privacy-centric manner using verifiable data exchange agreements. The received data can be verified using SSI and X.509-based signatures. A DEXA workflow involves the following phases as illustrated below:
Figure 2. Different phases of DA and DDA lifecycle
These different phases are explained below:
Definition: An existing agreement template is adopted as is or new ones are formulated in this phase. The template could be based on a particular industry and/or sector-specific practice. This can then be used by any organisation (DS or DUS) for a particular data usage purpose, in our case for enabling third party data exchange.
Preparation: An organisation creates an agreement based on a DPIA or similar and shares it with relevant parties . For a DA, the relevant counterparty is the individual while for the DDA, it is a DUS.
Capture: The counterparty signs the agreement in this phase. For a DDA, it is countersigned by the DUS while for a DA it’s the individual.
Proof: Any organisation or individual is able to demonstrate that an agreement exists between the parties. Independent auditors can also check that records are in place proving that the individual's personal data may be processed (e.g. as per GDPR Article 30).
DEXA workflow enabling data provenance
The four phases described above are further elaborated in Figure 3 and explains how the DAs and DDAs are interlinked in the DEXA workflow. To ensure their compliance with data regulations, each organisation is encouraged to perform a privacy risk assessment or DPIA and ensure that risk mitigation measures are in place before collecting and processing personal data.
Figure 3: DA and DDA interlink within DEXA workflow
When a DDA is signed and personal data has been exchanged, the DS is not liable for the DUS's use of personal data. However, the obligation to monitor the individual’s consent to share data with a third party, in this case, the DUS, remains with the DS. The DUS is obliged to adhere to the terms laid out in the DDA. If the DUS does not adhere to the DDA, the DS can, upon finding out about the infringement, withdraw the DDA and consequently revoke all the DAs associated with the DDA.
Throughout the DA lifecycle, cryptographic proofs are generated detailing who created the DA during the preparation phase and who signed it during the capture phase [2]. This is based on a W3C (DID:mydata) specification [4] and realised via a Data Agreement DIDComm protocol [5] implementation.
The key activities and actors involved in each phase are summarised in the table below:
| # | Activity | Phase | Actors |
| Assessment | |||
| 1.0 | Perform DPIA or similar privacy assessment (external or self-assessment) Output: DA template consisting of usage purpose, data attribute etc as per the DA schema | Definition and preparation | Assessor, DS, DUS |
| For DS: Lawfully expose data and demonstrate provenance | |||
| 2.1 | If the organisation wishes to expose personal data to a third party, it creates the DDA offer, If required, publishes to a data marketplace Output: DDA is available and is ready for any DUS to sign. Provenance: action to create an entity (DDA) by an actor (DS). | Definition and preparation | DS |
| 2.2 | Add DUS when they sign up Output: DDA is updated with the DUS signatory info (during the DDA capture phase) Provenance: action to update and sign off entity (DDA) by an actor (DUS) | Capture | DUS |
| 2.3 | Any interested party can check the signed DDA proof of compliant data usage. Provenance: Query to view provenance metadata | Proof | Auditor, Individual, DS or DUS or any 3PP |
| 2.4 | Automated enforcement of DDA Provenance: query provenance metadata to ensure the signing of DDA is permitted | Proof, Capture | DS, DUS |
| For DUS: Lawfully consume data and demonstrate provenance | |||
| 3.1 | If the organisation (DUS) wishes to consume data, it checks the available DDA offers in the marketplace. | Definition and Preparation | DUS |
| 3.2 | Organisation (DUS) signs up (Same as step 2.2) | Capture | DUS |
| 3.3 | DUS updates and register the DA based on the DDA | Definition and Preparation | DUS |
| 3.4 | Any interested party can check the signed DA proof of compliant data usage | Proof | Auditor, Individual, DS or DUS or any 3PP |