👍Consent
Governance: Consent
Last updated
Governance: Consent
Last updated
The consent service allows participants of the data space to generate a consent towards an end user to share their data with an other participant of the data space
People can manage their consent from the services concerned in the data exchange or from their data intermediary where they can find and manage all their consents from a central place
The consent is generated from a data sharing agreement existing between the parties sharing the data; the consent triggers the real data exchange or access.
This video shows how a consent system works, it is here operated by the Visions data intermediary. Through the Prometheus-X philosophy and open source building blocks, any other player can reuse the code and operate a similar service. Through this same approach, people can not only share data between parties connected to their specific data intermediary but with all parties of the data space (see Architecture).
Start date: T0 + 2 months (T0 = expected: Q1 2023)
End date : T0 + 9 months
Duration (in months): 7 months
First version of such a consent service implemented by Visions, see documentation here and code here
Find the full decentralized protocol enabling data sharing between multiple contract services, consent services and personal data intermediaries here
Want to join the effort? See the Working Groups.
The objective of this building block is to provide a consent service to organizations wishing to exchange personal data. Indeed, in order to ensure compliance with the RGPD as well as ethical and person-centered principles in the flow and use of data, consent and information of the data subject are required.
This service allows ecosystem members to present consent to the individual, store it, verify it and revoke it. This consent is generated based on an existing contract between the data user and the data source(s) (contracting service developed by Task 1.3) and will contain all the information needed to obtain it (purpose of the processing, parties of the exchange, data involved, duration of validity, way to revoke it). This service interacts with the data storage system on the blockchain, described in task 1.5, to guarantee the decentralized and unforgeable nature of the consent. The valid consent is then verified for each data exchange and processing that requires it. It also interacts with the monitoring system to be able to alert in case of suspected fraudulent use of the authorizations, see here.
This will allow each data exchange to be linked to a consent when required and each member will be able to easily request a consent to exchange data with other members of the network.
This service will enable the implementation of person-centric consent that links its different services together. This differs from internal consent services within each organization that only address the person's data and identity within that organization, here the person links their data and identities across different organizations through their consent. This allows one organization to request consent for data present in another.
The service consists of an API allowing:
Retrieve information (processing, data types, organizations involved, description, identities, etc.) to generate consent based on a contract by interacting with the contracting service
Register consent on the blockchain by verifying the identity of all stakeholders by interacting with the identity systems of data providers and users as well as the identity system
Modify a consent
Notify stakeholders of the withdrawal or granting of consent to initiate or terminate a data exchange
Interacting with data users' data deletion systems when withdrawing consent
Ensure withdrawal of consent and notification when consent is revoked or expires
Verify a consent and its validity
Retrieve all consents for a stakeholder in a standard format
Interactions with the monitoring system to detect fraudulent use of consent (task 1.6)
Conduct accurate searches of a department's data as well as of all departments, data and processes
Limit and secure the various calls made to the API by a system of verification by IP / Service
Obtain detailed information about errors in a known error register
The API will be developed based on existing code provided by one of the founding members of Prometheus, Visions, which is developing a similar service through VisionsTrust (visionstrust.com).
- Definition of the architecture of the API endpoints in accordance with the technical recommendations of GAIA-X
- State of the art of the latest developments in consent standards (Kantara, ISO)
- Development of the endpoints necessary for the list of functionalities described above
- expression of data in JSON-LD format to ensure interoperability with other data spaces
- Integration with the blockchain storage system (task 1.5)
- API testing with use cases provided by Prometheus volunteer partners (see support list)
- Integration with contracting, identity, monitoring and interoperability services (see tasks 1.3, 1.4, 1.5 and 1.6)
- Deployment of the service in a managed version in one of the partner cloud providers
- Development of automated service deployment scripts for multi-cloud use (infrastructure as code e.g. Terraform) at partner cloud providers
- Writing of public documentation, publication of the code according to the standards decided by Prometheus, hosting and uploading on the Prometheus platform
# | Availability | Deliverable |
1.2.1 | T0 +3 | Documents : Specification, state of the art and quantitative study |
1.2.2 | T0 + 5 | Development of the service and production launch in beta version (v0) |
1.2.3 | T0 + 7 | Test report + interconnection tests with contracting, interoperability and identity services |
1.2.4 | T0 + 9 | Development of final version (v1) of the service + multi-cloud deployment scripts |
Sequence flow:
