TDIP: Tenzro Decentralized Identity Protocol

Abstract

TDIP (Tenzro Decentralized Identity Protocol) is Tenzro Network's unified identity standard for both humans and machines, built on W3C Decentralized Identifiers (DIDs). As the AI age ushers in autonomous agents capable of independent action and financial transactions, identity systems must evolve beyond human-only models to accommodate machine actors with verifiable identities, permissions, and accountability.

TDIP provides a single coherent framework for representing, authenticating, and authorizing both human users and AI agents on the Tenzro Network. Each identity receives an auto-provisioned multi-party computation (MPC) wallet, enabling secure cryptographic operations without seed phrases. Fine-grained delegation scopes allow humans to grant specific permissions to their controlled machines, while verifiable credentials establish trust chains and attestations.

This paper describes the complete TDIP specification, including DID format conventions, the unified TenzroIdentity type, auto-provisioned MPC wallets, KYC tier support for regulatory compliance, delegation scope mechanisms for controlled machine actors, W3C verifiable credentials, cascading revocation, and interoperability with the legacy PDIS (Personal Decentralized Identity Standard) as a secondary standard.

1. Introduction

1.1 Motivation

Traditional identity systems were designed for human users interacting with applications. In the AI age, this paradigm is insufficient. Autonomous agents now conduct financial transactions, access APIs, negotiate contracts, and interact with other agents—all without direct human intervention. These machine actors require:

• Verifiable identities that can be authenticated across the network
• Cryptographic wallets for signing transactions and managing assets
• Fine-grained permission systems to limit scope of autonomous actions
• Credential inheritance from controlling human entities
• Revocation mechanisms that cascade through delegation chains
• Reputation tracking and accountability

TDIP addresses these requirements with a unified identity protocol that treats human and machine identities as first-class citizens within a single framework. By leveraging W3C DID standards and extending them with AI-specific capabilities, TDIP enables the Tenzro Network to support a hybrid human-machine economy.

1.2 Design Goals

• Unified framework: Single identity type for both humans and machines
• W3C compliance: Adhere to Decentralized Identifier standards for interoperability
• Auto-provisioned security: Every identity gets an MPC wallet without seed phrase management
• Fine-grained delegation: Humans control machine permissions with transaction limits, operation allowlists, and time bounds
• Verifiable credentials: W3C VC-compatible attestations with credential inheritance
• Cascading revocation: Revoking a controller automatically revokes all controlled identities
• KYC tier support: Ordered compliance levels for regulatory requirements
• Backward compatibility: Full support for PDIS as a secondary standard

1.3 Scope

This whitepaper covers the complete TDIP specification. It describes:

• DID format conventions for both TDIP and PDIS standards
• The unified TenzroIdentity type structure
• Auto-provisioned MPC wallet integration
• KYC tier definitions and ordered comparison
• Delegation scope field definitions and validation rules
• Verifiable credential types and proof mechanisms
• Cascading revocation algorithms
• W3C DID Document export/import
• Identity registry implementation and thread-safety guarantees
• Onboarding flows via RPC endpoints

2. DID Formats

2.1 TDIP DID Format (Primary)

TDIP uses the did:tenzro: method identifier. The format varies based on identity type:

# Human identity
did:tenzro:human:{uuid}

# Controlled machine identity (has a controller)
did:tenzro:machine:{controller}:{uuid}

# Autonomous machine identity (no controller)
did:tenzro:machine:{uuid}

Where:

• uuid is a Version 4 UUID (128-bit random identifier)
• controller is the DID of the controlling human or machine identity

2.2 PDIS DID Format (Secondary)

PDIS (Personal Decentralized Identity Standard) remains fully supported as a secondary standard for backward compatibility. PDIS defines two specification levels:

# PDIS-1: Guardian (human identity)
did:pdis:guardian:{uuid}

# PDIS-2: Agent (controlled machine identity)
did:pdis:agent:{controller}:{uuid}

PDIS identities map to TDIP equivalents:

• did:pdis:guardian:{uuid} → did:tenzro:human:{uuid}
• did:pdis:agent:{controller}:{uuid} → did:tenzro:machine:{controller}:{uuid}

2.3 DID Parsing and Validation

The TDIP parser accepts both did:tenzro: and did:pdis: formats. All DIDs are validated to ensure:

• Correct method identifier prefix
• Valid identity type (human, machine, guardian, agent)
• Well-formed UUID components
• Controller DID exists and is valid (for controlled identities)

3. Unified Identity Type

3.1 TenzroIdentity Structure

The core identity structure represents both human and machine identities with the following components:

Identity Structure:
    - DID (unique identifier in W3C format)
    - Public keys for cryptographic verification
    - Identity-specific data (human or machine)
    - Status (Active, Suspended, or Revoked)
    - Auto-provisioned wallet binding
    - Verifiable credentials collection
    - Service endpoints (APIs, protocols)
    - Timestamps and metadata

