§ Data Disclosure Agreement (DDA) Specification

Specification Status: version 1.0.0

This is reviewed and implementation has started. This spec is live and is being iterated as part of the PS-SDA project in NGI-ONTOCHAIN. The project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 957338.

Latest Draft: Avaialble here

Editors:

• Mr. George Padayatti (iGrant.io, Sweden)
• Mr. Jan Linquist (Linaltec, Sweden)
• Mr. Lal Chandran (iGrant.io, Sweden)

Contributors and Reviwers:

• Dr. David Goodman (iGrant.io, Sweden)
• Ms. Lotta Lundin (iGrant.io, Sweden)

Participate:

• GitHub repo
• File a bug
• Commit history

§ Abstract

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.

§ Introduction

Data is the ​critical currency of an advanced digital economy, and trust is fundamental for continuous access to personal data. An adequate governance framework is essential to build the requisite trust and must involve, at the very least, the following actors:

• Individuals, who can manage their preferences and follow their data, should know who is consuming what, when and why.

• Organisations, which are either a DS or a DUS, should be able to leverage personal data and gain access to the right quality data, provided that:

  • they offer adequate transparency for individuals to trust them.
  • their data usage is compliant with the relevant data protection and privacy regulations which they can prove if requested.

• Auditors, who can independently prove fair data usage via independent audit mechanisms, can be used by organisations and individuals to ​verify the legitimacy of their claims in any legal dispute concerning the use or misuse of data.

Any organisation undergoing digital transformation needs to ensure that it can cater to the above, so individuals continue to say “yes” to sharing their data. Initiatives like MyData Operator and the proposed EU Data Governance Act point to the need for data intermediaries ​to enable the above for individuals and businesses.

Data exchange agreements aim to enhance data governance to ​increase transparency and authenticity as ​critical elements for digital trust. This specification describes how the key actors above can capture, view or disclose the provenance trail of a personal data exchange transaction​,​ starting with ​creating data disclosure agreements during any such data exchanges. It also specifies how a DS can define rules for data processing (to demonstrate regulatory compliance etc.) in a data exchange transaction.

§ Data intermediaries enabling data exchange

iGrant.io is a data exchange platform that helps organisations access personal data in a sustainable and human-centric manner. Using iGrant.io’s data exchange services, organisations gain access to verifiable, auditable and data regulatory compliant personal data. Every data exchange transaction has an associated DA that records conditions for an organisation to process personal data in accordance with data regulations, such as the GDPR and the Data Governance Act, as illustrated in Figure 1 below.

Figure 1. A data exchange ecosystem using a data intermediary

§ Data exchange agreement landscape

In a data exchange ecosystem, there are a number of agreements that are required to legally validate data exchanges. This chapter introduces various Data Exchange Agreements (DEXA) and the relationships that exist between organisations and individuals, depending on their roles in different personal data usage scenarios. The various agreements involved can be classified into four broad categories as shown in Figure 2 below. These are agreements between:

1. An individual and an organisation,
2. Two organisations (DS and DUS),
3. An organisation and its supplier and
4. Two individuals

Figure 2. Data exchange agreement landscape

§ Data Agreement (DA) or Personal Data Agreement

This is an agreement between an organisation and an individual when it comes to the use and processing of personal data. A data agreement can have any legal basis as outlined by the relevant data protection regulation. The agreement can be with a DS (issuer) or a DUS (verifier) and can also be used for personal data exchange with third parties.

Today, the DA is implemented via a W3C specified Decentralised Identifier (DID) DID:mydata. It records the conditions for an organisation to process personal data in accordance with data protection regulations. Regulations could be data laws or they could be norms such as the MyData principles.

The key characteristics of a DA are as follows:

• It is associated with any personal data usage including data exchange
• It has the ability to rely on an individual’s consent or other lawful basis such as contract, legal obligation, vital interests, public task and legitimate interests by outlining the purpose for which personal data is to be processed
• It is tied to a data protection impact assessment (DPIA) that further strengthens legal compliance for the organisation. iGrant.io automates the conversion of the results of a DPIA to a machine-readable DA
• It is standardised via ISO/IEC JTC 1/SC 27 Information security, cybersecurity and privacy protection WG5: 27560 (working draft)

The key commercial values enabled by a DA are described below:

Data regulatory compliance: A DA based on a DPIA provides reassurance that the organisation has the intent to exchange data in compliance with a jurisdiction appropriate data protection regulation.

