Search
Duplicate
Try Notion
🚧🚧

Identity Registrar

Concept

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.

Record verification process

The process of verifying an identity record involves a few steps:
An user creates an on-chain transaction that includes the desired key and value for the identity record.
It then requests verification from a publicly trusted KIRA account for the key-value pair, and include a tip as payment for the service provided.
If the verification is successful, the record will remain verified unless any changes are made to the verified key.
If any changes are made to the key after the verification process, the record will no longer be considered verified.
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.

Unique identity keys

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, 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."

Parameters

Consensus node dedicated records

A consensus node can create one or more of the following keys in the Identity Registrar to increase its public recognition and trust
NAME
TYPE
DESCRIPTION
moniker
string
Identifies validator name as seen on the leaderboard table.
description
string
A longer description of validator node
website
string
URL to the validator website
logo
string
URL toΒ .SVGΒ image (256kB max) representing validator entity
social
string ,string , …
Comma-separated URL list of any social profiles such as Twitter, Telegram, etc…
contact
string
Email address, url, or another emergency contact
validator_node_id
string
Node ID of the validator node. Required to identify the node in the network visualizer.
sentry_node_id
string ,string , …
Comma-separated list of sentry node IDs, required to identify validators public sentry nodes in the network visualizer
interx_pub_keys
string ,string , …
Comma-separated list of INTERX server public signing keys

Users dedicated records

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.
NAME
TYPE
DESCRIPTION
username
string
Identifies your name as seen on the network explorer. The value can be used for the purpose of sending transactions similarly to ENS domain.
avatar
string
URL toΒ .SVGΒ image or gif (256kB max)

CLI syntax & examples

Governance

N/A

Transactions

tx/customgov
register-identity-records - Submit a transaction to create an identity record.
delete-identity-records - Submit a transaction to delete an identity records.
request-identity-record-verify - Submit a transaction to request an identity verify record.
handle-identity-records-verify-request - Submit a transaction to approve or reject identity records verify request.

Queries

query/customgov
all-identity-records - Query all identity records.
identity-record - Query identity record by id.
identity-records-by-addr - Query identity records by owner.
identity-record-verify-request - Query identity record verify request by id.
identity-record-verify-requests-by-requester - Query identity records verify requests by requester.
identity-record-verify-requests-by-approver - Query identity record verify request by approver.

Syntax & examples

Callout icon
Each CLI command and proposal process in KIRA requires specific permissions. These permissions must be added to the account's whitelist or obtained as sudo permissions for direct changes. Refer to the Roles & Permissions documentation for more details. $SIGNER represents the transaction signer's account name or address. For instructions on setting common flags as environment variables, such as $FLAGS_TX and $FLAGS_QR, see the CLI flags configuration section
$INFOSFILE
string
The path to the file containing for identity request.
$INFOSJSON
string
The infos json for identity request.
$KEYS
string
Comma-separated list of keys.
$TIP
string
The tip to be given to the verifier.
$RECORDIDS*
string
Comma-separated list of identity record ids
$VERIFIER*
string
The verifier’s address.
$APPROVE*
bool
true
The flag to approve or reject the verification request.
$ID*
int
Id of the key to be approved/rejected.

Adding/Editing records

To add or edit identity records using the register-identity-records CLI, provide the desired key-value pairs in either 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. It is important to note that certain key names are reserved and may be required to be unique within the Identity Registrar.
Bash
Copy
sekaid tx customgov register-identity-records \ --from=$SIGNER $FLAGS_TX \ [ --infos-file=$INFOSFILE || --infos-json=$INFOSJSON ]
​
Bash
Copy
# Example # from an id.json file with below content : # { # "key1": "value1", # "key2": "value2" # } sekaid tx customgov register-identity-records \ --from=$SIGNER $FLAGS_TX \ --infos-file="path-to-id.json" # providing json format manually sekaid tx customgov register-identity-records \ --from=$SIGNER $FLAGS_TX \ --infos-json="{\"$KEY1\":\"$VAL1\",\"$KEY2\":\"$VAL2\"}"
​

Deleting records

To delete one or several identity records, use the delete-identity-records CLI 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.
Bash
Copy
sekaid tx customgov delete-identity-records \ --from=$SIGNER $FLAGS_TX \ --keys=$KEYS
​

Requesting record verification

In order to verify an identity record, use the request-identity-record-verify CLI and provide the address of the verifier using --verifier and the desired key(s) or record ID(s) using --record-ids. Users can also provide a tip using --tip to incentivize the verifier to review the request. It is important to note that the tip value must be greater than twice the transaction fee value.
Bash
Copy
sekaid tx customgov request-identity-record-verify \ --from=$SIGNER $FLAGS_TX \ --verifier=$VERIFIER --record-ids=$RECORDIDS --tip=$TIP
​

Verifying or rejecting records verification requests

To verify or reject a request for identity record verification, use the handle-identity-records-verify-request CLI. To approve the request, include the --approve flag and set its value to true. To reject the request, users can set the value of --approve to false. The ID of the request must also be provided. (Reminder: Only the verifier specified in the original request can approve or reject it)
Bash
Copy
sekaid tx customgov handle-identity-records-verify-request \ --from=$SIGNER $FLAGS_TX \ $ID --approve=$APPROVE
​

Queries

$VERIFIER*
string
The verifier’s address.
$ACCOUNT*
string
The account’s address.
$ID*
int
Id of the record.

Records queries

List all exisiting records

Bash
Copy
sekaid query customgov all-identity-records $FLAGS_QR | jq
​

Display one record id

Bash
Copy
sekaid query customgov identity-record $ID $FLAGS_QR | jq
​

List all records of a specific account

Bash
Copy
sekaid query customgov identity-records-by-addr $ACCOUNT $FLAGS_QR | jq
​

Display one specific record id of a specific account

Bash
Copy
sekaid query customgov identity-records-by-addr $ACC_ADDR $FLAGS_QR | jq ".records | .[] | select(.id==\"$ID\")"
​

Display one specific record key of a specific account

Bash
Copy
sekaid query customgov identity-records-by-addr $ACC_ADDR $FLAGS_QR | jq ".records | .[] | select(.key==\"$KEY\")"
​

Requests queries

Display all pending requests of a specific record id

Bash
Copy
sekaid query customgov identity-record-verify-requests-by-requester $ID $FLAGS_QR | jq
​

List all pending requests of an account

Bash
Copy
sekaid query customgov identity-record-verify-requests-by-requester $ACCOUNT $FLAGS_QR | jq
​

List all pending requests from an account to a specific verifier

Bash
Copy
sekaid query customgov identity-record-verify-requests-by-requester $ACCOUNT $FLAGS_QR | jq ".verify_records | .[] | select(.verifier==\"$VERIFIER\")"
​

List all pending requests of a verifier

Bash
Copy
sekaid query customgov identity-record-verify-requests-by-approver $VERIFIER $FLAGS_QR | jq
​

List all pending requests of a verifier from a specific account

Bash
Copy
sekaid query customgov identity-record-verify-requests-by-approver $VERIFIER $FLAGS_QR | jq ".verify_records | .[] | select(.address==\"$ACCOUNT\")"
​