Technical approach

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.

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.

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.

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.

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: https://docs.kivaprotocol.com/docs/ekyc-web-sdk