Posted on

When one door closes…

An inspiring effort in response to COVID-19

Last Tuesday, for the first time in recorded history, India pulled the emergency brakes on all of the complex interactions that make up the economy and society of 1.3 Billion Indians.

We’re going to see a lot more cascading effects of bringing almost all economic activity to a sudden and near-complete stop. Some of those effects are already visible and others will reveal themselves over time. One thing that’s easy to predict is that this disaster, like most others, will affect Bharat more than it does India.

However, at iSPIRT, we remain impatient optimists for Bharat. It does not suffice for our volunteers to simply predict the future; we want to help create it. When the lockdown hit, we could immediately see that the country’s messy supply chains would be hard-pressed to disentangle essential services from non-essential ones. On the very first day of the lockdown itself, you may have seen videos or news about the police using their lathis on innocent essential service providers like doctors.

This is undeniably tragic, but at its heart is an information and social trust issue inherent in India. When you distil the problem, it comes down to how does the administration identify those travelling for essential-services vs those who are not. Consider this, Swiggy and Zomato alone – who only work on the last mile of one category of food – claim to have a fleet of close to 500,000. For the entire supply chain, even restricted to essential items only, will require authorisations for millions of people and another few million vehicles.

So today, we’re announcing the release of an open-source tool called, ePass. ePass is a tool to help the administration issue digital lockdown passes. These e-Passes are secure and can be verified when needed. iSPIRT got this solution going from zero to launch in less than 4 days. In the following interview, Tanuj Bhojwani speaks with Sudhanshu Shekhar, who led the effort to build the tool and Kamya Chandra, who helped liaison with the Karnataka administration.

Tanuj Bhojwani: Hey Sudhanshu, let’s start with what e-Pass is?

Sudhanshu Shekar: Sure, so the objective is to make sure that those who are on the road providing essential services or regular citizens seeking them can face minimal friction from the authorities.

We imagine a simple 4-step flow

  1. Individuals, such as you or me, or businesses providing essential services, can apply for a pass.
  2. The administration sees these requests digitally, and can authorise them from the backend, either manually or via automated rules.
  3. People can download their digitally signed passes on their devices
  4. The on-ground personnel, such as the police, can verify the curfew pass is valid by scanning it.

We’ve built tools for each part of that flow.

When we started working with the administration, they gave another great suggestion. If the beat officers could provide pre-authenticated “tokens” – like a gift-code, we could make this process even more convenient for some essential service providers. For example, they could distribute tokens to all the informal businesses in a mandi in one go, helping bring the supply-chain back online that much faster.

Tanuj Bhojwani: And you’ve made this open-source. How can a local administration use this?

Kamya Chandra: Everything is a configuration. The administration will have to decide who the approving authorities are. An admin dashboard allows bulk uploads, approvals, tracking statistics of issued passes, etc. It also allows them to configure timings, the validity of the pass, which identity fields are required, etc.

And finally, they have to instruct their beat officers to download the verification app and use it.

Tanuj Bhojwani: so the local government hosts this themselves?

Sudhanshu Shekar: Yes, the governments need to host this themselves, either directly or through a service provider. As iSPIRT, we have only provided the code and will not be providing any managed services. Even the code is open-sourced for others to use and remix as they see fit.

Tanuj Bhojwani: iSPIRT doesn’t work with the Karnataka administration normally, so how did this all happen? How did the team come together?

Sudhanshu Shekar: Sharad called me at 8 pm Tuesday or Wednesday? Maybe it was 8 in the morning. I’m no longer sure. What’s a day anyway? *laughs*

Kamya Chandra: I want to interrupt here and say I am super impressed by Sudhanshu and the rest of the team. No matter how little sleep they got, they didn’t let it affect their judgement or mood. Their decisions were always geared towards what’s the best that’s needed.

Sudhanshu Shekar: Thank you. We’re all just doing what we can.

But basically, on Monday, as Karnataka started enforcing curfew, we realised that people are going to need curfew passes. We started kicking around the idea on Monday, but there was no team. The next night the PM announced a nation-wide lockdown. We knew this was going to be a problem everywhere.

On Wednesday, the Karnataka administration also got in touch with Sharad asking for a similar solution, and they made it clear they need the solution in two days.

Sharad called and said, “I’m going to ask you about something, and you’re going to want to do it, but be really sure and think about it. This is a hard project and has very tight timelines. Everybody will understand if you say no”.

Sharad was right, I did want to do it, so I said yes and immediately got to work. I reached out to several friends and iSPIRT volunteers for help and a few – namely Mayank, Manish, Vibhav, Mohit and Ashok – agreed to help. It was easy to convince everybody, given the importance of fighting COVID. Manish has a few friends in China and was very aware about the seriousness of this situation. We quickly agreed on the basic product outline and started working. Wednesday was a flurry of activity and we got frequent reviews done with the Administration.

We realised we needed an admin console for the police to manage pass issuance. None of us was really an expert in building front-end applications and therefore, I started making calls trying to find an expert. Through referrals, I managed to reach Vishwajeet at 12 pm. I spoke to him about the project, its importance and the strict timelines. I told him we’d fail without him!

Tanuj Bhojwani: So you called a guy you’ve never met and asked him to deliver a complex task, on a ridiculous deadline for no pay nor any certificate or recognition. How did he respond?

Sudhanshu Shekar: He called his office to take a holiday. Vishwajeet sat down, worked for 15 hours straight, and delivered before time!

Kamya Chandra: *laughs* I want to add that this team, which did not know each other, did sleep shifts – including Vishwajeet, who became a volunteer that afternoon. I remember Sudhanshu taking turns with the devs to sleep at night in 2-hour batches just to keep the engine going. I’d run demos with the administration for feedback in the morning, while they all got a little shut-eye. From afternoon, they’d repeat another day and night of development.

Tanuj Bhojwani: Wow, that’s a lot of effort, and what sounds like very little sleep! What was happening on the police end, Kamya? 

Kamya Chandra: Honestly, I went in with a negative impression of the police and administration – because all you see are videos of people being beaten. However, I was very impressed with the few people I was working with. They were very knowledgeable about the challenges they were going to face operationally. Also, it was obvious they were doing their best. The first call I got from them was at 11.45pm!

They made time for our demos, gave excellent, considered feedback on all of it that has definitely helped the product. For example, we added a quick and easy way to verify the ID alongside the QR, so that it can work even if the beat policeman verifying does not have a smartphone.

All of this was happening by a remote team in lockdown. I was in Delhi talking to officers in Karnataka. Other than Sudhanshu, I’ve never met any of the other volunteers! In every other organisation, this kind of a crisis response doesn’t happen as smoothly even if the team knows each other. Anywhere else, it would have been near impossible if the team didn’t know each other.

Tanuj Bhojwani: Oh! I assumed they were all from Bangalore?

Sudhanshu Shekar: No.

 Mayank is in Bundi, a small town in Rajasthan. Kamya is in Delhi. I’m in Indiranagar, Bangalore. Ashok, our design guy, is in Koramangala and Mohit – I have no idea where he stays – I have never met him *everyone laughs*

Kamya Chandra: Knowing everyone’s location is harder, we still don’t know full names! One of the volunteers who helped us test the security of the product was Sasi Ganesan. I spelt his first and last name wrong in the first email I sent to him! He still helped though. On the 4th day of working together, I needed everyone’s last names, I still only knew Sudhanshu’s and Sasi’s!

Compared to the places I’ve worked before, I was surprised to see Pramod send an email with such savage truths. That’s a great example of how radical candour works, why it is in direct opposition to corporate culture.

Tanuj Bhojwani: *laughs* What were the “savage truths” in this email?

Kamya Chandra: To be fair to Pramod, it was more surprising than savage. Pramod said DO NOT GO LIVE (in bold and underline) until security and related aspects weren’t complete. The contents weren’t particularly shocking, but that he sent it to all of us – including people he barely knew. There was no secrecy or pretending to be bigger than we are. All our failures were also publicly available to a team we’ve never worked with before or met. It’s quite a unique experience.

Sudhanshu Shekar: Yeah, we were planning on going live on Friday, and we knew we needed to do security testing before we went live. Pramod’s email was a good one, and all fair asks about security, usability and data retention. He connected us to another iSPIRT volunteer, Sasi Ganesan for help. Ten hours before the scheduled launch, Sasi wrote back with a list of tasks we must do BEFORE we go live. This Thursday night email doubled our todo list. Thankfully, we were able to pull in Bharat, Sireesha and a few others from Thoughtworks to help close these tasks But at the time it felt brutal, we realised this was going to be a very hard few hours.

Kamya Chandra: Yeah, I think this is around the time Rohit started helping us enhance our UX. To me, this email was a clear indication of the high bar every iSPIRT volunteer must meet. Tight timelines or urgent needs are not enough to excuse sloppiness. I am glad we have senior volunteers such as Pramod to keep the bar high.

Tanuj Bhojwani: But I believe this story has a twist?

Kamya Chandra: Well, we did the demos in time, and everyone seemed very impressed. Unfortunately, the Karnataka administration decided to go with someone else. Their decision to go with someone else was disappointing for us.

However, they are policymakers making scale decisions. They probably had to keep many balls in the air and have redundancy. It’s good they have backup plans for backup plans.

They handled it with grace and were very kind about it. They sent a thank you and a commendation letter to each of our volunteers. One of the senior lady officers asked me – do you only take techies? I do not have a computer science degree, but I want to volunteer!

I told her I was an economist too and that she should definitely volunteer.

Sudhanshu Shekar: For me, the toughest part was when I heard the news that our work won’t be going live on Friday like I had promised all these guys. I was really sad. For about an hour, I tried to fight the decision, but then I realised that I would have to do the difficult thing and break the bad news to a bunch of volunteers who’ve slept less than 6 hours total in the last 72 hours.

What happened next is what surprised me the most about this whole thing.

All of them – every single one – took it so well! They all said something to the effect of working on a solution with other volunteers felt better than not working on one and worrying about the lockdown.

I thought this is the end of the line, but it was they who cheered me up and suggested we should open-source it. I was hoping to tell the volunteers to get some rest. Instead, these guys were so passionate that they worked for a couple more days to complete the documentation, which is why we were able to launch ePass today!

Tanuj Bhojwani: Wow. That’s quite a lot of team-spirit for a team that has never even met! So what happens now that this is open-source? How do you expect it will get traction?

Kamya Chandra: The decision to open-source paid off! Even though Karnataka didn’t take ePass, the officers messaged their batchmates and told them about what the volunteers did.

Sudhanshu Shekar: Now, we have demos scheduled with several other state governments as well as a few national ministries. We think this could be live in at least a couple of places soon.

Tanuj Bhojwani: That sounds like a fairy tale ending. Do you have any advice for anyone who is reading this and wants to volunteer?

Kamya Chandra: I used to work at the World Bank in DC, and we were trying to implement national-level digital systems in many countries. When we had technical challenges there, I was often told to get on a video call with iSPIRT volunteers for guidance and inputs. The more I interacted with them, the more I realised there is magic here to learn from. So I gave up my diplomatic passport and got on a plane to Bangalore!

So my advice is that you should try volunteering even if you’re many, many oceans away!

Sudhanshu Shekar: *laughs* I have a more straightforward test than Kamya’s for those who want to volunteer. These are also the three reasons I volunteer.

First, Societal Impact. You feel useful because you get to work on something that genuinely helps people.

Second, exposure to a wide variety of topics – such a different set of problems – you don’t exactly stick to your lane. Hence, you also meet people with very diverse backgrounds and work experiences. Because my peers are not age-bracketed with me, I feel like there are many lessons that I usually would’ve learned in ten years of my career, I’ve learned already at iSPIRT. 

Third, you draw energy from others’ passion. It’s just amazing to go to work with people like this every day. I’ve realised iSPIRT is a self-selecting group – it’s only the people who seek to find it, find it. It is not easy to be a volunteer, because the environment is open and the volunteers are self-driven, people will clearly be able to see if you can walk the talk. When you have people respected in a system not for who they are, but what they do, it is magical for everyone.

Tanuj Bhojwani: That is very true. Thank you for the chat!

Like Sudhanshu says, Volunteering at iSPIRT is hard and definitely not for everyone. However, if one or more of these reasons resonate with you, you should read the volunteers handbook to learn more about balloon volunteering.

Posted on

Policy Hacks On India’s Digital Sky Initiative 1.0

On August 27, 2018, India announced its much-awaited Civil Aviation Regulations (CAR) for drones. The new CAR had many improvements on the original draft published last year, but most important was the introduction of Digital Sky, a technology platform that would handle the entire process of regulating the registration and permissions for all Remotely Piloted Aircraft Systems above the nano category, i.e. any remote controlled or automated flying object – multi-rotor or fixed-wing, electric or IC-engine. These set of regulations along with the announcement of Digital Sky drone policy represent the government’s “Drone Policy 1.0”.

What this policy isn’t?

From the outset, one of the largest criticisms of the draft was its seeming omission of beyond visual line of sight flights, as well as those of fully-autonomous operations. Combined with a ban on delivery of items, it would seem like the government is pre-emptively clamping down on some of the most promises of Unmanned Aerial Vehicles before they even begin.

But on close inspection, the Ministry of Civil Aviation has made an interesting & what looks to be a promising decision in naming this policy as “1.0”. Through the various public comments made by the Minister of State for Civil Aviation, Jayant Sinha, it can be gathered that there is a phased-approach being adopted for the planning and implementation of the government’s strategy for unmanned aerial vehicles.

The more complex commercial operations will be rolled out atop the digital platform, allowing the government to test the waters before allowing potentially risky operations.

At iSPIRT, we appreciate this data-driven, innovation-friendly yet safety-first approach that has been inherent to all of civil aviation.

What does the policy say?

The policy lays out a general procedure for registering, and taking permissions to fly for every type of remotely piloted aircraft system (RPAS). A good summary of the regulations themselves, what you need to fly, what you can and cannot do is given here. We will be focussing this blog post on demystifying Digital Sky and the surrounding technology – How it works, what it does and what should private players be doing about it.

What is Digital Sky?

Digital Sky is essentially a barebones Unmanned Aircraft Traffic Management system. An Unmanned Traffic Management is to drones what ATC is to aircraft. Most countries are looking to external UTM providers to build and run this digital enabling infrastructure. The government of India, in continuing its digital infrastructure as public goods tradition, has decided to build and run its own UTM to ensure that this critical infrastructure system remains committed to interoperability and is free from the risks of vendor capture in the long run. Digital Sky is the first version of such a UTM for managing drone flights in both controlled as well as uncontrolled airspaces.

For consumers, Digital Sky essentially constructed of three layers. The three layers are Online Registrations, Automated Permissions and Analytics, Tracking and Configurable Policies.

Online Registrations are the layers that onboard operators, pilots, RPAS and manufacturers on to the Digital Sky Platform. It will be a fully digital process, and applicants can track their applications online. All registered users will have an identity number, including the RPAS, which will get a Unique Identification Number (UIN). There is a private key attached to the UIN allowing the drone to prove it is who it claims to be through digital signatures.

Automated Permissions is the transaction layer that digitizes the process of seeking airspace clearance. Using Open APIs or a portal provided by the government, drones can directly seek permissions by specifying the geographic area, time of operations & pilot registration id, signed with the UIN of drone. In response to the API call or portal request, an XML file digitally signed by the DGCA is generated. This XML response is called the Permission Artefact.