Transparency: A DA provides the requisite transparency to a data subject on how personal data is to be used by an organisation, especially if exchanged with third parties.

Auditability: With a DA, a DS can prove its legitimate right to collect and share data with a DUS via digital token-based verification system. Similarly, an individual can dispute data usage for which no legitimacy can be proven using the signed DA.

§ Data Disclosure Agreement (DDA)

A Data Disclosure Agreement (DDA) exists between two organisations where one organisation acts as a DS and the other as a DUS. The DDA captures how data is shared between the two organisations and what role and obligation each party has, as either a data processor and/or a data controller. For any organisation involved in the data exchange, there is an associated DA that explains the purpose of processing personal data, what personal data is collected, what the data subject rights are, etc. Where both organisations are data controllers, the individual (data subject) has a signed DA with both.

§ Data Processing Agreement (DPA)

The third form of an agreement exists between an organisation and its suppliers, as illustrated in Figure 2. Here, there is a vertical relationship between Organisation A as a data controller and its supplier as a data processor or sub-processor. For a higher level of accountability between these organisations, a DPA is set up, which lays out what routines are required to be in place: for example, a data processor’s obligations in case of a data breach or how the rights of the individual, such as access rights, are supported, among other policies and routines. An auditor should also be able to inspect the organisation and use the DPA as reference material during the inspection. As depicted in Figure 2, the DPA is connected to the individual at the top of the hierarchy via the data controller organisation.

The concept of a DDA can be extended to include the DPA as well. This, however, is not within the scope of this project. For details on the DPA and its content please refer to Appendix C.

§ Delegation Agreement

The delegation agreement is included to complete the data exchange ecosystem. A delegate may act on behalf of an individual in signing off any data exchange. There are several scenarios where delegation is necessary for example in the case of guardianship when an individual is not capable of signing off or in case an individual is given temporary rights to sign off on behalf of the individual for example purchasing medicine at a pharmacy.

§ Data provenance

W3C defines provenance as the information about entities, activities, and agents involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness.

Figure 3. Data provenance terminology

There are different models that can be used to achieve data provenance. This includes the Open Provenance Model (OPM) and W3C PROV. Both these models have basic entity, activity and agent (people) components. The difference comes with W3C PROV providing additional terms to help with explaining the details of activity through the usage of “plans”. These plans set the details of the execution of an activity.

In the context of a personal data exchange transaction, the agents are the actors involved in the personal data exchange transaction like the individuals (or data subjects) and organisations (DS and DUS), entities are the data being exchanged. The activities include create/read/update/delete (CRUD) operations on these agreements and will be further elaborated in this document. The model in Figure 3 is taken from the W3C PROV Primer to illustrate a high-level overview.

In a personal data transaction, provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility and the re-use of personal data. Once this is achieved, assertions could be made with regard to the use of contextual metadata (e.g. events in data agreements and data disclosure agreements) and can themselves become important records with their own provenance. Once provenance metadata is collected it is possible to check claims that are being made in the records.

§ Data Exchange Agreement overview

Figure 4 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 4. Data exchange and provenance scenarios

§ 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 stages as illustrated in Figure 5:

Figure 5. DA and DDA workflow

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 6 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 6: 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:

§ Publish and Sign DDA sequence diagram

Figure 7: DDA - Publish and sign sequence

§ Data Provenance

Appendix D in this specification provides a detailed ontology analysis of what needs to be captured in a provenance trail. A DDA schema (Ref. chapter Ontologies) is proposed and the existing DA schema has been updated to include the key elements required to establish data provenance when making the data available for third parties. By combining information from the DA and the DDA, a provenance trail can be generated to provide reassurance about the legitimacy of owning, trading or controlling copies of the data. With the usage of digital signatures, provenance trails are tamper-evident logs, which means you can cryptographically prove that data hasn’t been unexpectedly changed. A verifiable provenance trail helps in realising the accurate, immutable and verifiable history of activity and entity.

Scenario 01: Here DS and DUS do not need individual identity proof before the data exchange e.g. in the case of a DUS using anonymous or pseudonymous data sharing to offer personalised services.

Figure 8 elaborates on how the provenance is captured during a data exchange transaction in Scenario 01 where there is no need for identity proof (E.g. Anonymised data exchange).

Figure 8: Scenario 01: DA, DDA workflows without ID proof (E.g. anonymised data exchange)

Scenario 02: DS and DUS require individual identity proof before the data exchange. This is the case, for e.g., during a registration process, check-ins, covid-credential exchange etc. This is illustrated in Figure 9.

