Requirement formulation

Owned by Vineet Singh
Aug 19, 2021
3 min read

 

What does consent look like?

DEPA in a nutshell

 

FS offering

  • Create a service that can embed in any application that can help collect consent - consent manager for agriculture domain

  • Consent interaction with FS connector:

    • FS connector an independent offering that has an application that queries DB and creates a table that can be made available

    • FS connector enforces a policy that is based on the consent, for example:

      • Share data of those farmers only who has given consent

      • Share data to specific orgs (connectors) as mentioned in the consent

      • Share data to specific connectors with specific application as mentioned in consent

 

 

 

Similarities/ differences in FS and DEPA (does FS intend to add on DEPA?):

DEPA

FS

DEPA

FS

Consent is requested by the data consumer who wants to provide some service

Apart from consumer, consent can also be obtained by the data provider who wants to share data that can help the users but only when the users have consented

Consent is one time use only, can be revoked

For next transaction, data consumer need to request consent again

Consent can be used multiple times by the provider and the revocation is either done by the user or expired as per the consent collection itself

Data to be shared is assumed to be available from data provider, true for banks like transaction details of each customer

Provider may not have the finalised table that has to be shared - connectors can be configured once with applications that transforms the data

Consent is essentially access control

FS proposes to enhance consent to usage control

MVP

Approach

  1. Build for one of the use cases where we see potential use

  2. Leverage existing data that DG has to provide better services to the farmers

    1. CoCo DB is MySQL DB with multiple tables about the farmers, the videos they have seen and the practices they have adopted and so on

    2. We can use the data and add consent in tables in each row

  3. Initially don’t focus on the consent artefact and automation of usage policies from the same

Streams:

  1. Consent manager service:

    1. UX to capture informed consent

    2. Understand user motivation/ benefits etc

  2. Usage policy:

    1. For a use case which basically helps user onboard on a different system with their information, there is a connector that has an application that queries the DB and creates a table of relevant information for all individuals (phone number, name, location, cropping history, consent)

    2. The usage policy is enforced on the provider that only those rows are shared for which there is a valid consent

What do we achieve?

  1. By use of consent, the history of activity on field of a farmer is shared and used to create a profile in another system. It eases the data consumer or farmer’s job of onboarding.

  2. By making use of connector, we create a one time activity that does provide the final relevant data about the farmer in one table. It eases the data provider’s job.

  3. It gives choice as well as access to the farmers - something that the government policy desires.

Further Questions:

  1. The connector should ideally be run by a third service provider (maybe Government) or the the consent collector itself but then it can cause more issues

  2. We are not able to ensure:

    1. that data will only be shared by FarmStack - provider can still share it (so make this part of consent)

    2. In the current MVP, the control is not extended on the consumer (later stage)