A toolkit for gathering and documenting valid consent

A voice menu that uses jargon-free, language and requires affirmative action from the beneficiary coupled with an accessible registry.

In humanitarian settings, it can be difficult to fulfil the basic conditions of valid consent. 

Sometimes this is because consent cannot be considered to be freely given. This is the case for example when consenting to the processing of Personal Data is pre-condition to receive assistance.

In many cases however, it is lack of transparency, information and documentation that invalidates consents. Also, it is very difficult for the beneficiary to revoke consent for a given programme.

We propose a toolkit consisting of an IVR menu and blockchain supported registry that addresses these issues. We believe our solution will significantly increase the probability of obtaining valid consent in three different ways.

Increase transparency and understanding through simple, jargon free content delivery on the beneficiary’s device

The beneficiary receives a call on their phone and can listen to the explanations about the data collection task in their own language. The explanations can be preloaded on the platform by the organization before the data collection. We are aiming at creating standardised reusable content where possible.

Reduce ambiguity through salient affirmative action

Providing consent is a transaction of identity data. However, many times the data subject does not perceive it as such, especially in humanitarian settings where the beneficiary’s consent might be a rushed question & answer at the beginning of the data collection. Our solution makes this transaction more salient and deliberate, by requiring the user to push a button on their phone and saying the phrase “I, … give consent”. We believe this will contribute to removing ambiguity in giving consent.

Improve documentation and empower the beneficiary with data oversight using blockchain proof and digital wallets

A hash proof of the consent will be stored on a public blockchain. The clear-data version of the consent object stored in two places. On the organization’s database and on a digital wallet where the beneficiary can inspect, update and revoke. Gravity provides such a self-sovereign digital wallet platform but it could also the data storage of a different digital identity system. The system would have to be self-sovereign however, in the sense that the individual has control over their data.

Our solution can be integrated in existing systems and can be adapted  to work offline, for example on an enumerators smart device for later upload. 

From our engagements with NGOs and International organizations, we know that consent is an important, but underappreciated issue. Together with ID4D and MIT solve, we want to build a solution that solves this for everyone involved.

Our solution is innovative in two ways. First, we propose a new process, that brings the content and action for giving consent closer to the beneficiary in a more inclusive and easy to understand format. It also makes the transaction of data more salient to the individual.  Second, we leverage mobile and blockchain technology to build a tamper-proof, decentralized and universally accessible registry for consents. This increases transparency and provides oversight of personal data use. Given reliable authentication is possible it will also empower the beneficiary to revoke consent.

The main focus of our solution is on the principles of consent and purpose specification. The beneficiary’s free and specific consent is the preferred legal basis for the collection, use, or disclosure of personal information, The greater the sensitivity of the data, the clearer and more specific the quality of the consent required. This is exactly where our solution links in, by increasing the quality and validity of the consent given and clarifying the purpose.

We aim to also provide the possibility to withdraw consent, by providing a voice interface to the backend registry. By providing this consent monitor interface, the solution also demonstrates openness, right to access and compliance.

Our solution can easily be linked up with existing digital identification systems, either through full integration, or by referencing the identifier of the existing system in the consent.

It can be fully integrated by using the authentication method of the existing system when the user provides consent. This is for example how consent is created in the id systems of India and Estonia. The consent will still be registered on the registry. This will allow to add more features in the future, for example, transaction logs of data access inside the id system can be checked against the user consent saved in the wallet and on the blockchain.

A more pragmatic approach would be that ID number of the existing system be referenced when the consent is given. This would be useful in order to attach consent to a unique, universal id and could be used to find the consent object on the registry. It would imply, however, that the beneficiary knows their ID number.

We assume that the term “user” in here refers to the data subject. The pragmatic approach outlined above is very user friendly in case the ID number is something many people know. From our experience however, that is not often the case in humanitarian settings. Arguably, full integration, using the existing ID system’s authentication mechanism is even more user friendly since it would streamline the act of giving consent with other identity transaction. From a system integrators point of view, the consents would have to be referenced to the specific data attributes from within the system.

First, we will use public blockchains that are universally accessible to store the timestamp proof of consents. That also ensures that the consents can be migrated in case another architecture is preferred. Second, we are working with stakeholders and the digital identity community towards developing a schema for consents. In particular, we are part of the w3c Verifiable Credentials working group which is a great platform for developing interoperable and open standards. We have developed a schema for consent that we are using inside Gravity’s ID system that we can build upon.

We address low literacy and numeracy levels by providing explanation in the beneficiary’s preferred language in a simple, jargon-free manner. IVRs have successfully been used by organizations in settings with many different dialects in South Sudan and Kenya information gathering and dissipation.

Our solution only requires a basic mobile phone, and in case of zero network coverage, the IVR can be implemented as an app and downloaded on the data collector’s device, which we expect to be a smart device. As soon as this device connects to the internet, the consent is uploaded to the registry as usual.

We see two pathways to scale for our solution. First, we aim to integrate our solution into existing ID systems that have achieved scale as a mechanism for obtaining and documenting valid consent. We also aim to integrate it in Gravity’s Identity Platform. Second, we want to offer the solution as a toolkit to humanitarian organizations. This could be done for instance by integrating a module into Open Data Kit, that is used by many organizations, in order to make the consent collection more seamless for the organization.

With Xavier project for the the implementation of a self-sovereign digital ID education wallet for refugees. We use Gravity’s digital identity platform to track attendance, course completion and learning outcomes for refugees in three of Xavier Projects schools in Kakuma Refugee Settlement in northern Kenya. The self-sovereign wallets serve as interoperable data layer to which other parties can request access.

In collaboration with Strathmore University in Nairobi, we are currently working on the issuing of blockchain certified diplomas. Also, We have a partnership with PwC that gives us access to their network and expertise.

Gravity leverages a core team of multidisciplinary experts in the fields of mobile money, blockchain technology, banking and the humanitarian/international development, helping us to deliver a holistic solution that draws from each of our team members expertise in the area. We are well connected in the Nairobi ecosystem of NGOs, innovators and the government, which gives us access to many distribution channels and information. In addition, our Partner PwC has also committed to providing resources to the Mission Billion challenge. 

As Gravity, our revenue model is transactional. We charge our customers per data request to our users wallets. Part of this transaction is paid out to the user in airtime. There is a lack of interoperable data in a variety of domains, including education, cash transfer programming and financial history. We fill this gap by providing an interoperable data layer consisting of self-sovereign wallets. Our approach to gather data on this wallet is product driven. We build products for each use case that link into the wallet, but solve an immediate need for the users (like our education product). We believe this is the model of the future for data sharing and interoperability.

We are strong believers that the future of personal data and identity systems must be private by design. This will only happen if there is a common effort by everyone involved in order to build interoperable and open source modules that can find widespread adoption. Contributing our ideas, experience and network to this endeavor is our main motivation to apply. Participation will also advance our work thanks to collaboration with the ID4D ecosystem and by improving our product offering with an open source consent module.

Low literacy and numeracy and the variety of languages will be a challenge. However, we can draw on the experience or organizations in our personal network that have successfully worked with similar solutions in these settings. Another key barrier is the friction it creates during the data collection task. This can only be solved through a user centered design approach, spending time on the ground and iterating on our solution. We are aware that the module must be user friendly for the data collecting party in order to find adoption in this kind of setting.