Tenzro Testnet is live. Get testnet TNZO

PDIS Standard

The Programmable Decentralized Identity Standard (PDIS) is Tenzro Network's secondary identity protocol, providing full backward compatibility and interoperability with the primary TDIP standard. PDIS establishes a guardian-agent relationship model for human-machine identity management.

Overview

PDIS remains fully supported as a secondary identity standard alongside TDIP. Both did:tenzro: and did:pdis: formats are parsed and interoperable throughout the Tenzro Network ecosystem. While TDIP is the primary standard for new identity registrations, PDIS provides continuity for existing systems and specialized use cases.

The PDIS standard defines two complementary identity types: Guardians (human operators) and Agents (autonomous machines). This model creates clear hierarchies and delegation relationships between human controllers and their machine agents.

DID Format Specification

PDIS-1: Guardian DIDs

Guardian DIDs represent human operators who control one or more agent identities. The format follows a simple, predictable structure:

did:pdis:guardian:{uuid}

The UUID component is a globally unique identifier generated using UUID v4 (random) or v7 (timestamp-based with lexicographic ordering). Guardian identities are anchored to the blockchain and can be resolved across all network nodes.

PDIS-2: Agent DIDs

Agent DIDs represent machine identities that are controlled by a guardian. The controller relationship is embedded directly in the DID string:

did:pdis:agent:{controller}:{uuid}

The controller component references the guardian DID that has authority over this agent. This creates an explicit trust chain and delegation hierarchy. Agent identities inherit capabilities and permissions from their guardian while maintaining their own autonomous state.

Example Agent DID:

did:pdis:agent:did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000:7c9e6679-7425-40de-944b-e07fc1f90ae7

This agent is controlled by guardian did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000 and has its own identity 7c9e6679-7425-40de-944b-e07fc1f90ae7.

Interoperability with TDIP

The Tenzro identity subsystem provides seamless interoperability between PDIS and TDIP formats. Both standards are first-class citizens in the identity registry, and cross-standard references are fully supported.

Format Mapping

PDIS and TDIP identities map to equivalent concepts:

PDIS Guardian → TDIP Human did:pdis:guardian:{uuid} ≈ did:tenzro:human:{uuid} PDIS Agent → TDIP Machine (controlled) did:pdis:agent:{controller}:{uuid} ≈ did:tenzro:machine:{controller}:{uuid}

While the underlying data structures are equivalent, PDIS maintains its distinct namespace to preserve semantic meaning and enable protocol-specific features. Applications can choose to work with either standard or both simultaneously.

Cross-Standard Resolution

The identity registry resolves both PDIS and TDIP DIDs through the same resolution API. DID Documents exported for PDIS identities include cross-references to equivalent TDIP identities when available:

{ "@context": [ "https://www.w3.org/ns/did/v1", "https://tenzro.network/ns/identity/v1" ], "id": "did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000", "alsoKnownAs": [ "did:tenzro:human:550e8400-e29b-41d4-a716-446655440000" ], "verificationMethod": [...], "service": [...] }

Creating PDIS Identities

Guardian Registration

Registering a guardian identity through the CLI or SDK provisions a complete identity package including DID, cryptographic keys, and MPC wallet:

# CLI registration tenzro-cli identity register \ --type guardian \ --display-name "Alice Johnson" \ --kyc-tier basic # Expected output Guardian DID registered: did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000 Wallet address: 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb2 KYC tier: Basic (1)

The registration process generates an Ed25519 or Secp256k1 keypair, creates MPC threshold shares (default 2-of-3), encrypts the keystore with Argon2id-derived keys, and anchors the identity to the blockchain through a registration transaction.

Agent Provisioning

Agents are created with an explicit controller reference linking them to their guardian. The guardian's credentials and delegation scopes are inherited:

# Provision an agent for a guardian tenzro-cli identity register \ --type agent \ --controller "did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000" \ --capabilities "inference,settlement,payment" \ --max-transaction-value 1000000000000000000 # Expected output Agent DID registered: did:pdis:agent:did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000:7c9e6679-7425-40de-944b-e07fc1f90ae7 Wallet address: 0x8f3Cf7ad23Cd3CaDbD9735AFf958023239c6A063 Capabilities: inference, settlement, payment Max transaction value: 1.0 TNZO

Delegation and Permissions

PDIS implements fine-grained delegation scopes that control what actions an agent can perform on behalf of its guardian. These scopes are enforced at the protocol level across all network operations.

Delegation Scope Structure

Delegation scopes define boundaries for agent autonomy:

{ "max_transaction_value": "1000000000000000000", // 1 TNZO in wei "max_daily_spend": "5000000000000000000", // 5 TNZO per day "allowed_operations": [ "inference_request", "settlement_create", "payment_authorize" ], "allowed_contracts": [ "0x1234567890123456789012345678901234567890" ], "time_bound": { "start": "2024-01-01T00:00:00Z", "end": "2024-12-31T23:59:59Z" }, "allowed_payment_protocols": ["Mpp", "X402"], "allowed_chains": [1337, 1, 137] }

Scope Enforcement

The identity registry validates delegation scopes at transaction submission time. Operations exceeding delegated permissions are rejected before execution:

// Rust SDK example - scope validation use tenzro_identity::{IdentityRegistry, DelegationScope}; let registry = IdentityRegistry::new(); let agent_did = "did:pdis:agent:..."; let operation = "inference_request"; let value = 2_000_000_000_000_000_000u64; // 2 TNZO // Check if agent is allowed to perform this operation let can_execute = registry .validate_delegation(agent_did, operation, value) .await?; if !can_execute { return Err("Operation exceeds delegation scope"); }

Resolving PDIS Identities

Identity resolution retrieves the full identity document including verification methods, services, and controller relationships:

# CLI resolution tenzro-cli identity resolve \ "did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000" # JSON-RPC resolution curl -X POST https://rpc.tenzro.network \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "tenzro_resolveIdentity", "params": ["did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000"], "id": 1 }'

Resolution returns a W3C DID Document with all verification methods, service endpoints, controlled agents (for guardians), and controller references (for agents).

Credential Inheritance

Agents automatically inherit credentials issued to their guardian. This creates a trust chain where guardian KYC verification, payment authorizations, and capability attestations flow down to controlled agents.

// Example: Guardian receives KYC credential Guardian: did:pdis:guardian:550e8400... → Credential: KYC Level Enhanced (tier 2) → Issued by: did:tenzro:issuer:kyc-provider // Agent automatically inherits Agent: did:pdis:agent:did:pdis:guardian:550e8400...:7c9e6679... → Inherited credential: KYC Level Enhanced (tier 2) → Trust chain: issuer → guardian → agent

Credential inheritance respects delegation scopes. If a guardian has credentials authorizing high-value transactions but an agent has a restrictive delegation scope, the agent's scope takes precedence as the more restrictive permission set.

Revocation and Cascading Effects

Revoking a guardian identity automatically cascades to all controlled agents. This ensures that when a guardian's authority is revoked, all delegated agents lose their operational permissions simultaneously:

# Revoke a guardian and cascade to agents tenzro-cli identity revoke \ "did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000" \ --cascade # Result Revoked: did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000 Cascaded revocations: - did:pdis:agent:...:7c9e6679-7425-40de-944b-e07fc1f90ae7 - did:pdis:agent:...:9f4a2c81-8b63-42e1-a5d7-3c9b7e0f8d21 - did:pdis:agent:...:1a5b3c7d-4e8f-49a0-b2c6-8d9e0f1a2b3c

Migration from PDIS to TDIP

Existing PDIS identities can be migrated to TDIP format while preserving all cryptographic keys, wallet addresses, and credential history. Migration creates a new TDIP DID that references the original PDIS identity in its alsoKnownAs field:

# Migrate PDIS guardian to TDIP human tenzro-cli identity migrate \ --from "did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000" \ --to-standard tdip # Result Migration successful Original: did:pdis:guardian:550e8400-e29b-41d4-a716-446655440000 New DID: did:tenzro:human:550e8400-e29b-41d4-a716-446655440000 All credentials, controlled agents, and wallet addresses preserved. Both DIDs resolve to the same identity.

Use Cases for PDIS

While TDIP is the primary standard, PDIS remains valuable for specific scenarios:

Legacy System Integration: Organizations with existing PDIS-based infrastructure can continue using PDIS while gradually migrating to TDIP.

Explicit Guardian-Agent Hierarchies: Use cases requiring clear semantic distinction between human operators (guardians) and their machine delegates (agents).

Protocol-Specific Features: Applications built on PDIS-specific semantics can maintain compatibility while leveraging TDIP features through cross-standard resolution.

Technical Implementation

The PDIS implementation in the tenzro-identity crate uses the same underlying TenzroIdentity type as TDIP, with format-specific parsing and serialization:

// Rust implementation excerpt pub enum IdentityStandard { Tdip, Pdis, } impl TenzroIdentity { pub fn parse_did(did: &str) -> Result<(IdentityStandard, IdentityType)> { if did.starts_with("did:tenzro:") { // Parse TDIP format return Self::parse_tdip(did); } else if did.starts_with("did:pdis:") { // Parse PDIS format return Self::parse_pdis(did); } Err(IdentityError::InvalidDidFormat) } }

Both standards share the same identity registry, wallet binder, credential engine, and delegation scope validator. This ensures feature parity and seamless interoperability at the protocol level.