Identity Registrar

The Identity Registrar (IR) is a central component of the KIRA network, designed to bolster the integrity and authenticity of user accounts. It addresses the critical challenge of "Sybil attacks", where a single entity poses as multiple users. Through the IR, KIRA emphasizes the significance of genuine, unique user representation, ensuring a more democratic and fair governance structure.

At its core, the IR provides a mechanism for users to authenticate assertions about themselves, such as ownership of a website or an online handle. Unlike traditional centralized verification systems, the IR operates on mutual verification principles within the community. Users within the KIRA network can endorse the validity of claims made by others by giving their attestation, fostering an environment of collective trust. The framework of the IR is akin to a digital dictionary, allowing users to define key-value pairs relevant to their identity. For instance, associating a key website with the value example.com serves as proof of ownership of said website. Importantly, any alteration to these authenticated records necessitates re-verification, preserving the integrity of claims.

The essence of IR transcends mere claim verification. Addressing concerns of true sovereignty, IR refines the concept of social attestations. Instead of uniformly weighing attestations, the focus pivots to the trustworthiness of the attestor from an individual or application's perspective. This subjectivity highlights that in the vast sea of approvals, the ones deemed trustworthy to the user or a specific application are the ones that truly matter. It recognizes that while multiple individuals may appear non-sovereign from a network's viewpoint, in reality, their distinct identities hold weight. The IR thus fosters a nuanced, relative view of identity that adapts across applications and purposes, emphasizing the notion that when it comes to digital identity, objective truths are often overshadowed by the diverse perspectives they cater to.

The process of verifying an identity record involves a few steps:

It is important to note that verification requests must include a tip, which cannot be less than the min_identity_approval_tip network property (default: 2x the transaction cost of the approval/rejection transaction). This tip is meant to incentivize other accounts to verify identity records, or at least provide them with a refund of the transaction cost. Tips are paid regardless of whether the records are rejected or approved, ensuring that approvers are honest and trusted, rather than motivated solely by financial gain. The network governance can also choose to distrust any account at any time through a proposal process, marking them as potentially malicious and referencing the evidence.

KIRA offers a range of dedicated identity keys designed to make interactions with the network more user-friendly. These keys store various user-related information that can be interpreted by wallets, explorers, visualizers, and other front-end applications. Notably, KIRA allows for the creation of any custom key within the Identity Registrar, but it reserves certain key names like username and moniker by default. These reserved keys have special significance, affecting the visibility of nodes or accounts across different applications. What's more, the governance of the KIRA network can enforce these key-value pairs to remain globally unique, provided they do not already exist, which is managed by modifying the unique_identity_keys network property. As a result, users can send assets not just to a KIRA address, but also by simply providing a unique username or moniker. Once these unique keys are created, they cannot be deleted, ensuring a more streamlined and user-friendly experience.

Governance can create one or more of the following keys in the Identity Registrar as unique to increase consensus node public recognition and trust

Users can create one or several of the following keys in the Identity Registrar in order to make their account easier to identify and recognize by other users.

N/A

To add or edit identity records, use the register-identity-records CLI command. Provide the desired key-value pairs either in a JSON file by specifying its path with the --infos-file flag, or directly in the command as a JSON string using the --infos-json flag. Note that certain key names are reserved and may be required to be unique within the Identity Registrar.

To delete one or several identity records, use the delete-identity-records CLI command and provide the keys to be deleted as a comma-separated list using the --keys flag. Note that the keys moniker and username cannot be deleted.

To verify an identity record, use the request-identity-record-verify CLI command. Provide the address of the verifier using the --verifier flag, and the desired key(s) or record ID(s) using the --record-ids flag. Users can also provide a tip using the --tip flag to incentivize the verifier to review the request. Note that the tip value must be greater than twice the transaction fee value.

To verify or reject a request for identity record verification, use the handle-identity-records-verify-request CLI command. To approve the request, include the --approve flag and set its value to true. To reject the request, set the value of --approve to false. The ID of the request must also be provided. Only the verifier specified in the original request can approve or reject it.

Retrieve a specific identity record using the identity-record subcommand followed by the record’s identifier.

Fetch all identity records associated with a specific account using the identity-records-by-addr subcommand followed by the account’s address.

To query a specific record ID of a specific account, utilize the identity-records-by-addr subcommand in conjunction with jq filtering using the specific record ID.

Retrieve a specific record key of a specific account using the identity-records-by-addr subcommand and jq filtering.

Fetch all pending requests of a specific record ID using the identity-record-verify-requests subcommand followed by the record ID.

Retrieve all pending verification requests of a requester account using the identity-record-verify-requests-by-approver subcommand. For a more specific query, an optional $VERIFIER argument may be provided to filter the results to only display pending requests sent to a specific verifier/approver account.

Retrieve all pending verification requests for a verifier using the identity-record-verify-requests-by-approver subcommand. For a more specific query, an optional $ACCOUNT argument may be provided to filter the results to only display requests from a specific requester account.