All RPAS sold in India under the new policy must carry firmware that can authenticate such a Permission Artefact. Further, they must confirm that the flight parameters of the current mission match those given in the authenticated Permission Artefact. If these parameters do not match, the RPAS must not arm. This condition is referred to simply as No Permission, No Takeoff or NPNT. Thus, the requirement is that any RPAS (except nano) operated in India should be NPNT compliant. We will cover what it means to be NPNT compliant in part two of this series.

To deal with areas of low connectivity, this authenticated request can be carried prior to the flight itself, when connectivity is available. The Permission Artefact can be stored, carried and read offline by an NPNT-compliant RPAS with a registered UIN. Thus flight operations in remote or low-connectivity areas will not be severely impacted. While this seems tedious, it promises to be a lot easier than the draft regulations, which required the filing of flight plans 60 days in advance.

Digital Sky will classify all existing airspace into three colour-coded zones: Green Zones are where drones are pre-authorized to fly, but must still obtain a permission artefact to notify the local authorities of their intent to fly. On applying for permission, a permission artefact is returned instantly. Red Zones are where drone operations are forbidden from taking place. This includes areas such as airports, borders and other sensitive areas. Amber Zones are areas restricted by appropriate reasons as mentioned in the CAR where additional permissions are required. These requests are also initiated and managed through the Digital Sky Platform

Analytics, Tracking & Configurable (ATC) Policies is a shorthand for the regulatory functions that the DGCA will carry out to regulate the use of airspace by unmanned aircraft. It involves functions such as the classification of Red, Amber & Green zones, deconfliction of overlapping flights, incident response, etc.

The MoCA has articulated its desire for an ecosystem-driven approach to building out the drone industry. From an earlier draft of the No Permission No Takeoff technical document shared with manufacturers, it is expected that this layer of Digital Sky will be opened up to private players labelled as Digital Sky Service Providers (DSPs). We will cover more about Digital Sky Service Providers in part three of this series.

Conclusion

Digital Sky appears to be a move towards a more data-driven, phased-approach to policy and regulation for emerging technology. It is a global first and offers a truly forward-looking approach compared to most other nations.

For operators, in the long term, a formal system leads to an eco-system of authorised players, increase in trust, and rise of a legitimate industry. 

Note:  We have been actively following the Digital Sky policy development, Intend to bring in Part two of this blog after an active role out and implementation starts.

Posted on

iSPIRT needs you!

iSPIRT works to transform India into a hub for new generation software products, by addressing crucial government policy, creating market catalysts, building societal platforms, and assisting product entrepreneurs evolve into the next role. It’s a think-tank with an emphasis on following up our ideas with great execution. This is where you come in.

Over the past 2 years, we’ve developed the Data Empowerment and Protection Architecture (DEPA) as the final layer of the India Stack. The DEPA empowers users with freedom and choice to actualize their data in a way that benefits them.

This includes a new technology for managing user consent and for authorizing data flows, as well as a new federated architecture for efficiently sharing user data from multiple data sources to multiple destinations (referred to as the digital locker framework). Banks and other big institutions are now beginning to deploy DEPA tools to enable consented data sharing by users. You can deep dive into DEPA here 

 

Volunteer Challenge

In alignment with RBI’s NBFC-AA Directive, we wish to develop a reference data architecture for Banks and NBFCs based on DEPA so that they can introduce new products and services to accelerate Financial Inclusion in India.

You will help develop, design and evangelize this new architecture with anyone and everyone in the market. If the job description seems vague, it is because this is uncharted territory and largely, you will decide where the work takes you. What we promise you is a world-class support system and a platform to actualize those ideas.

iSPIRT also has room for a lot of other volunteers with a variety of skillsets. Even if your expertise is not technology, but want to contribute to the mission with your unique skills, do fill the form below.

Why Volunteer

Our volunteers pay-forward for a variety of reasons.  Some do it for iSPIRT’s mission and cause. Others, find self-actualization in building public goods. Yet others do it to be in the company of world-class techies and entrepreneurs. You can learn more about iSPIRT from its Intro Presentation and its 2017 Annual Letter.