Field Descriptions:

3.2 IdentityData Enum

Identity data is differentiated between human and machine types with distinct attributes:

Human Identity:
    - Display name
    - KYC verification tier
    - List of controlled machine identities

Machine Identity:
    - Capability declarations
    - Delegation scope (permission boundaries)
    - Controller identity reference
    - Reputation score
    - Agent service integration

3.3 Human Identity Data

3.4 Machine Identity Data

3.5 Identity Status

Identity status has three defined states:

Identity Status States:
    Active     - Identity is valid and operational
    Suspended  - Temporarily disabled, can be reactivated
    Revoked    - Permanently revoked, cannot be reactivated

4. Auto-Provisioned MPC Wallets

4.1 Overview

Every TDIP identity (both human and machine) receives an auto-provisioned MPC (multi-party computation) wallet upon registration. This wallet enables cryptographic operations without requiring users to manage seed phrases or private keys directly.

4.2 Wallet Architecture

The auto-provisioned wallet system uses threshold cryptography with the following characteristics:

• Threshold scheme: 2-of-3 by default (2 shares required to sign)
• Key generation: Ed25519 or Secp256k1 keypair generated on registration
• Share distribution: Private key split into 3 shares using Shamir's Secret Sharing
• Address derivation: Wallet address derived from the public key
• No seed phrases: Users never see or manage raw private keys

4.3 Wallet Provisioning Flow

When an identity is registered (via tenzro_participate or tenzro_importIdentity RPC), the following steps occur:

1. Generate a fresh Ed25519 or Secp256k1 keypair
2. Split the private key into 3 shares using threshold cryptography
3. Store share 1 in local encrypted keystore (Argon2id + AES-256-GCM)
4. Store share 2 in TEE enclave (if available) or encrypted cloud backup
5. Store share 3 in distributed recovery mechanism or secondary device
6. Derive wallet address from public key
7. Bind wallet to identity in the IdentityRegistry
8. Persist wallet metadata to persistent storage

4.4 Multi-Asset Support

Auto-provisioned wallets support multiple assets:

• TNZO (native token)
• USDC, USDT (stablecoins)
• ETH (Ethereum bridge)
• SOL (Solana bridge)
• BTC (Bitcoin bridge)

4.5 Signature Verification

All transactions signed by MPC wallets undergo automatic cryptographic verification via tenzro_crypto::signatures::verify(). The wallet system performs post-signing verification to ensure:

• Signature matches the transaction hash
• Public key corresponds to the wallet address
• Signature algorithm is correct for the key type

5. KYC Tier Support

5.1 Overview

TDIP includes built-in KYC (Know Your Customer) tier support for regulatory compliance. Human identities are assigned a tier level that represents the degree of identity verification completed.

5.2 Tier Definitions

5.3 Ordered Comparison

KYC tiers support ordered comparison (<, >, >=, etc.) for access control logic:

// Example: Require Enhanced tier or higher for a sensitive operation
if identity.kyc_tier() >= KycTier::Enhanced {
    // Allow operation
} else {
    // Deny access
}

5.4 Tier Upgrades

Users can upgrade their KYC tier by submitting verification documents through approved KYC provider integrations. Tier upgrades are recorded as verifiable credentials issued by the KYC provider and attached to the identity.

6. Delegation Scopes

6.1 Overview

Delegation scopes enable humans to grant fine-grained permissions to their controlled machine identities. A machine identity with a delegation scope can only perform actions within the boundaries defined by its controller.

6.2 DelegationScope Structure

Delegation Scope Fields:
    - Maximum transaction value limit
    - Maximum daily spending limit
    - Allowed operations list
    - Allowed smart contracts list
    - Time-based restrictions
    - Allowed payment protocols
    - Allowed blockchain networks

6.3 Field Definitions

6.4 TimeBound Structure

Time Boundary:
    - Not before: earliest valid timestamp
    - Not after: latest valid timestamp

6.5 Unrestricted Scope

A special factory method DelegationScope::unrestricted() creates a scope with no restrictions:

Unrestricted Scope:
    - No transaction value limits
    - No daily spending limits
    - All operations allowed (empty allowlist)
    - All contracts allowed (empty allowlist)
    - No time restrictions
    - All payment protocols allowed
    - All blockchain networks allowed

6.6 Delegation Scope Validation

The payment system enforces delegation scope validation before allowing machine identity payments. The system validates:

• Transaction value does not exceed max_transaction_value
• Daily spend does not exceed max_daily_spend
• Operation type is in allowed_operations (if non-empty)
• Payment protocol is in allowed_payment_protocols (if non-empty)
• Chain ID is in allowed_chains (if non-empty)
• Current timestamp is within time_bound window (if set)

7. Verifiable Credentials

7.1 Overview

TDIP supports W3C Verifiable Credentials for attaching cryptographically signed attestations to identities. Credentials can be issued by trusted third parties (e.g., KYC providers, model registries, TEE providers) or inherited from controlling identities.

7.2 VerifiableCredential Structure

Verifiable Credential Structure:
    - Unique credential identifier
    - Credential type classification
    - Issuer identity reference
    - Subject identity reference
    - Issuance timestamp
    - Optional expiration timestamp
    - Key-value claims
    - Cryptographic proof

7.3 Credential Types

Credential Types:
    - KYC Verification (tier attestation)
    - Provider Attestation (model/TEE provider verification)
    - Capability Proof (machine capability attestation)
    - Custom types (application-specific credentials)

7.4 CredentialProof Structure

Credential Proof Structure:
    - Proof type (e.g., "Ed25519Signature2020")
    - Creation timestamp
    - Verification method (DID of signing key)
    - Proof purpose (e.g., "assertionMethod")
    - Cryptographic signature bytes

7.5 Credential Issuance

To issue a verifiable credential:

1. Issuer creates a credential with subject DID and claims
2. Issuer signs the credential using their private key
3. Issuer attaches the credential to the subject's identity via add_credential()
4. Subject's identity is updated with the new credential

7.6 Credential Inheritance

Machine identities can inherit credentials from their controller. For example, if a human identity has a KYC verification credential, all controlled machine identities inherit that verification status. This enables machines to act with the compliance status of their human operator.

7.7 Credential Verification

Credential verification checks:

• Credential has not expired (expiration_date)
• Issuer DID resolves to a valid identity
• Cryptographic signature in proof_value is valid
• Signature was created by the issuer's verification method

8. Cascading Revocation

8.1 Overview

TDIP implements cascading revocation to prevent orphaned machine identities. When a human identity is revoked, all controlled machine identities are automatically revoked in a single operation.

8.2 Revocation Algorithm

The revocation algorithm performs cascading revocation:

1. Mark the target identity as Revoked status
2. If the identity is human, retrieve the list of controlled machines
3. For each controlled machine DID, recursively revoke that identity
4. Update timestamps for all affected identities
5. Persist all changes to the identity registry

8.3 Revocation Propagation

Cascading revocation supports multi-level delegation chains. If a machine identity controls other machine identities (delegated agent-to-agent control), revoking the parent machine revokes all descendants.

9. W3C DID Document Export

9.1 Overview

TDIP identities can be exported as W3C DID Documents for interoperability with external identity systems, wallets, and verifiers. The DID Document provides a standard JSON-LD representation of the identity.

9.2 DID Document Structure

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:tenzro:human:abc123",
  "verificationMethod": [
    {
      "id": "did:tenzro:human:abc123#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:tenzro:human:abc123",
      "publicKeyMultibase": "z6MkpTHR8..."
    }
  ],
  "authentication": [
    "did:tenzro:human:abc123#key-1"
  ],
  "assertionMethod": [
    "did:tenzro:human:abc123#key-1"
  ],
  "service": [
    {
      "id": "did:tenzro:human:abc123#mcp",
      "type": "MCPServer",
      "serviceEndpoint": "https://mcp.example.com/agent"
    }
  ]
}

9.3 Export and Import

The identity system provides export and import functionality:

• Export identity as W3C DID Document (JSON format)
• Import identity from W3C DID Document (JSON format)

10. Identity Registry

10.1 Overview

The identity registry is a thread-safe central store for all TDIP identities, providing methods for registration, resolution, revocation, and credential management.

10.2 Core Methods

10.3 Thread Safety

The identity registry uses concurrent data structures for high-performance access. Multiple operations can register, resolve, and update identities simultaneously without blocking.

10.4 WalletBinder Integration

The wallet provisioning service auto-provisions MPC wallets for newly registered identities. During identity registration, the system:

1. Generates a fresh cryptographic keypair (Ed25519 or Secp256k1)
2. Splits the private key into threshold shares
3. Stores shares in encrypted storage
4. Derives wallet address from public key
5. Binds wallet address to the identity

11. Onboarding Flows

11.1 One-Click Participation

The network participation API endpoint provides one-click network onboarding:

POST /rpc
{
  "jsonrpc": "2.0",
  "method": "tenzro_participate",
  "params": {
    "display_name": "Alice",
    "password": "secure_password_123"
  },
  "id": 1
}

Steps performed:

1. Generate Ed25519 keypair
2. Split private key into 3 shares using Shamir's Secret Sharing
3. Encrypt shares with password-derived key (Argon2id KDF + AES-256-GCM)
4. Create TDIP human identity with did:tenzro:human:{uuid}
5. Auto-provision MPC wallet and bind to identity
6. Detect hardware profile (CPU, RAM, GPU, TEE capabilities)
7. Persist identity and wallet metadata to persistent storage
8. Return identity DID, wallet address, and hardware profile to user

11.2 Import Existing Identity

The identity import API endpoint allows importing an existing keypair:

POST /rpc
{
  "jsonrpc": "2.0",
  "method": "tenzro_importIdentity",
  "params": {
    "display_name": "Bob",
    "private_key": "0x1234...",
    "key_type": "Ed25519",
    "password": "secure_password_456"
  },
  "id": 1
}

Steps performed:

1. Parse and validate private key
2. Split private key into 3 shares
3. Encrypt shares with password-derived key
4. Create TDIP human identity
5. Bind wallet to identity
6. Persist to persistent storage
7. Return identity DID and wallet address

11.3 Desktop App Onboarding

The Tenzro Desktop App (Tauri + React) includes a Setup page that gates access to the Dashboard. On first launch, users are presented with two tabs:

• Create New: Generates fresh identity and wallet with hardware profile detection
• Import Existing: Imports existing keypair and creates identity binding

On success, the app redirects to the Dashboard and displays the user's identity DID, wallet address, and detected hardware profile.

12. Security Considerations

12.1 Key Management

MPC wallet private keys are split into 3 shares using Shamir's Secret Sharing. The threshold is 2-of-3, meaning any 2 shares can reconstruct the private key. Shares are stored:

• Share 1: Local encrypted keystore (Argon2id + AES-256-GCM)
• Share 2: TEE enclave (if available) or encrypted cloud backup
• Share 3: Distributed recovery mechanism or secondary device

Sensitive key material is securely cleared from memory on drop to prevent memory scraping attacks.

12.2 Password-Based Encryption

User passwords are used to derive encryption keys via Argon2id KDF with the following parameters:

• Memory: 64 MB
• Iterations: 3
• Parallelism: 4 threads
• Output length: 32 bytes (AES-256 key)

Key shares are encrypted with AES-256-GCM authenticated encryption before storage.

12.3 Delegation Scope Enforcement

Delegation scopes are enforced at multiple layers:

• Payment layer: The payments module validates transaction value, daily spend, protocol, and chain ID before authorizing machine payments
• VM layer: The VM execution layer checks allowed contracts and operations before executing smart contract calls
• Settlement layer: The settlement engine enforces spend limits on escrow releases and micropayment channels

12.4 Credential Verification

All verifiable credentials undergo cryptographic verification before acceptance. The verification process validates:

• Issuer DID resolves to a valid active identity
• Credential has not expired
• Cryptographic signature is valid for the credential data
• Signature was created by the issuer's verification method (public key)

13. Future Work

13.1 On-Chain Identity Anchoring

A future version will anchor identities on-chain via the Tenzro Ledger, enabling global resolution and preventing DID spoofing across distributed nodes.

13.2 Advanced Credential Types

Future credential types will include:

• Selective disclosure credentials (using zero-knowledge proofs)
• Credential revocation lists (on-chain revocation registry)
• Reputation credentials (dynamic score updates based on network activity)

13.3 Cross-Chain Identity Resolution

TDIP will integrate with cross-chain bridges (LayerZero, Chainlink CCIP) to enable identity resolution across multiple blockchain networks. This allows a single TDIP identity to interact with Ethereum, Solana, and other chains.

13.4 Biometric Authentication

For Full KYC tier (tier 3), biometric authentication will be supported via WebAuthn integration in the desktop app and CLI.

14. Conclusion

TDIP provides a unified identity framework for the AI age, enabling both humans and machines to participate as first-class citizens in the Tenzro Network. By combining W3C DID standards with auto-provisioned MPC wallets, fine-grained delegation scopes, verifiable credentials, and cascading revocation, TDIP addresses the unique requirements of autonomous agent economies.

The protocol supports regulatory compliance via KYC tiers while preserving user privacy and control. Machine identities can operate autonomously within well-defined permission boundaries, and credential inheritance ensures trust chains are preserved through delegation hierarchies.

As the Tenzro ecosystem evolves, TDIP will serve as the foundation for decentralized identity, enabling secure, verifiable, and accountable interactions between humans, agents, and infrastructure providers across the network.

References

• W3C Decentralized Identifiers (DIDs) v1.0 — https://www.w3.org/TR/did-core/
• W3C Verifiable Credentials Data Model v1.1 — https://www.w3.org/TR/vc-data-model/
• Shamir's Secret Sharing — https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
• Argon2 Password Hashing — https://github.com/P-H-C/phc-winner-argon2
• Tenzro Network GitHub Repository — https://github.com/tenzro/tenzro-network