Figure 9. Scenario 02: DA, DDA workflows with ID proof

§ On-chain and off-chain agreements for provenance trail

A DDA can be realised as a smart contract adding the key advantages of using a blockchain. The key considerations for the design of the PS-SDA blockchain-based solution are:

• Authenticity - Enabling verified agreements source and ownership
• Scalability - Can store large amounts of data at low-cost
• Proof of membership - Makes it easy to prove if a data disclosure agreement transaction occurred or not, e.g. signing, counter signing, data exchange without revealing PII data.
• Tamper resistance - Allows checking that data hasn’t been altered
• Availability of transaction data - Allows for immediate access to any transaction. The blockchain confirmation times [12] of mainstream blockchain are slow. E.g. the proof of work consensus mechanism in Bitcoin is 10 minutes while for Ethereum it is 2 minutes.

During a DDA capture process, the signing transaction is registered on the chain to enable provenance. The solution will leverage features offered by ONTOCHAIN to develop and deploy a smart contract to facilitate seamless data exchanges between two organisations.

§ Publish to the marketplace via a DLT

During the creation of the data disclosure agreement, the DS creates a token of ownership for the DDA offer and registers it to the blockchain. The DDA offer is stored in the (Inter Planetary File System) IPFS. The signing process is facilitated by a data intermediary service, such as iGrant.io, which acts as a notary and registers the signed DDA evidence (hash) to the blockchain.

Figure 10. Publishing of DDAs by DS in the blockchain ecosystem

The DS and the DUS do not need to understand the underlying witness system and cost mechanisms of using a DLT, e.g. Ethereum, bitcoin etc. The use of data intermediary service also reduces the costs associated with the footprint on the blockchain and solves the key issue of trust, e.g. who’s signed DDA do you trust?

The transaction data is on-chain as per chapter “Ontologies/ On-Chain Data”, with the ownership of the DDA and event signature needed for data provenance. The DDA offer is stored in the IPFS.

§ Countersigning of DDA offers by the DUS via a DLT

Any DUS can view what data DSs are offering to share, negotiate new terms and eventually sign a DDA and use the data based on the terms set in the agreement as shown below.

Figure 11. Countersigning of DDA by DUS in the blockchain ecosystem

§ Off-chain and On-chain handling of data disclosure agreements

As illustrated in Figure 11 above, once the DDA is prepared, the DDA offer (by the DS) is published in the marketplace by the Data Intermediary. The Data Intermediary awaits the signed DDA (by both DS and DUS) before anchoring it to the DLT. The data intermediary waits for the countersigned DDA from the DUS(s) and anchors it to the DLT. The detailed mechanism involved in anchoring (via a smart contract) to the underlying witness system (e.g. DLTs like blockchain, hash graphs) taking into account the key considerations (in chapter 3.2] is as pictured below Figure 12.

Figure 12. Anchoring DDA transactions to a witness system, e.g. DLT

The DDAs are always stored in local storage, a copy of which is available with the signing parties and the data intermediary. The hash of the DDA offer (Hash (1)) forms the bottom leaf of the Merkle tree. Hash (2) represents the hash of the signed DDA when it is published to the data marketplace while Hash (3) represents the countersigned DDA. At a given point in time, the root hash from the Merkle tree is added to the DLT.

§ Handling release of personal data

When the actual exchange of data happens from the DS to the DUS, an event and a corresponding proof is appended to the Data Disclosure Agreement. This provides for data exchange provenance to any interested parties.

§ User stories and use case analysis

§ Individual

§ Auditors

§ Detailed design specification

§ Architecture diagram

The DEXA functions are available as microservices that can be plugged into existing systems, such as in iGrant.io SSI data exchange workflows. The core components are exposed as RESTFul APIs. The components can exist independently in any service provider agreement handling system. Here, the DA registry holds the signed DA records. In PS-SDA, we will add the DDA registry, as shown in Figure 13:

IMAGE Figure 13. DEXA microservice components

In Figure 13, the agreement records can be both DA and DDA records. Together with the JSON-LD processing components, DA and DDA, all exposed as RESTFul APIs, form the core component in the DEXA architecture. The pluggable components could be replaced with any chosen implementation mechanisms.

§ High-level software quality analysis

The project uses a DevOps process with established CI/CD practices. Quality assurance is via manual and automated tests by the development team. Validations are carried out by the product owners and signed off during each sprint.

§ APIs for SDKs

No SDKs are required for the DDA implementation. Existing DA SDKs will be reused and be revised to support new flows.

