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.


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.

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.


Preferably, Bangalore

How To Apply

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

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.