We’d be happy to discuss what is in your future, and how volunteering with iSPIRT can get you closer to that goal. Though, we have found that many of our volunteers have gone on to unexpected pathways, as they kept an open mind through the journey.

Location

Preferably, Bangalore

How To Apply

Interested? Please fill out this simple Google form and we shall get back to you: 

Posted on

The best way forward for Privacy is to open up your data

Since conception, the India Stack has always been presented as having 4 layers. The first 3, paperless, presence-less and cashless, would essentially combat the price of doing transactions. Whether government to consumer or business to consumer, these layers significantly drive down the cost of interacting with your end consumer. With reduced cost, came increased access. Sachetization of services was possible, and we started seeing more and more businesses target India-2 and India-3, making them data rich.

Slide Showing the 4 layers of the India Stack
Slide Showing the 4 layers of the India Stack

The 4th layer, that was nicknamed the “consent layer” was different, and hasn’t received much attention thus far. Unlike, the other 3 layers, it does not seek to drive down the cost of delivering services, but is a tool to, as Nandan Nilekani puts it, “invert the data”. That means that it allows the user to assert ownership over the data, and exercise certain choices in how it is used. The Data Empowerment & Protection Architecture (DEPA) brings us closer to achieving a Data Democracy, where the user can share his data with service providers. The slides attached here, present iSPIRT’s outlook on what DEPA is, what it does and most importantly, how does it empower the user.

Before we get into details of Data Empowerment, it is useful to acknowledge that Data is not a homogeneous commodity. There is a hierarchy within Data, and not all forms of Data can be treated equally.

The five types of Data that needs regulations
The five types of Data that needs regulation

In the table above, as we go from left to right, data goes from more intimate, to more public. Even in today’s muddled regulatory framework around Data, non-shareable data such as biometrics, or passwords is seen as user-owned and a big no-no to share. But as we move towards the right, where ownership of the user ends, and that of the Data Controller begins, is murky at best.

Second, as you go reverse from right to left, the data becomes more individualistic. Anonymous Datasets, and Public Datasets are clearly about group data, whereas the rest are coupled with one or more individuals. Generated Data on e-commerce marketplaces, for example, may involve 3 or even 4 parties. Non-shareable data is typically intimate to a single user

Everything that we talk about in this post or the slides that follow, focus on the shareable middle of this chart, highlighted in yellow. At a principle level, we assert that any data, that has an individual identifier to it, is co-owned by every individual whose identifier is present in the data set. This may not give you complete rights over your data, but it gives you two rights, that DEPA enshrines in technology.

The first right, is that you can ask for access to your data from the data provider where this data originated, in a machine-readable format. The second right, is to share with user consent, your personal, generated or derived data with any other service provider you wish. To be clear, this is a right to consented sharing, and not consented collection. The right to what data is collected is a tricky issue, and requires policy, legal & regulatory clarity, before we can build tools to protect it. But we believe that the right for a user to claim stake on collected, generated or derived data about themselves has clear legal and moral precedent.

DEPA engages with Consent to Collect, not Consent to Share
DEPA engages with Consent to Collect, not Consent to Share

How do we enshrine these rights in technology? The Electronic Data Consent. But before we introduce the hero, I’d like to get into a little back story to set the stage.

When UIDAI first issued Aadhaar cards, it noticed that despite it’s portable, digital nature, people used Aadhaar cards as Proof of Identity in the same way they used other IDs, through self-attested photocopies. Most of the time, these photocopies would not contain the explicit purpose of why they were photocopied. These photocopies were impossible to manage, and inadvertently some bad actors would steal say PAN or Aadhaar xeroxes, and use them as paper identity documents for fraudulent transactions.

So the UIDAI launched eKYC. The premise was simple, UIDAI could authenticate the identity of the individual. Combined with explicit consent of the user to share their data, the encrypted data would go directly to the service provider, digitally signed from UIDAI. This copy of the KYC document was safer, more trustworthy as well as faster and cheaper.

