Table of Contents
<The key question being asked is how do we connect presentation exchange to the key motivations identified below? >
This document is divided into 3 main sections:
The data agreement process section is a high level view of the steps that take place when working with data agreements. Not all steps may apply to signing data agreements but are included to help understand what an organization wanting to support data agreements need to consider. For example definition of a schema and how to populate the data agreement prior to signing.
The data agreement schema section describes the details of the data agreement and content. All the fields are explained and also notion of an envelop to wrap the data agreement when signing.
The interoperability section describes how for each of the supported methods how data agreements are exchanged and signed. Important in this section is to establish the requirements to reach interoperability between different vendors.
example describe consent, DID, W3C etc.
<What are the key motivations of needing a data agreement? and what exists today?>
For any organisation, processing personal there are key reasons for introducing the concept of data agreement as part of regulating the use of personal data. As Lawrence Lessig has previously established (known as Lessig's "modalities of regulation", the Internet is regulated by multiple forces. The motivation for introducing Data Agreements could take a similar approach:
This provides a global perspective to Data Agreements and could potentially work across multiple jurisdictions, both in countries where stricter and sophisticated legal frameworks as well as where data laws are emerging or non-existant.
Regulatory compliance forms a key aspect of introducing data agreements (e.g. GDPR). In GDPR, the key articles that are taken as input are:
The second key driver is ethical norms that are prevalent in any society. These may be based on certain standards or ethical norms such as, e.g., MyData or FAIR Data Principles. s.
Data agreements are also influenced by standards and this section highlights some of those influencing the development of data agreement. Some of the ISO standards are mentioned and since it is generic to any regulation and not only GDPR then it will use their own terms. To get an introduction of those terms standard ISO/IEC 29100 (Privacy Framework) is a good start, it is also free.
The ISO/IEC 29100 standard provides a high-level framework for protecting personal data or personal identifiable information (PII) as defined in ISO standards. The standard helps specify privacy terminology, actors and roles in processing personal data, privacy safeguards requirements and reference to privacy principles which are frequently referred to by management standards.
An important aspect to provide a notice and get consent is the adherence to the privacy by design principles listed below. Each principle is reviewed if they should be communicated by an organisation to an individual (data subject in GDPR terms).
Privacy Principles | Communication with Individual |
---|---|
Consent and choice | Record of choice |
Purpose, legitimacy and specification | Clear expression of purpose |
Collection limitation | Explicit list of personal data used for specified purpose |
Data minimization | Similar to collection limitation but how implemented in a system |
Use, retention and disclosure limitation | Explicit indication of retention period for collected personal data |
Accuracy and quality | Not applicable |
Openness, transparency and notice | Notice of purpose and transparency of the communication |
Individual participation and access | How to exercise privacy rights by individual |
Accountability | Not applicable |
Information security | Informing individual of potential privacy risk |
Privacy compliance | Demonstration of privacy regulation compliance for increased trust |
The ISO/IEC 29184 standard specifies the controls that set the structure of online privacy notices and getting consent.
The standard will further be elaborated in the data model section.
The ISO/IEC 27560 standard specifies the structure of a consent record (data agreement) and receipt. The work is based on Kantara consent receipt specification.
The standard will further be elaborated in the data model section.
To automate compliance and increase trust assurance, a Data Protection Impact Assessment (DPIA) or similar may be used to populate the data agreement.
A DA lifecycle consists of 4 phases as illustrated in the figure below:
Figure 11: Data Agreement (with consent as a lawful basis, for e.g.) Lifecycle
Definition: In this phase, the organisation (a DS or a DUS) adopts and defines a data policy that applies to the healthcare industry in its jurisdiction as a template.
Preparation: In this phase, the organisation (a DS or a DUS) that intends to process personal data configures the DA and relevant rules for its use. An organisation could use personal data for third-party data sharing as an example. If the data processing is based on consent, the lawful_basis in the DA schema definition is of type consent.
In this phase, an organisation (admin) registers their data model. It configures the DA that consists of the usage purpose, the data attributes used by the agreement, legal basis, data policy configurations etc. In this case, the lawful basis for the data agreement is "Consent". Once prepared, the organisation publishes the DAs to the individuals. Refer here for the complete schema vocabulary of the latest DA.
Capture: In this phase, the individual can review the DA. Once agreed upon, it is captured in a data agreement record by both the organisation and the individual as a cryptographic signature and stored for verification. This allows an auditor to check and ensure records are in place to process the individual's personal data. This phase could also encompass delegation and other individual use cases.
The individuals can view the relevant granularity levels (aka attribute level, e.g. name, activity data, phone number etc.) of respective data. It allows individuals to exercise their rights (as per GDPR Article 12-23) and opt-in / opt-out of any data usage at various granularity levels, where consent is used as a lawful basis.
The capture can happen actively or passively. Active capture is when the individual is involved in real-time during the data exchange transaction. E.g. when a patient shares data with a nurse during remote support (such as with 1177 in Sweden). In passive capture, the individual has granted permission to either a DS or a DUS to share or consume their personal data. For example, when a patient has given consent for anonymised and/or pseudonymised data usage by researchers, the patient can always revoke the agreement at any point (e.g. if the lawful_basis is of type consent). Passive capture of consents can be anonymous or identifiable and transparent based on the DUS’s DA configurations.
Proof: In this phase, an organisation (a DS or a DUS) can demonstrate that a valid record exists for performing data processing within itself or with other organisations. This allows internal usage, and an auditor can verify and ensure records are in place to process the individual's personal data.
In the preparation phase the notice information that will be extracted from the data agreement needs to be set. There may be a templaet database to choose from.
Questions:
Questions:
Description of the two basic documents used to stablish a data agreement and the set of properties to be included in each of them.
AP: add grouping of the attributes
The data agreement will be conveyed by some means described in the interoperability section. To seperate the implementation and the data agreement schema we introduce the term "envelope" to signify the transport of the data agreement as illustrated in the below diagram.
The content of the data agreement contained in the envelope is represented in the following diagram. How the fields are structured may vary but in general they should be included. [NOTE-diagram will be updated as the fields are agreed upon. May need to create a cross reference table of the implementations to be able to identify misalignement]
The next three sub-sections describe the data agreement notice that is shared with the individual, the data agreement record that is signed and is proof of consent, and the common examples of the data agreement notice/record.
A data agreement template is a document elaborated by the Verifier and offered at the beginning of the exchange. Depending on the features supported, it will be presented with the requirements defined by the verifier by the exchange (i.e: if using the Presentation Exchange standard, it should be submitted with the presentation definition).
The data agreement template must define to the Holder the usage that will be given to each of the requested pieces of data, including the purpose, the storage, the privacy policy or legal information about the requester.
The template id references univocally the Data Agreement Template. It SHOULD be linked to a specific presentation definition.
The template version allows to keep tracking of updates on the Data Agreement template.
Holders MUST use the version to determine if they need to perform changes on an existing Data Agreement Record
The data receiver MUST inform the user of all the information about the service provided and the usage of the data.
DID associated to the service provider
Name of the Service Provider to inform the Holder
OPTIONAL: Description of the service that will make use of the data
Base URL of the digital service provided to interact along the lifecycle of the data agreement
Default duration of the data agreement if no further operations happen. After expiration, the data MAY be kept for regulation reasons, but not used or exploited any more.
OPTIONAL: Describes the way the holder needs to provide his consent. Either
Default is 'explicit'
Unique identifier of the purpose to use it as a reference
Description of the purpose for which the data will be used
Data privacy category under which falls this purpose of usage.
Credential purposes _SHALL_ provide support for GDPR and other privacy regulations. Vocabulary _MUST_ be in line with [Data Privacy Vocabulary](https://dpvcg.github.io/dpv/). [The list of all accounted purposes](https://www.w3.org/community/dpvcg/wiki/Purposes_for_handling_Personal_Data#High-level_categories_.28to-be-discussed.29) has been used as a base for this selection.
The category MUST be one of the following:
Legal basis employed by the service provider for the usage of this data. One of:
OPTIONAL Indicate the Holder how the data will be processed by the Verifier
Time during which the data MAY be kept by the service provider, even after extinction of the consent.
OPTIONAL Economic sector representing the service provided.
OPTIONAL Geographic region where the data will be managed.
OPTIONAL List of legal jurisdictions under which the data will be used.
URL pointing to the privacy policy of this service
OPTIONAL Physical location of storage where the Data will be stored
Name describing univocally the attribute.
It MUST refer to an input descriptor ID on the associated Presentation Definition
boolean Marks if this piece of information must be managed as sensitive information
List of purposes, referenced by their Id, under which this credential CAN be used.
OPTIONAL: Information about the DPIAs performed with the generic defined scopes if they have been performed
Time at which the DPIA was performed
Url to retrieve the DPIA report
The events will track all the lifecycle and interactions performed on the Data Agreement by the different parties.
DID of the actor performing the data agreement operation
Current state of the Data Agreement. MUST be one of the following:
Version of the Data Agreement at the time the Event is performed
Time of operation of the Data Agreement
Data Proof asserting the event and the current resulting state of the HTML StandardData Agreement, as described in VC Data Model. One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a modification or acceptance event.
Example 1: Data Agreement Template
{
"@context": "https://schema.igrant.io/data-agreements/v1",
"data_receiver": {
"id": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
"consent_duration": 365,
"form_of_consent": "explicit",
"name": "Bank Of America Fake",
"service": "Bank Of America Demo",
"url": "https://9ae1-88-6-127-11.ngrok.io"
},
"event": [{
"principle_did": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
"proof": [{
"created": "2022-01-13T07:48:40Z",
"creator": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1",
"domain": "gataca.io",
"nonce": "kX04XcM-rpYN4kDopwjaCX-ocxRwzrRs9R_DtsySghs=",
"proofPurpose": "assertionMethod",
"signatureValue": "fRx1WYGM_77VS_7m6SA4hpmmQdT_keIlTABeDY-FA1rQXSe0_zgSDdmVAzcegUJ23jfbKrZY_6EEYrTaode5Dg",
"type": "JcsEd25519Signature2020",
"verificationMethod": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1"
}],
"state": "Preparation",
"version": "0",
"timestamp": 1642060120223
}],
"personal_data": [{
"attribute_name": "email",
"attribute_sensitive": true,
"purposes": ["Client authentication"]
}, {
"attribute_name": "debtRecords",
"attribute_sensitive": true,
"purposes": ["Client authentication","Special clients promotion"]
}],
"purposes": [{
"data_policy": {
"data_retention_period": 300,
"geographic_restriction": "Europe",
"industry_scope": "Banking",
"jurisdictions": ["Spain", "EU"],
"policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
"storage_location": "Europe"
},
"id": "Client authentication",
"legal_basis": "legal_obligation",
"method_of_use": "data-source",
"purpose_category": "Identify verification",
"purpose_description": "Authenticate the user to provide services"
}, {
"data_policy": {
"data_retention_period": 30,
"geographic_restriction": "Europe",
"industry_scope": "Banking",
"jurisdictions": ["Spain", "EU"],
"policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
"storage_location": "Europe"
},
"id": "Special clients promotion",
"legal_basis": "legitimate_interest",
"method_of_use": "data-using-service",
"purpose_category": "Service Personalisation",
"purpose_description": "Collecting user data for offering specific promotions"
}],
"template_id": "x76ShERoQReZmWlLdJZWhWmWQx8bhGa",
"template_version": "v1.0",
}
A data agreement record is each of the accepted versions of a Data Agreement. The current Data Agreement would be the Data Agreement record with the highest version signed by both parties.
A data agreement record is built from a data agreement template: completing the template with the remaining missing data that MUST be provided by the Holder.
[]
The data agreement record MAY be submitted along a Verifiable Presentation during an Exchange. If there has previously been a valid data agreement record that requires no modifications, the submission of a new record is OPTIONAL.
The additional properties added to the template are:
Unique ID to reference this Data Agreement
Current version of the Data Agreement Record
DID uniquely referencing the Holder of the credentials, performing the exchange.
It MAY be the same as the Data Subject. If using Peer DIDs for exchanges, it MUST be the Peer DID.
DID uniquely referencing the real persona to which the credentials used on the credential exchange have been issued.
It MAY be the same or different as the Data Holder.
Inside the personal data information, the following field MUST be included
Unique reference to the Id of the Verifiable Credential shared satisfying this kind of information.
The credential Id MUST match the Id of the Credential that satisfies a specific requirement by the Verifier (i.e.: if using a Presentation exchange, the Input Descriptor) matching the Attribute name of this same piece of personal data
If present, it signalates that this Data Agreement Record is not in use anymore with the timestamp at which it was revocated.
Example 2: Data Agreement Record
{
"@context": "https://schema.igrant.io/data-agreements/v1",
"data_holder": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4",
"data_receiver": {
"id": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
"consent_duration": 365,
"form_of_consent": "explicit",
"name": "Bank Of America Fake",
"service": "Bank Of America Demo",
"url": "https://9ae1-88-6-127-11.ngrok.io"
},
"data_subject": "did:gatc:YzQxNjRjM2U4YTUzZGVkNjhmNjAxYzk5",
"event": [{
"principle_did": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
"proof": [{
"created": "2022-01-13T07:48:40Z",
"creator": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1",
"domain": "gataca.io",
"nonce": "kX04XcM-rpYN4kDopwjaCX-ocxRwzrRs9R_DtsySghs=",
"proofPurpose": "assertionMethod",
"signatureValue": "fRx1WYGM_77VS_7m6SA4hpmmQdT_keIlTABeDY-FA1rQXSe0_zgSDdmVAzcegUJ23jfbKrZY_6EEYrTaode5Dg",
"type": "JcsEd25519Signature2020",
"verificationMethod": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1"
}],
"state": "Preparation",
"version": "0",
"timestamp": 1642060120223
}, {
"principle_did": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4",
"proof": [{
"created": "2022-01-13T07:50:12Z",
"creator": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4#keys-1",
"proofPurpose": "authentication",
"signatureValue": "uWl5t_KSV09qG5nv5Opk0A-r0WoNKkeY9otdxA43sPwQFK4ZACVCKKT0bockbUYAhXm-SGBhQ45xlBwgH-GXDw",
"type": "JcsEd25519Signature2020",
"verificationMethod": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4#keys-1"
}],
"state": "Capture",
"version": "1",
"timestamp": 1642060212916
}],
"id": "3Nkep8bQygtyWyrmcJDkmnnmH8W1huJpZ4E2i6WyY1da",
"personal_data": [{
"attribute_id": "cred:gatc:NjMxNjc0NTA0ZjVmZmYwY2U0Y2M3NTRk",
"attribute_name": "email",
"attribute_sensitive": true,
"purposes": ["Client authentication"]
}, {
"attribute_id": "urn:credential:hEoISQtpfXua6VWzbGUKdON1rqxF3liv",
"attribute_name": "debtRecords",
"attribute_sensitive": true,
"purposes": ["Client authentication","Special clients promotion"]
}],
"purposes": [{
"data_policy": {
"data_retention_period": 300,
"geographic_restriction": "Europe",
"industry_scope": "Banking",
"jurisdictions": ["Spain", "EU"],
"policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
"storage_location": "Europe"
},
"id": "Client authentication",
"legal_basis": "legal_obligation",
"method_of_use": "data-source",
"purpose_category": "Identify verification",
"purpose_description": "Authenticate the user to provide services"
}, {
"data_policy": {
"data_retention_period": 30,
"geographic_restriction": "Europe",
"industry_scope": "Banking",
"jurisdictions": ["Spain", "EU"],
"policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
"storage_location": "Europe"
},
"id": "Special clients promotion",
"legal_basis": "legitimate_interest",
"method_of_use": "data-using-service",
"purpose_category": "Service Personalisation",
"purpose_description": "Collecting user data for offering specific promotions"
}],
"template_id": "x76ShERoQReZmWlLdJZWhWmWQx8bhGa",
"template_version": "v1.0",
"version": "1"
}
Here is an example schema from NGI eSSIF-Lab [Automated Data Exchange Project].
Sections describes the implementations of data agreements into SSI technology stacks.
The following table is an overview of different methods to convey credentials and personal data. The methods that have an implementation of data agreements are listed in sub-sections.
Methods | 1: JWT Envelope | 2: VC-DI Envelope | 3: DIDComm | 4: XML |
---|---|---|---|---|
Signature | 1-only (one inside other) in vp-jwt | Proof object(s) in VP object | ? | XML-DSig (XaDES) |
VP Protocol | OIDC4VP (or WACI) | VP Req | DIDComm | ?** |
Authorization preference | OAuth2 tokens | ZCaps | ||
Trust Establishment |
*
= May be possible, to be researched
**
= Note - Check how some groups in the vcedu group may be implementing their education credentials. Refer to https://w3c-ccg.github.io/vc-ed/
https://identity.foundation/did-siop/ DID-SIOP
https://identity.foundation/presentation-exchange/
Extensions on the Presentation Exchange Data Model to support template and records
Description of the use of decorators to support a presentation exchange
Description of the DID Method design to support data agreements
Here is an example of consent context and consent receipt from Right Consents [Right Consents Project].
The consent context is a basis for consent transaction generation. It contains all pointers to target subject, data controller, processings and layout of what is going to be collected.
At the end of the consent transaction, an XML receipt is generated with certified timestamp and signature (not in the sample). Attachments can also be included.
ISO/IEC 29100:2011
Information technology — Security techniques — Privacy framework
https://www.iso.org/standard/45123.html
ISO/IEC 29184:2020
Information technology — Online privacy notices and consent
https://www.iso.org/standard/70331.html
ISO/IEC AWI TS 27560
Privacy technologies — Consent record information structure
https://www.iso.org/standard/80392.html