Skip to main content

Identity Registrar

Overview​

The Identity Registrar 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 records (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:

  1. An user creates an on-chain transaction that includes the desired key and value for the identity record.
  2. It then requests verification from a publicly trusted KIRA account for the record, and include a tip as payment for the service provided.
  3. If the verification is successful, the record will remain verified unless any changes are made to the verified key.
  4. If any changes are made to the key after the verification process, the record will no longer be considered verified.
  5. If any changes are made to the key, any pending request for that key are automatically canceled.

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​

caution

Once a key is made unique by governance, it cannot be reverted back to non-unique. This limitation is in place to avoid disrupting the logic of applications that depend on the key's uniqueness.

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 since they affect the visibility of nodes or accounts across different applications. KIRA’s governance can enforce these records 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 associated to the address. Once these unique keys are created, they cannot be deleted, ensuring a more streamlined and user-friendly experience.

Consensus Node Records Examples​

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

NAMETYPEDESCRIPTION
monikerstringIdentifies validator name as seen on the leaderboard table.
descriptionstringA longer description of validator node
websitestringURL to the validator website
logostringURL to .SVG image (256kB max) representing validator entity
socialstringAny social profiles such as Twitter, Telegram, etc…
contactstringEmail address, url, or another emergency contact
validator_node_idstringNode ID of the validator node. Required to identify the node in the network visualizer.

Users Records Examples​

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.

NAMETYPEDESCRIPTION
usernamestringIdentifies your name as seen on the network explorer. The value can be used for the purpose of sending transactions similarly to ENS domain.
avatarstringURL to .SVG image or gif (256kB max)

Parameters​

NAMETYPEEXAMPLEDESCRIPTION
iduint64153789A unique identifier for the Identity Record.
addressstringkira1vgy0v6l593lxghv9v8a98nl87x4y2uvfn0yn7rThe address of the user associated with the Identity Record.
keystringwebsiteThe key representing the type of identity information, e.g., "website" for website ownership. Can be custom or reserved such as username or moniker.
valuestringexample.comThe value associated with the key, serving as proof of ownership or association, e.g., a website URL for a website key.
dategoogle.protobuf.Timestamp2023-09-28T12:34:56ZThe timestamp indicating when the Identity Record was created.
verifiers[]string[kira1vgy0v6l59…, kira1gurt0g67y9…"]A list of addresses of users who have verified the validity of the Identity Record.

CLI Syntax & Examples​

note

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.

note

$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 Guide page.

Transactions​

register-identity-recordsAdd or edit identity records.
delete-identity-recordsDelete one or several identity records.
request-identity-record-verifyRequest verification for an identity record.
handle-identity-records-verify-requestVerify or reject requests for identity record verification.

Adding & Editing Records​

To add or edit identity records, use the register-identity-records CLI command. Provide the desired records 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.

Flags

  • $INFOSFILE: The path to the file containing information for the identity request.
  • $INFOSJSON: The JSON string containing information for the identity request.
sekaid tx customgov register-identity-records \
--from=$SIGNER $FLAGS_TX \
[ --infos-file=$INFOSFILE || --infos-json=$INFOSJSON ]
# 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 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.

Flags

  • $KEYS: Comma-separated list of keys.
sekaid tx customgov delete-identity-records \
--from=$SIGNER $FLAGS_TX \
--keys=$KEYS

Requesting Record Verification​

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.

Flags

  • $VERIFIER: The verifier’s address.
  • $RECORDIDS: Comma-separated list of identity record ids.
  • $TIP: The tip to be given to the verifier.
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 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.

Args

  • $ID: Id of the key to be approved/rejected.

Flags

  • $APPROVE: The flag to approve or reject the verification request. Defaults to true.
sekaid tx customgov handle-identity-records-verify-request \
--from=$SIGNER $FLAGS_TX \
$ID --approve=$APPROVE
Building the future of trustless computing by enabling scalable solutions for resource-intensive applications
2024 KIRA Network, All rights reserved.
Ecosystem
HomeToken & EconomicsBuild on KIRARun a node
Resources
GithubCareersBlogContact us
Community
XTelegramDiscord
2024 KIRA Network, All rights reserved.