So the basic equation became :

The eKYC equation
The eKYC equation

But this thinking was pretty powerful, and the MeitY decided to abstract it and create the Digital Locker Ecosystem. Where instead of only one source of truth (UIDAI), any government or private entity can become an issuer of documents. Authentication was also abstracted and need not be tied to Aadhaar. You could retrieve marksheets linked to your roll number, or mobile bills linked to your mobile number. This lead to the following equation :

The Digital Locker System Equation
The Digital Locker System Equation

If you’ve been following this so far, you’ll realize there’s a pretty big missing piece in these equations so far. The “User Consent to Share” bit doesn’t seem to have the same sort of granularity as the other two parts of the equation. Consent is more nuanced than a simple yes or no. By forcing consent into a binary, data providers reduce their offerings to a “take it” or “leave it” choice. This is a meaningless choice for the consumer.

To really capture user intent, we must expand our understanding of consent. We must try to capture the granularity of the customer’s intent to consent. Does the customer consent to sharing of his data forever or for a limited period of time? Does the customer consent to further downstream sharing of the data, or does he not want his data to leave the service provider? This is where the hero we mentioned earlier enters.

Sample Flows of Data and Consent under EDC
Sample Flows of Data and Consent under EDC

Introducing Electronic Data Consent (EDC). It is a mechanism to abstract consent flows, from data flows. Which means, that you can capture the user’s intent to consent in bits, digitally signed by the user for authenticity, and share it with other providers to retrieve user data seamlessly.

Flowing through the pipes of EDC is an open, extensible XML file called the Consent Artefact. The Consent Artefact has some pretty cool features. It captures all the parties involved in the transaction, it explicitly states what data is being shared and for how long. There are options for the user to decide if the data consumer is allowed storage and further sharing of this data. Also, all parties are immediately notified to any updates in the consent and all changes are logged. This facilitates data audits, not just for regulators, but also to enhance trust between Data Providers and Consumers, and unlock the data economy.

The Consent Artefact enables differential privacy measures such as Virtual Data Rooms. For e.g., a lending startup could know if your income in the bank account matches the one on your salary slip, without having to hand over your entire financial transaction history from your bank to the NBFC. It can just raise a query to your bank “Is income > x?”, and get a simple yes/no in return. The Consent Artefact’s logging and notice, can enable newer ways of pricing and doing business on data. The Consent Artefact deserves another post just for itself, and you will get one, in the next couple of weeks.

But to summarize, the EDC abstracts consent flows, from data flows. It allows for collection, management and audit of granular consent to share data in an open XML file called the Consent Artefact. Now, time for the big question. So What?

Well, today you can open a Bank Account instantly with eKYC. You can get your bank statements on a digital locker without lifting a finger, if the bank is enrolled as an issuer on a digital locker. But to get a personalized flow-based loan, you need EDC. Electronic consent unlocks the value of your data sitting in multiple databases of multiple service providers and gives you granular control over who gets to see what. Together these 3 tools give us a stack for Consented Data Sharing that we call Data Empowerment & Protection Architecture. DEPA opens up whole new models for Privacy Protection and Auditing Data flows while keeping the user in the center. More tools will be added to this Architecture that encourage the unlocking of value in disparate data sources, such as the healthcare combiner.

The 3 Tools that make up DEPA. Upcoming tools such as the Health Record Combiner will be introduced in another blog post.
The 3 Tools that make up DEPA. Upcoming tools such as the Health Record Combiner will be introduced in another blog post.

We believe that the 4th layer of the India Stack is the most critical. While the other 3 were useful operationally, the consent layer is useful strategically. It forces you to think about how best to align Data for the empowerment of the user. By opening up the data, it removes all monopoly value attached to the Data, whilst still retaining the inherent value of the Data. Innovation moves away from who can hoard the most user Data, to who can make the best use of the Data for the user.

If you’re curious to see EDC in action, please do have a look at the talk by Sanjay Jain & team here. The slides used in that talk are shared here.