§ Rest APIs for Services

The key interfaces are APIs classified under the key actors listed below. An early version of the DEXA APIs is published at the iGrant.io swagger API hub.

§ Individuals

§ Organisations (DS and DUS)

§ Auditors

§ Ontologies

§ Data Disclosure Agreement

§ Data Agreement

The existing DA schema (v1) is updated to include the following:

• The events with additional states to take care of third party data exchange handling
• DA revocation list
• DA expiry date to refetch the data based on the rules set by the DS

§ On-Chain Data

Only the DS/DUS DIDs and the root hash value based on the Merkle tree of the DDA/DA is stored on chain.

§ Interoperability

Work in progress

§ Appendix A: References

[1] Automated Data Agreements (Linaltec, iGrant.io and PrivacyAnt with NGI eSSIF-Lab)

[2] Lundin, L and Chandran, L, Lindquist, J: Data Agreement Specification

[3] Lindquist, J: (ISO Standards editor) Information technologies — Consent record information structure, ISO/IEC 27560 (working draft)

[4] Data Agreement DID Method Specification, Available at: https://github.com/decentralised-dataexchange/automated-data-agreements/blob/main/docs/did-spec.md [Accessed: 13-Jan-2022]

[5] Data Agreement - DIDComm Protocol Specification, Available at:https://github.com/decentralised-dataexchange/automated-data-agreements/blob/main/docs/didcomm-protocol-spec.md [Accessed: 13-Jan-2022]

[6] iGrant.io Data Wallet: https://igrant.io/datawallet.html [Accessed: 13-Jan-2022]

[7] The Open Provenance Model core specification (v1.1), Available: https://www.sciencedirect.com/science/article/abs/pii/S0167739X10001275 [Accessed: 13-Jan-2022]

[8] W3C PROV-Data Model: https://www.w3.org/TR/2013/REC-prov-dm-20130430/ [Accessed: 23-Feb-2022]

[9] W3C PROV-O: The PROV Ontology, Available at: https://www.w3.org/TR/prov-o/ [Accessed: 23-Feb-2022]

[10] W3C PROV Model Primer, Available at:https://www.w3.org/TR/prov-primer/ [Accessed: 23-Feb-2022]

[11] The OPM Provenance Model (OPM), Available at: https://openprovenance.org/opm/ [Accessed: 23-Feb-2022]

[12] Ethereum whitepaper: https://ethereum.org/en/whitepaper/ [Accessed: 01 April 2022]

§ Appendix B: Glossary

§ B.1 Abbreviations

§ B.2 Terminology

§ Appendix C: Data Processing Agreement (DPA)

Processing personal data on behalf of another organisation requires a Data Processing Agreement (DPA). The one processing personal data is a data Processor, and the one using the services of the data processor is the data controller. The DPA is required to ensure that when something goes wrong, there are steps to address, for example, a security incident. Guidance for creating a “Data Processing Agreement” is based on GDPR Article 28 and can be summarised in the following list:

• Processing only on the controller’s documented instructions (Article 28(3)(a))
• Duty of confidence (Article 28(3)(b))
• Appropriate security measures (Article 28(3)©)
• Using sub-processors (Article 28(3)(d))
• Data subjects’ rights (Article 28(3)(e))
• Assisting the controller (Article 28(3)(f))
• End-of-contract provisions (Article 28(3)(g))
• Audits and inspections (Article 28(3)(h))

Below is a DPA template from the Danish Data Protection Agency (Datatilsynet) which is endorsed by the EDPB. These sections are the relevant ones to this analysis.

1. Table of Contents \
2. Preamble \
3. The rights and obligations of the data controller \
4. The data processor acts according to instructions \
5. Confidentiality \
6. Security of processing \
7. Use of sub-processors \
8. Transfer of data to third countries or international organisations \
9. Assistance to the data controller \
10. Notification of personal data breach \
11. Erasure and return of data \
12. Audit and inspection \
13. The parties’ agreement on other terms \
14. Commencement and termination \
15. Data controller and data processor contacts/contact points \

Included in the template are three appendixes that need to be filled out.

Appendix, A Information about the processing
Appendix B, Authorised sub-processors
Appendix C Instruction pertaining to the use of personal data

§ Appendix D: Data provenance - Ontology analysis

