Technical approach

The Kiva Protocol team held tightly to principles of do no harm, privacy by design, open source software and standards, and data minimization. That ethos guided our approach to the technologies and system design decisions that we made with Kiva Protocol. In this section, we provide additional details on those key decisions and some of the technical tooling we developed.

Kiva Protocol Technical White Paper

Why use decentralized technology?

Decentralized identity systems are conceptually similar to federated hub-and-spoke systems. However, rather than relying on a hub or broker institution to intermediate and pseudonymize the authentication transaction between the Issuer and Verifier, the technical architecture provides this functionality directly.

In a decentralized system, the Issuer provides identity proofing and shares relevant identity attributes as a verifiable credential (VC)-a tamper-evident data file transferred over the internet-to a digital wallet that is owned and controlled by an individual. Once the data has been collected and prepared, the Issuer writes four objects to a distributed ledger: (i) the public decentralized identifier (DID) of the Issuer; (ii) the schema of the identity credential; (iii) the credential definition that describes the signing keys; and (iv) and the revocation registry, an online repository of data needed for the Issuer to revoke the credential provided to the individual. None of these data fields contain any personally identifiable information, and are foundational for the system to enable identity Verifiers to confirm validity and authenticity of the credentials when they are used for eKYC verification.

The identity owner can share the VC directly with Verifiers without any further action required by the Issuer or the involvement of any hub or exchange intermediary. Upon receipt, the Verifier simply confirms that the VC: (i) was issued by the Issuer; (ii) has not been altered or tampered with; and (iii) has not been revoked by the Issuer. This final step is accomplished by cross-checking a revocation registry, rather than reverting-directly or indirectly-to the Issuer.

In this architecture, identity credentials are decentralized and contextual. Although it may be powerful for a foundational identity issuer-e.g., a birth or voter registry or other civil registration authority-to act as the initial Issuer, there is no technical requirement to establish a centralized authority for validating all identity claims. The architecture can be adapted to any local or industry context to enable multiple Issuers to issue credentials into individual-owned wallets. This provides added flexibility in design and implementation, particularly in jurisdictions with multiple functional and foundational identity issuers.

Authentication request flow in a decentralized identity system

Decentralization also provides various data protection and privacy advantages over centralized or federated systems-principally because Verifiers do not need to contact Issuers (or exchange intermediaries) to perform identity verification. There are no technical, contractual or commercial relationships between Issuers and Verifiers. Individual identity owners are free to share their VCs with Verifiers as they choose without exposing their third-party transaction activity with any central authority, hub, or exchange. (It is important to note, however, that the Issuer still maintains responsibility for, and control over, identity proofing and the issuance and revocation of credentials. The decentralized architecture merely allows the individual to privately, reliably, and securely share those credentials with third parties without necessitating a subsequent confirmation by the Verifier to the Issuer.

The decentralized architecture provides many of benefits of the hub-and-spoke system including, inter alia: (i) eliminating entirely the need for Verifiers and Issuers to exchange information regarding identity verification requests; (ii) enabling multiple Issuers to issue credentials to the same digital wallet; (iii) enabling consumer-permissioned data sharing with multiple Verifiers who can integrate easily and securely with the system via simple APIs. Unlike the hub-and-spoke model, however, the decentralized architecture relies on consumer-controlled digital wallets, rather than third-party intermediaries, to facilitate a privacy-preserving identity data exchange.

Is this self-sovereign identity (SSI)?

Yep, at least one form of it. Self Sovereign Identity (SSI) is a term used to describe the digital movement that recognizes an individual should own and control their identity without the intervening administrative authorities. Kiva Protocol implements SSI using technology built by the Sovrin Foundation and Hyperledger.

For more information, please refer to: Sovrin Foundation on SSI HyperLedger Aries

Working with open source communities

Kiva Protocol is a completely open-source technology that incorporates the efforts of multiple other open-source and open-standards communities. Our team members were active contributors and heavily invested in the open-source communities around these technologies.

Kiva Protocol adhered to the high-level Principles on Identification for Sustainable Development which call for open standards and vendor neutrality in the design of digital identity systems to encourage innovation and ensure financial and operational efficiency and sustainability. When deployed to support a decentralized identity system, a strong advantage of this type of standardized protocol derives from the interoperability, efficiency, and network effects that can be achieved by working together:

  • No vendor lock-in. Because Kiva Protocol is open source software, the implementing Entity (typically a government agency or public-private partnership) is not reliant on a single vendor to maintain the system. Any proficient Entity, internal to the system or a local vendor, can help operate and maintain the system. Even without Kiva’s continued involvement, the system can continue to advance and develop with the support of various vendors working independently or continuing to participate in upstream projects like Hyperledger Indy, Hyperledger Aries and Hyperledger Ursa.
  • Standards. Technical standards and terminology are shared across the open-source community. This greatly simplifies integrating Kiva Protocol into existing or new systems for governments, FSPs, and other authorized entities. Ongoing with with the Anoncreds standards group, the W3C (Verifiable Credentials Working Group, Decentralized IDentifier Working Group, and Credentials Community Group), the Decentralized Identity Foundation, and the Trust Over IP Foundation continue to develop and support needed technologies and standards.
  • Interoperability and extensibility. Enabling Kiva Protocol to extend beyond eKYC verification is possible if desired. Adding adjacent services such as business Entity registration, digital driver’s licenses, digital voter identity, portable health data, and verifiable education records are just a few examples. Moreover, because Protocol extends the functionality of existing identity systems-whether it be national ID systems, functional IDs, or social protection eligibility lists-it can be deployed without any interruption to existing public or private sector programs.
  • Resilience. The open source nature of Kiva Protocol makes it resilient in that no external party can revoke the ability to use the system. In addition to removing vendor lock, even if all external access to the system were cut off, local operators would be able to provide a then-current copy of the ledger data, and clients would be able to continue with new local-only transactions until a time when updates can be merged back into the national system.

Kiva is proud of our collaboration with this open-source ecosystem and welcome all contributions towards continuing to develop Kiva Protocol and the technologies incorporated therein.

Financial histories services / tools

During the exploratory phase of our research on the use of eKYC for verification of financial history, we established workflows for three potential data sources: 1) Remittance provider, 2) Intermediary bank, 3) Physical paper documents in the possession of the customer.

