To a large extent, identity on the Internet today is centralized — or at best, hierarchical. Digital identities are owned by CAs, domain registrars, and individual sites/organisations, and then rented to users or revoked at any time. At times, the aforementioned identities are shared or worse, sold to other organisations without the consent of the ones they originally belong to. However, for the last two decades, there’s also been a growing push to return identities to the people, so that they could actually control them.
idStack is a blockchain network that enables app developers to build fast full-stack applications on it. Using the idStack SDK app developers can issue identity to their users enabling universal login. They can also use the SDK to read and write data on the user's behalf. This enables app developers to build fast applications on top of idStack.
idStack maintains all the transactions run on the platform in a datastore (MySQL database). All the user-generated data that the apps write are written to idStacks decentralised storage (file-based).
Identity Stack (idStack) is a blockchain-powered platform with a simple goal — The user must be central to the administration of their own identity. It enables an individual (or organization) to manage the elements that make up their identity and controls access to those credentials — digitally.
idStack comes with a set of pre-packaged APIs which can be used to store and retrieve user identity on the configurable blockchain. Use of blockchain to track the user-identity registration not only makes it immutable but also provides a way to track usage of the same. Once the user identity is captured on the platform, for all access of user-identity requires the user to express something called — “Consent”. A Consent is a control switch integrated directly into a user’s identity, access to which can only be approved by the user. Since his identity is on the blockchain, any changes to the Consent can be backtracked and reviewed at any point in time.
A configurable plug-in blockchain module sits in the core and powers all the promises delivered by idStack. Organisation is free to choose any blockchain platform from a predefined set, after which blockchain-interface packages are available for download. Package contains the necessary tools for Organisation to leverage the blockchain platform for their use-case.
After selecting blockchain platform, organisations can download the API package which can be used to store user identity on the chain. It also contains several other APIs and tools for seamless interaction between application layer and blockchain layer.
Key management modules:
For each user, a unique key is allocated at the time of registration. Using this key, User can cryptographically sign actions — add and modify, he performs on his identity. This module effectively limits the access of the identity to the owner.
User holds all the rights on how his identity should be shared across different platforms. He enables the Organisation, he has used to set up his identity, to share the identity further, either fully or partially, by showing ‘Consent’. A Consent, in the system, is nothing but a flag reflecting the owner’s decision whether his identity should be shared with others or not. Consent sits very closely with the User’s identity and gives him full control over his digital credentials.
First ever E-Voting to happen on blockchain. National Securities Depository Limited (NSDL), along with the Securities and Exchange Board of India (SEBI) with the help of idStack successfully conducted E-Voting Proof-of-Concept and also gearing up for taking the entire setup into production.
idStack, in eVoting, enabled votes to tokenized and distributed to the owners at the start of the Annual General Meeting (AGM) and later proxied should the owner feel the need to do that. One important thing to notice here is that the key-management module of idStack enriched the voting process with functionalities like Automatic signing using logged-in user’s key, Vote-proxy and Vote-cast tracing. Tracing of votes particularly helped bring-in transparency and highlight abnormal behaviour in the system, if any.
Central KYC (CKYC) is an initiative by the Government of India to bring all financial sector entities under one single roof. Main goal of cKYC was to centralise the data captured during registration, but this also introduced a big challenge into the system — Organisation which captures the KYC-data holds the ownership over it. Thus, they can share user’s data with other organisations and as many times as they like.
With the help of id Stack, decision of sharing user’s KYC-data was coupled with the data itself. Now, financial organisations need to also capture the ‘Consent’ of the user before they make it available to other organisations. Users are able to manage how and which companies should get their KYC-data. Along with consent, idStack provides traceability of all operations done on user’s Addition, Update, Querydata like — Addition, Update, Query of KYC, which is linked to the platform-generated CKYC-ID.
Network orchestration is a key part of idStack. In order to achieve a high yield blockchain that is capable of supporting fast full-stack apps it was essential that we’re able to handle operations around the network management seamlessly. We achieved this by building a federated network protocol (FNP). This became very important because idStack is a permissioned blockchain that is capable of running as a public ledger when required.
Orchestration enables us to release products with more confidence. A proper process is a huge part of “reliable engineering”. Automation allows progressive development. For example, if an engineer in your organisation is responsible for setting up your web server or database server; he does it manually; once he leaves your team you have to build from scratch all the abilities again. If the tasks were automated, there would be no reinventing the wheel and development effort thereafter would add to the previous achievements. Automation and orchestration take the burden of managing mundane, day-to-day operations of IT teams so they can focus on strategic, value-add activities.
Automation is a single task or function that is accomplished without human intervention, while orchestration describes the arrangement of these automated tasks into a consolidated workflow. Automation is concerned with individual tasks, while orchestration is concerned with processes.
One of the main benefits of the DevOps approach is its ability to shorten an application’s time to market by uniting development and operations teams, creating standardised processes that reduce the time it takes to get an application up and running. But these challenges are amplified exponentially when multiple parties are involved. A blockchain network would usually consist of two or more organisations. So how do we then unite the operations and development teams across these organisations?
Establishing consensus in a private network for administration can be achieved through automation of node processes and automating governance tasks. For e.g. handling genesis files and other configurations when members are to be added to a network, dealing with network topology chain specific idiosyncrasies, balancing unstable networks, etc. These elements can be difficult for teams to accomplish on their own because they involve interconnecting processes running across heterogeneous systems in multiple locations. What needs to be achieved is designing a process that learns from network data and enables communication between nodes. These standardised processes are developed through the orchestration of several different automated tasks to create a repeatable, reusable workflow.
There are cloud blockchain deployment tools that simplify blockchain deployments and handle the intercomponent communication and connections to other apps and ensure that everything is correctly configured and maintained. But the challenge is that these tools allow only one user to deploy the entire network. Essentially making him the gatekeeper. The other members have to then borrow the nodes deployed by the gatekeeper. This nullifies advantages that decentralisation brings to the table. Also, these tools lock you down to specific platforms like Microsoft Azure, AWS, IBM Cloud.
DevOps culture, automation and orchestration work hand in hand to streamline application deployment. In other words, orchestration aims to optimise and standardise processes and automation is a tool to accomplish that goal. But the real value is only achieved once we are able to handle individual deployments of nodes by their own owners and are yet able to form networks and later administer those networks in an automated manner.
DevOps and orchestration determine success or failure for most products or services deployed. Having healthy process for automated deployments is key. As such it is very important to learn federated orchestration to build successful blockchain networks.
FNP (federated network protocol) is a communication and orchestration protocol. It will allow applications to install and manage blockchain networks. Blockchain is a network of two or more than two participants talking to each other and following a set of rules (smart contracts) using their clients/nodes (software installed on their servers — blockchain client).
Usually, the nodes in a network belong to different stakeholders. Installing these nodes is undertaken by these independent stakeholders. Issues arise with the compatibility of the installed clients (version mismatches, dependency issues, etc.) because of the diversity. Also, once these clients are installed there is the problem of orchestrating the network. Tasks like starting the network, member on-boarding, role allocation, etc. need extreme coordination. If there is no third-party service provider managing and controlling the entire network centrally these actions become near impossible to complete. But having these clients/nodes be controlled through centralised means is anti-blockchain in nature. This defeats the purpose of the decentralised use-case.
This is where FNP come in. It enables these independent stakeholders to control their clients/nodes through the idStack controller (a website based control screen) abstracting the complexities of the above-mentioned actions. idStack controller is not centralised and can be installed independently with each stakeholder. All of the independent installations of the idStack controller can talk to each other using FNP. Because they are able to communicate they can coordinate and carry out the complex orchestrations required for establishing and maintaining the blockchain network.
Administration on private blockchains has proven to be a challenging problem.
This is because many tasks, such as allowing another member to join or leave the network, will need to be executed in a coordinated manner.
For example, if a new member has to be added everyone on the network will have to whitelist the new member’s IP, open certain ports and make changes to configuration files like the genesis file.
In such a scenario, it’s much more efficient and reliable to automate these tasks. But, this cannot be done if the nodes can’t talk to each other.
Coordinating a decision on important activities such as adding or removing network members, network topology design and scaling up the network requires federated as opposed to a centralised method of decision making.
As such, the FNP essentially acts like “a hall monitor” to ensure nodes are behaving. If a validator node is about to crash, for example, a so-called “predictive correction feature” kicks in.
The Federated Network Protocol is aware of the number of validators, and their health, at all times. This awareness allows idStack controller to predict the point of failure on the network and prevent it by spinning up temporary validators that keep the network alive while participants are alerted to the imbalance and instructed to remedy it. This enables smooth orchestration of decentralised identity networks.
Network protocols used in idStack:
idStack is a blockchain network that enables app developers to build fast full-stack applications on it. The nodes that make up the idStack network are constantly communicating with each other. Thus it is important for us to use a communication protocol that does not have a lot of overhead. For example, the standard REST formats that use HTTP as the network protocol sends a lot of headers along with the actual payload which affects the bandwidth. Also, using JSON which is a textual representation of the payload is not the most efficient. Thus we decided to use gRPC as the communication protocols between the nodes.
What is gRPC?
gRPC is an open-source remote procedure call (RPC) system initially developed at Google. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts.
gRPC Framework Architecture:
gRPC has SSL/TLS integration and promotes the use of SSL/TLS to authenticate the server and to encrypt all the data exchanged between the client and the server. Optional mechanisms are available for clients to provide certificates for mutual authentication.
gRPC with idStack:
idStack is a decentralised identity and app development platform. It is based on the blockchain framework. Intended as a foundation for developing applications or solutions with a modular decentralised architecture, idStack allows components, such as consensus and membership services, to be plug-and-play. idStack leverages container technology to host user data files; this acts as the foundation of data storage on this platform.
idStack uses gRPC for communication between peers and clients in the network. It also uses gRPC for communication between the decentralised storage engine.
In idStack Project:
To prepare data for transmission, Protocol Buffers are used for serialization. gRPC comes with SSL/TLS capability baked-in. Though this feature can be enabled, for idStack in Production Pilot we kept it disabled to achieve lower network latency. Another reason was that all the nodes for idStack in Production Pilot belong to one datacenter. For Production, as required, we can enable the SSL/TLS module by simply changing the boolean flag of the docker image to True.
Also, it is important to note that SSL/TLS certificates need to be provided and installed on these nodes before the docker container is created.