**Provenance Models and provenance metadata: **Different provenance metadata models were evaluated to determine the model that best matched the requirements to support DAs. The models that were analysed were the Open Provenance Model (OPM) and W3C PROV. Both have the basic components of entity, activity and agent (people, organisations and devices). W3C PROV provides additional terms to help explain the execution details of a particular activity by using “plans”.

To capture the provenance metadata in a data exchange, it is necessary to understand the complete lifecycle for populating, capturing and updating the metadata. The below list of terms describes the provenance metadata required for a fully functioning data exchange ecosystem (W3C PROV primer) and analyses how it is today address within the DA DDAs.

The table below provides an extension to the provenance metadata, outlined in the table above, and is introduced in W3C P-Plan Ontology to add further granularity.

§

§ Appendix E: Ontology analysis

§ E.1 DA and DDA Ontology

§ E.1.1 Legal prose builder

To capture the contractual obligations between organisations in a data exchange ecosystem, a governance framework is suggested regarding legal documents for the DS or DUS. The legal documents required typically do not change over time and are frequently copied; therefore, templates can be created with fixed input to populate information like organisation address, duration of the agreement, etc. A legal prose builder is introduced based on work from CommonAccord.

CommonAccord is an initiative to create global codes of legal transactions by codifying and automating legal documents, including contracts, permits, organisational records, and consents in any language. It has two repositories: one for the reference legal documents templates and a repository with the input to the templates similar to a DA record. The input will be called a DDA/DPA record. An example of an “Intra Group Data Transfer Agreement” can be found in CommonAccord. Section 3 in the model has text for data transfer between data controllers in a DDA, and section 4 has text for a DPA. These examples will be modified to European requirements.

§ E.1.2 DDA/DPA record

The DDA/DPA record will capture the requisite input fields to the agreement template. Below is an example of the content of the record.

• Organisation name and address
• Contact information
• Duration of the agreement
• List of purposes categories for processing personal data
• Location personal data is stored
• Retention period
• List of personal data categories to be processed

Many fields in the record are similar to the DA. It is important to use the same ontology between the two in order to be able to automate any controls required. For example, if a DUS uses personal data that is not in the DDA or for a different purpose than specified, the system can block the DA from being able to be registered by the DUS. In theory, if any DUS infringement occurs, there is a means to automatically revoke the DA or at the very least block new ones from being created during the arbitration. A classic example that would benefit from this solution is Cambridge Analytics’ relationship with Facebook. Cambridge Analytica would be required to set up a new DA with the data subject. If Cambridge Analytica tried to use personal data outside the stated purposes, the DDA would kick in and block that attempt.

§ E1.3 DDA and DDA attribute mapping

A key aspect that needs to be understood when populating the DA or DDA is what fields must be filled and how they may be used for automated enforcement policies. The automated enforcement policies are numbered in the policies column. This table was used to arrive at the ontology described in 5.6 Ontologies.

*() indicates optionality or condition (1) - Can support certification

§ E.1.4 Provenance metadata relation with the ledger

All DS disclose what data they are ready to expose in the data exchange ecosystem by publishing their DDA offer(s). Each DUS can decide if their signed DDA i.e. what personal data they are consuming should be published or not.

No personal data shall be stored on the ledger. Even a hash value that may correlate with a data subject like a decentralised identifier is considered identifiable and is marked as sensitive. Personal data will be off-ledger. In order to make the DA verifiable or auditable in iExec confidential computing, a smart data agreement (SDA) is required.

§ E.2 Privacy ontology vocabulary

The provenance metadata requires a privacy ontology vocabulary in order to have the same interpretation of the terms used across implementations. The privacy ontology will be based on W3C Data Privacy Vocabulary [DPV] which enables expressing machine-readable metadata about the use and processing of personal data based on legislative requirements such as the General Data Protection Regulation [GDPR].

The core concepts in DPV represent the most relevant concepts for representing information regarding the what, how, where, who, why of personal data and its processing. Each of these concepts is further elaborated as a taxonomy of concepts in a hierarchical fashion. The DPV provides the following as ‘top-level’ concepts and relations to associate them with other concepts (only the ones relevant to this specification are listed, for other classes refer to DPV):

Foot Notes Work in progress to convert footnotes to references

[^1]: EU GDPR: https://docs.igrant.io/regulations/reg-eu-gdpr

[^2]: W3C DID Registry: https://www.w3.org/TR/did-spec-registries

[^3]: DID:MyData Specification

[^4]: Automated Data Agreements: https://github.com/decentralised-dataexchange/automated-data-agreements

[^5]: ISO/IEC AWI TS 27560 Privacy technologies — Consent record information structure