Data usage and data sharing is a major concern in all digital services and for the last decade, regulation has increased according to user needs.
On the Decentralized Identity model, there is no current support for the management of the data. Considering the user experience perspective, user rights and service provider risk assessment and data management processes, a specific protocol to agree on the usage of verifiable credentials could be attractive for verifiers.
Despite its format, this document doesn't aim to be published on the W3C as a standard normative, rather it aims to offer a new protocol that is applicable to known SSI frameworks for the improvement of data management. Other protocol extensions shall be discussed and included if considered appropriate.
Regarding standarization efforts on enforcing a technical consent on the usage of Verifiable Credentials, there seems to be a gap that hasn't been filled yet.
The Consent & Information Sharing Work Group at Kantara has been working on a generic Consent Receipts specification that could apply to any digital service. The ISO organization has also provided some guidelines and is working on the subject:
In the context of SSI frameworks however, some organizations could have proprietary implementations of consent mechanisms, such as Verifiable Consents; but no standard has received major adherence.
In the context of the EssifLab, the Automated Data Agreement project has been created. It builds upon Kantara Consent Receipts to allow a data privacy mechanisms to be enforced in the framework of Hyperledger Aries.
The benefits of Automated Data Agreement in the management of DPIA are presented in [[ADA]]. This kind of protocol could also be integrated in automation tools to manage a company's DPIA.
This document will try to offer an adaptation, built upon both Automated Data Agreements and Kantara Consent Receipts, of those same data privacy mechanisms in the context of the Verifier Universal Interface; that is, avoiding specific technical solutions and in comunion to other related interfaces such as the Presentation Exchange.
The data model aims to port the specifications of Kantara Consent Receipts and Automated Data Agreements to have a base Data Agreement structure that could be used on any SSI framework.
The Data Agreement represents all the information shared between a Holder and a Verifier in order to enjoy a given Digital Service.
JSON-LD is a JSON-based format used to serialize Linked Data.
The JSON-LD representation defines the following representation-specific entries:
The Data Agreement Template is the base model to generate a Data Agreement. It MAY be offered by the Verifier to the Holder at the initiation of a Presentation Exchange.
Its contents MUST match the presentation definition to be processable
The data receiver MUST inform the user of all the information about the service provided and the usage of the data.
Credential purposes SHALL provide support for GDPR and other privacy regulations. Vocabulary MUST be in line with Data Privacy Vocabulary. The list of all accounted purposes has been used as a base for this selection.
The category MUST be one of the following:
It MUST refer to an input descriptor ID on the associated Presentation Definition
The events will track all the lifecycle and interactions performed on the Data Agreement by the different parties.
{ "@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", }
The Data Agreement Record is an extension of the Data Agreement Template.
The Holder fills the template offered by the verifier with his personal data and the attribute unique ids that are being shared in that exchange.
Even if the Holder has multiple pieces of information satisfying the Verifier requirements, the Id of
the one selected MUST be referenced in the Data Agreement without disclosing its contents.
This is necessary to enforce Data-minimization, and ensure that the Verifier only has rights to use the
specific information shared by the Holder, and not any other of that same type that could also come from
the same Subject.
The Data Agreement Record represents the current accepted state of a Data Agreement by
both parties.
It SHOULD be
used to maintain the lifecycle of the credential exchange performed between the Holder and the Verifier.
The Data Agreement Record MUST be kept at its last version by both the Holder and the Verifier. Previous versions of the Data Agreement are RECOMMENDED to be stored at least by Verifiers.
The additional properties added to the template are:
{ "@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" }
There are some known deviations from Automated Data Agreements due to either technical implementation issues or to the adaptation to the Presentation exchange protocol.
Those changes apply to the relation between different subproperties of the Data Agreement or the cardinality between them:
The generation Data Agreement MUST be performed along a new Presentation Exchange. With any presentation exchange, a Data Agreement Template with a given Id and Version SHOULD be attached.
The Holder SHOULD check for existent Data Agreement Records belonging to the same data
receiver id.
The process to generate a new Data Agreement would be:
The Data Agreement MAY be modified along time with new needs from both the Holder or the Verifier.
Any modifications of the Data Agreement MUST be performed along a new Presentation Exchange.
This table shows the different kind of modifications that can be performed on a Data Agreement:
+-------------------------------------++-------------------------------------+ | Holder || Verifier | +-------------------------------------++-------------------------------------+ +-----------------------------------------------------------------------------+ |+-------------------------------------++------------------------------------+| || Replacing shared credentials || Asking for a different set of || || with an equivalent || credentials || ++------------------------------------++-------------------------------------++ || Revoking access to some credentials || Modifying the credential purposes || || => Partial Revocation || || ++---------------------------------------------------------------------------++ | | | End of relationship => Full revocation | | | +-----------------------------------------------------------------------------+
Modifications of the Data Agreement MUST result in a higher version of the Data Agreement Record
Every version of the Data Agreement Record MUST be signed by both the Verifier and the Holder. Every stable Data Agreement Record MUST contain at least 2 events with the current version, each signed by a different Actor.
The Holder CAN only modify some credentials, depending on the Category of the Purpose assigned to the credential.
Purpose Category | Substitution | Partial Revocation |
---|---|---|
'Identify verification' | ||
'Fraud detection and prevention' | ||
'Access control' | ||
'Service Provision' | X | |
'Service Optimization' | X | |
'Service Personalisation' | X | |
'Marketing' | X | X |
'Commercial Interests' | X | X |
'Research & Development' | X |
This table is not a final definition.
The protocol of substitution or partial revocation of a specific purpose would be better configured at
purpose level.
It hasn't been suggested in the data model to avoid major divergencies with the Consent
Receipts and ADA specifications.
The process to modify a Data Agreement would be:
The process to modify a Data Agreement would be:
The full revocation of the Data Agreement CAN be requested by both parties.
The process of revocation is done by sending a Data Agreement Record with the last known version with a termination timestamp and a new Event of status Revocation signed by the requester. The receiver MUST also add a new Event of status Revocation signed by the him. Both parties MAY store later the Data Agreement Record as proof of termination.
The provision of the data-using-service to the Subject MAY end after the acceptance of the revocation.
The usage of the data MAY be done up until the expiration of the Consent, as accepted in the first
version.
The storage of Data MAY be executed for each specific purpose until it was accepted on the Data
Agreement.
For security reasons, if using a Peer DID as a Holder for the Data Agreement, it is RECOMMENDED to also revoke the DID. In that case, further exchanges of this data CANNOT be trusted by the Verifier, rendering it unusable.
This section will provide a guide on how to integrate a Data Agreement inside a Presentation Exchange in the context of the Verifier Universal Interface.
As previously defined, to embed the Data Agreement in a Presentation Exchange, a Data Agreement Template MUST be defined. Said template MUST be either referred to or embedded in the Presentation Definition Document.
Upon receiving a Presentation Definition with an embedded Data Agreement Template, 4 options are possible:
In order for the Holder to communicate with the Verifier to manage the data agreement lifecycle, he MUST use the URL property of the data receiver.
The Verifier API to operate with data receivers MUST conform with the API defined on the corresponding VUI working package.
Whatever operations on the VUI Data Agreement Interface have been performed, the Holder MUST include the Data Agreement Record id in the data_agreement_id property of the presentation submission.