Keeta Network
  • Introduction
    • Start Developing
    • Create Your First Account
    • Send a Transaction
  • Architecture
    • Data Structure
    • Consensus
      • Voting Power
      • Votes
      • Vote Stapling
  • Components
    • Ledger
      • Get Ledger History
    • Blocks
      • Create a Block
      • Operations
        • Send
        • Receive
        • setInfo
        • modifyTokenSupply
        • modifyTokenBalance
        • updatePermissions
    • Nodes
      • Ledger Pruning
    • Accounts
      • Permissions
      • Storage Accounts
        • Create a Storage Account
        • Single-Token Storage Account
    • Key Pairs
      • Storing Key Pairs
    • Certificates
      • Get Certificates
  • Security
    • Digital Signatures
    • Post Quantum Readiness
    • Data Integrity
    • Protection From Common Attacks
  • Scalability
    • Benchmarks and Performance Metrics
    • Seperating Nodes from Hardware
    • Eliminating Mempools
  • Features
    • Identity Profiles
      • Utilizing Identity Profiles
    • Native Tokenization
      • Token Creation
        • Mint Tokens
        • Burn Tokens
        • Set Permissions
      • Built-in Rules Engine
    • Anchors
      • Creating an Anchor
  • Applications
    • Public Network
    • Private Sub Network
  • Industry Comparison
    • Keeta Network's Advantage
    • Resolving the Blockchain Trilemma
  • Guides
    • Tokenizing Real-World Assets
  • Other Documentation
    • Official Links
    • Tokenomics
    • Roadmap
    • Articles
      • Cryptographically Verifiable Identity Sharing with Keeta
Powered by GitBook
On this page
  1. Other Documentation
  2. Articles

Cryptographically Verifiable Identity Sharing with Keeta

PreviousArticles

Last updated 8 minutes ago

CtrlK
  • What Is a Certificate?
  • Sensitive Attributes and Commitment Schemes
  • Selective Disclosure with Encrypted Containers
  • Summary

In digital systems, establishing trust between parties often comes down to verifying identity attributes: names, emails, addresses, government IDs, etc. Sharing this data securely, selectively, and in a way that others can verify has long been a challenge—especially when both privacy and integrity are required.

Keeta provides a cryptographic framework for identity certification and selective disclosure using X.509 certificates, enhanced with commitment schemes and encrypted containers. This post outlines how it works.

What Is a Certificate?

In cryptographic terms, a certificate is a signed data structure used to assert claims about a subject. One entity (the issuer) attests to attributes of another entity (the subject) by issuing a certificate containing:

  • The subject’s public key

  • A set of attributes

  • The issuer’s digital signature over the certificate’s contents

Keeta builds on the standard X.509 certificate format, which is widely used in TLS, PKI systems, and identity infrastructure. X.509 supports an extensions mechanism that allows embedding additional, application-specific data within the certificate. Keeta uses this to encode structured identity attributes in a consistent, extensible format.

Sensitive Attributes and Commitment Schemes

In many cases, identity attributes are privacy-sensitive. Including them in plaintext inside a certificate would expose them to anyone with access to the certificate.

Keeta addresses this using a combination of encryption and cryptographic commitments. Specifically:

  1. The issuer encrypts the attribute value (e.g., full name, address) and a random salt using the subject’s public key.

  2. The issuer computes a commitment in the form of a cryptographic hash over:

    • the subject's account identifier (public key),

    • the attribute's cleartext value,

    • the salt.

This commitment is included in the certificate’s extension field, alongside the encrypted value and encrypted salt.This structure enables the following properties:

  • Binding: The commitment ties the attribute to a specific subject and value.

  • Hiding: The actual attribute value and salt remain encrypted.

  • Non-repudiation: The certificate is signed by the issuer and includes the commitment.

Because cryptographic hashes are one-way functions, the commitment cannot be reversed to reveal the attribute value, but can be used to verify it when disclosed later.

Selective Disclosure with Encrypted Containers

To share specific sensitive attributes with a third party, Keeta uses an "encrypted container." This is a payload encrypted to the public keys of one or more designated recipients.Here’s how the process works at a high level when a user shares attributes via the Keeta Wallet:

  1. Decryption:

    1. The client decrypts each sensitive attribute and its associated salt.

  2. Proof Generation:

    1. For each attribute, the client generates a proof consisting of:

      • The cleartext value

      • The salt

  3. Container Construction:

    1. All selected proofs are encrypted into a container using the public keys of the intended recipients.

  4. Link Generation:

    1. The client generates a link referencing:

      • The encrypted container

      • The source certificate

      • The subject's account (public key)

  5. Verification by Recipient:

    1. The recipient decrypts the container, retrieves the proofs, and:

      • Recomputes the commitment hash for each attribute

      • Compares it against the commitment embedded in the certificate

      • Validates that the certificate was issued by a trusted authority

This mechanism enables verifiable selective disclosure. Only the recipient can access the attribute value, and they can independently verify that it matches what the issuer originally certified—without needing to trust the subject.

Summary

Keeta provides a cryptographically robust model for identity certification and sharing:

  • Attributes are embedded in X.509 certificates using standardized extensions.

  • Sensitive attributes are encrypted and committed using cryptographic hash functions and salts.

  • Commitment schemes ensure attribute integrity without exposing values.

  • Encrypted containers enable secure, recipient-specific selective disclosure.

  • All proofs are verifiable against the original issuer certificate without relying on out-of-band trust.

This architecture supports privacy-preserving identity verification at internet scale, with use cases ranging from fintech onboarding to decentralized identity frameworks.

For more technical documentation or to integrate Keeta into your platform, contact our team.