Data source: Remittance Provider (Agent) Workflow:

Data source: Intermediary bank via “Constancia” record Constancia documents are already in use as a form of proof of income for loan applications. They contain a 12-month remittance history and are generated by intermediary banks for customers for a small fee.


To see how we implemented financial history using SSI, check out the presentation PDF.

Data source: Customer has physical copies of receipts (manual upload by customer) Workflow:

Wallet guardianship & key recovery

Guardianship is the process required for controlling an Agent on behalf of a user. For Kiva Protocol implementations, typically the identity Issuer uses a Guardianship agency (e.g., the Central Bank) to hold Individual Agents in Guardianship. This allows for straightforward oversight and regulatory enforcement, and also a pathway to enable inclusion efforts that may necessitate delegation of Guardianship to a regulated FSP or otherwise.

A Key Management System handles key recovery processes on behalf of the user, consisting of securely backing up and recovering cryptographic secrets used to store or protect other information so that it can only be unlocked and recovered by its owner. The current iteration of Kiva Protocol implements biometric authentication to protect the wallets of users who have not claimed management over their own identity wallets (meaning users under Guardianship) such that they can only be unlocked by presenting the biometric template of the user through a participating organization that can then only interact with the user's wallet using the information sharing policies established by the rules of Guardianship.

Biometrics services / tools

Our approach was to provide an optional web service that was capable of performing fingerprint matching and fingerprint quality analysis. It was optional because we quickly realized that not all clients would be interested in using fingerprints as a method of unlocking access to a wallet. In addition, some of those who did want to use fingerprints had their own systems which they would rather use. Still, having such a web service available was useful for demonstrating the system's capabilities, and some clients did express interest in having us provide a fingerprint matching service.

As a matching engine, we turned to SourceAFIS. SourceAFIS was the only well-maintained open-source solution available to us, and we discovered that quite a few other actors were also using it in production, which spoke to its reliability. As the library was primarily written in Java, we decided that our fingerprint matching web service would similarly use a JVM language (we settled on Kotlin).

To determine fingerprint image quality, we relied on NFIQ2, a C++ library provided by NIST. This library is similarly open source and its use in production by many other actors speaks to its quality. Indeed, it often comes up as the standard solution to those who need to check the quality of fingerprint images. As we did not want to write a webservice in C++, we pre-loaded it as a binary in a docker image that we used to deploy our biometrics web services and called out to it at runtime using the NIFQ2 CLI.

eKYC approach

Upon conducting interviews with different local banks, it became clear that distribution of eKYC will be dependent on how easy it will be to integrate a common experience within a diverse ensemble of banking software. To this end, we worked with local partners to build and test a distribution vehicle that guaranteed a trusted deployment of an eKYC web wizard, while providing enough flexibility to the engineers working in the systems that will consume it.

The end result was the first version of our Web SDK that delivers drop-in integration for user-facing eKYC infrastructure and any software, especially banking.

For technical information see:

OIDC Integration

In the current software landscape, every organization is likely already using a vendor for user access and authentication. Rather than impose yet another login on potential integrators and their operators, we chose to support an open standard to connect our systems (and any potential deployment of it) with current vendors. The obvious choice was Open ID Connect (OIDC), and all our end user facing components regulate access through it.

For technical information see: