Tenzro Testnet is live —request testnet TNZO

Tenzro Decentralized Identity Protocol (TDIP)

TDIP is Tenzro's unified identity protocol designed for both humans and machines in the AI age. It provides W3C DID-compatible identities, verifiable credentials, delegation scopes, and auto-provisioned MPC wallets.

Overview

The Tenzro Decentralized Identity Protocol (TDIP) solves a fundamental challenge in AI infrastructure: providing secure, verifiable identities for both humans and autonomous agents. TDIP is the primary identity standard on Tenzro Network, with PDIS (Personal Data Identity Standard) fully supported as a secondary standard.

Key Features

  • Unified Identity Model — Single identity type for humans and machines
  • W3C DID Compatible — Fully compliant with W3C Decentralized Identifier standard
  • Verifiable Credentials — Issue and verify credentials with proof inheritance
  • Delegation Scopes — Fine-grained permission control for agent actions
  • Auto-Provisioned Wallets — Every identity gets a secure MPC wallet
  • Cascading Revocation — Revoking a controller revokes all controlled identities
  • OAuth 2.1 + DPoP JWTs — Decentralized network credentials minted via tenzro_onboardHuman / tenzro_onboardDelegatedAgent / tenzro_onboardAutonomousAgent (RFC 9449 / RFC 9396), DPoP-bound to a holder Ed25519 key, used by both humans and agents to authenticate write operations
  • Token Exchange (RFC 8693) — A parent token holder mints a child JWT with a strict subset of RAR grants and AAP capabilities via tenzro_exchangeToken; the child's controller_did is set to the parent sub for auditable agent-spawns-agent delegation chains
  • Introspection & Discoverytenzro_introspectToken (RFC 7662) returns {active: false} for invalid/expired tokens (no information leakage) and the full claim set otherwise; tenzro_oauthDiscovery (RFC 8414) exposes issuer metadata at /.well-known/openid-configuration with the AAP claim list

DID Format

TDIP uses the did:tenzro: method with distinct formats for humans and machines:

Human Identity

did:tenzro:human:{uuid}

Example: did:tenzro:human:550e8400-e29b-41d4-a716-446655440000

Machine Identity (Controlled)

did:tenzro:machine:{controller}:{uuid}

Example: did:tenzro:machine:did:tenzro:human:550e8400...:6ba7b810-9dad-11d1-80b4-00c04fd430c8

Machine Identity (Autonomous)

did:tenzro:machine:{uuid}

Example: did:tenzro:machine:6ba7b810-9dad-11d1-80b4-00c04fd430c8

Identity Types

Human Identity

Human identities represent real people and include:

  • display_name — Human-readable name
  • kyc_tier — KYC verification level (0-3)
  • controlled_machines — List of machine DIDs controlled by this human

KYC Tiers

  • Tier 0: Unverified — No KYC, basic functionality
  • Tier 1: Basic — Email verification, limited transaction amounts
  • Tier 2: Enhanced — Government ID verification, higher limits
  • Tier 3: Full — Complete KYC, unrestricted access

Machine Identity

Machine identities represent AI agents, services, or devices and include:

  • capabilities — List of agent capabilities (e.g., ["inference", "trading"])
  • delegation_scope — Permission boundaries
  • controller_did — DID of controlling entity (optional for autonomous agents)
  • reputation — Network reputation score (0.0-1.0)
  • tenzro_agent_id — Internal agent system ID (optional)

Delegation Scopes

Delegation scopes define fine-grained permissions for machine identities, enabling humans to safely delegate actions to AI agents.

Scope Parameters

{
  "max_transaction_value": "1000.0 TNZO",
  "max_daily_spend": "5000.0 TNZO",
  "allowed_operations": ["transfer", "inference_request"],
  "allowed_contracts": ["0xabc...", "0xdef..."],
  "time_bound": {
    "start": "2026-01-01T00:00:00Z",
    "end": "2026-12-31T23:59:59Z"
  },
  "allowed_payment_protocols": ["Mpp", "X402"],
  "allowed_chains": [1337, 1]
}

Example Use Cases

Trading Agent

Max transaction: $10,000 | Max daily: $50,000 | Operations: swap, provide_liquidity | Time: Market hours only

Inference Agent

Max transaction: 100 TNZO | Max daily: 1000 TNZO | Operations: inference_request | Protocols: MPP, x402

Payment Bot

Max transaction: 50 USDC | Max daily: 500 USDC | Operations: transfer | Allowed chains: Tenzro, Ethereum

W3C DID Documents

TDIP identities can be exported as standard W3C DID Documents for interoperability:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:tenzro:human:550e8400-e29b-41d4-a716-446655440000",
  "verificationMethod": [{
    "id": "did:tenzro:human:550e8400...#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:tenzro:human:550e8400...",
    "publicKeyMultibase": "z6MkpTHR8..."
  }],
  "authentication": ["did:tenzro:human:550e8400...#key-1"],
  "service": [{
    "id": "did:tenzro:human:550e8400...#wallet",
    "type": "WalletService",
    "serviceEndpoint": "https://wallet.tenzro.network/api"
  }]
}

Verifiable Credentials

TDIP supports W3C Verifiable Credentials for attestations, certifications, and reputation:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "KycCredential"],
  "issuer": "did:tenzro:human:issuer-uuid",
  "issuanceDate": "2026-03-20T12:00:00Z",
  "expirationDate": "2027-03-20T12:00:00Z",
  "credentialSubject": {
    "id": "did:tenzro:human:550e8400...",
    "kyc_tier": 2
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-20T12:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:tenzro:human:issuer-uuid#key-1",
    "proofValue": "z58DAdF..."
  }
}

Credential Inheritance

Machine identities automatically inherit credentials from their controllers:

  • If human has KYC Tier 2, their controlled agents inherit Tier 2 privileges
  • If human credential expires, all agent credentials expire
  • Credentials can be explicitly issued to agents for additional attestations

Registration and Resolution

Register Human Identity

# Via CLI
tenzro identity register \
--type human \
--display-name "Alice"
# Output: did:tenzro:human:550e8400...

Register Machine Identity

# Controlled by human
tenzro identity register \
--type machine \
--controller did:tenzro:human:550e8400... \
--capabilities inference,trading
# Autonomous agent
tenzro identity register \
--type machine \
--capabilities inference

Resolve DID

tenzro identity resolve did:tenzro:human:550e8400...

List Identities

tenzro identity list
// Rust - List all registered identities
let result = client.identity().list_identities().await?;
println!("Human: {}, Machine: {}", result["human_count"], result["machine_count"]);
// TypeScript
const result = await client.identity.listIdentities();
console.log(`Human: ${result.human_count}, Machine: ${result.machine_count}`);

Add Credential

tenzro identity add-credential \
--did did:tenzro:human:550e8400... \
--type KycCredential \
--issuer did:tenzro:human:issuer-uuid \
--data '{"kyc_tier": 2}'
// Rust - Add a verifiable credential to an identity
let result = client.identity().add_credential(
    "did:tenzro:human:abc123",
    "KycAttestation",
    Some("did:tenzro:human:issuer"),
    Some(serde_json::json!({"tier": "enhanced", "verified": true})),
).await?;
println!("Credential: {}", result["credential_id"]);
// TypeScript
const result = await client.identity.addCredential(
    "did:tenzro:human:abc123",
    "KycAttestation",
    "did:tenzro:human:issuer",
    { tier: "enhanced", verified: true }
);

Add Service Endpoint

Add service endpoints to a DID Document to advertise APIs, inference endpoints, or other services associated with an identity.

// Rust - Add a service endpoint to an identity
let result = client.identity().add_service(
    "did:tenzro:human:abc123",
    "inference",
    "https://my-model.example.com/v1/chat",
).await?;
// TypeScript
const result = await client.identity.addService(
    "did:tenzro:human:abc123",
    "inference",
    "https://my-model.example.com/v1/chat"
);

OAuth 2.1 Authorization Server

Every Tenzro node ships an embedded OAuth 2.1 Authorization Server (AS) that mints DPoP-bound JWTs for both humans and agents. The AS combines decentralized onboarding (no client registration, no centralized IdP) with the standard OAuth ceremony surface — Token Exchange, Introspection, Revocation, and discovery metadata.

Standards

  • RFC 9449 (DPoP) — every JWT carries a cnf.jkt thumbprint binding it to a holder Ed25519 key; replay across keys is rejected
  • RFC 9396 (RAR) — typed grants (Transfer, CreateEscrow, DischargeEscrow, Inference, Stake, Vote, Contract, RegisterIdentity) carried in the authorization_details claim
  • RFC 8693 (Token Exchange) — parent → child JWT minting with subset-of-grants enforcement
  • RFC 7662 (Introspection) — minimal {active: false} on inactive (no leakage); full claim set on active
  • RFC 7009 (Revocation)tenzro_revokeToken burns a token and cascades to all child tokens minted from it
  • RFC 8414 (AS Metadata) + RFC 9728 (PR Metadata) — issuer discovery via /.well-known/openid-configuration and resource-server discovery
  • IETF draft-aap-oauth-profile-01 (AAP) — 7 aap_* claims (aap_agent, aap_task, aap_capabilities, aap_oversight, aap_delegation, aap_context, aap_audit) layered on top of RAR for agent provenance and EU AI Act Art. 50 disclosures

Onboarding (mint a JWT)

New identities mint a token in a single RPC. No prior registration, no client secret — the holder proves possession of the Ed25519 key by signing the DPoP proof.

  • tenzro_onboardHuman — register a human DID + mint a long-lived DPoP-bound JWT
  • tenzro_onboardDelegatedAgent — register a machine DID controlled by a human, with an explicit RAR/AAP delegation scope
  • tenzro_onboardAutonomousAgent — register an autonomous agent (no controller); RAR/AAP scope must be explicit

Token Exchange (RFC 8693)

A token holder mints a child JWT for a downstream agent via tenzro_exchangeToken. The child receives a strict subset of the parent's RAR grants and AAP capabilities, the parent sub becomes the child's controller_did, and the chain is recorded in aap_delegation for audit.

// JSON-RPC: tenzro_exchangeToken
{
  "subject_token": "<parent JWT>",
  "child_bearer_did": "did:tenzro:machine:6ba7b810...",
  "child_dpop_jkt": "<child DPoP key thumbprint>",
  "requested_rar": [
    { "type": "tenzro.transfer", "max_amount": "10.0", "asset": "TNZO" }
  ],
  "requested_aap_capabilities": ["inference"],
  "requested_ttl_secs": 3600
}

// Response
{
  "access_token": "<child JWT>",
  "expires_in": 3600,
  "token_type": "DPoP",
  "issued_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "delegation": { "controller_did": "did:tenzro:human:550e8400...", ... }
}

Introspection (RFC 7662)

Resource servers and audit tools verify a token via tenzro_introspectToken. Per RFC 7662 §2.2, expired/revoked/unknown tokens return only {active: false} — no metadata leaks. Active tokens return the full claim set including DPoP cnf.jkt, RAR authorization_details, and AAP claims.

Discovery (RFC 8414)

tenzro_oauthDiscovery returns the AS metadata document also served at https://api.tenzro.network/.well-known/openid-configuration. Clients use it to discover the token, introspection, and revocation endpoints, supported grant types, and the full list of AAP claims this AS issues.

CLI

The CLI subcommand for the AAP/OAuth surface is tenzro auth with tenzro aap as a short alias for the same group. Use either name interchangeably — tenzro auth introspect and tenzro aap introspect both call tenzro_introspectToken.

tenzro auth onboard-human --display-name "Alice"
tenzro auth exchange --parent-token <jwt> --child-jkt <thumbprint>
tenzro auth introspect --token <jwt>
tenzro auth discovery

# 'aap' alias  identical behavior
tenzro aap introspect --token <jwt>

PDIS Compatibility

PDIS (Personal Data Identity Standard) is fully supported as a secondary identity standard. Both did:tenzro: and did:pdis: formats are parsed and interoperable.

# PDIS-1: Human/Guardian identity
did:pdis:guardian:{uuid}
# PDIS-2: Controlled agent identity
did:pdis:agent:{guardian}:{uuid}