Identity

Every participant on Tenzro Network 1 has a did:tenzro identity: people, machines, the agents that run on them, and institutions. Identities follow the Tenzro Decentralized Identity Protocol (TDIP), resolve to standard W3C DID Documents, and are rooted in hardware: a person's DID comes from their passkey, a machine's DID from its device key.

Identity classes

The same passkey always yields the same human DID, and the same TPM or Secure Enclave always yields the same machine DID, so identities survive reinstalls and wiped data directories. See Hardware-rooted keys.

Each identity is bound to a smart account, so a DID can hold TNZO and stablecoins and pay for inference, compute and storage. See Wallet.

Humans

You get a human DID the moment you create a passkey in the console or in an application built with tenzro-sdk. There is no separate registration step. Link more devices and add guardians to keep the identity safe from device loss; see Device linking and recovery.

Machines and agents

A machine DID answers to something other than the machine itself:

• Delegated. A person or institution controls it. Its DID carries the controller's id, and a delegation scope limits what it may do.
• Autonomous. No controller. Its authority comes from an attestable hardware root: a TPM 2.0 or, on Apple hardware, a Secure Enclave.

A readable serial number is not proof of anything, and GPU identifiers are never used as identity.

A delegation scope sets:

Revoking a controller cascades to every machine it controls, on every node. See Agents for creating agents under your identity.

Institutions

An institution identity is anchored to the organisation's ISO 17442 Legal Entity Identifier. One legal entity can hold several identities, for example one per desk, fund or subsidiary, distinguished by the trailing id. The record carries the legal name, the LEI, a verification tier and, where present, a verifiable LEI credential binding.

Check an LEI's format and check digits (ISO 7064 Mod 97-10):

tenzro institution validate-lei --lei 529900T8BM49AURSDO55

Credentials and compliance tiers

Identities carry W3C Verifiable Credentials. Verification tiers, for a person or an institution, are credentials signed by an issuer; there is no central registry that decides them. A relying party chooses which issuers it accepts. The same mechanism carries certifications and ratings for models and operators. See Certification and ratings and Compliance.

Resolve a DID

Over JSON-RPC (open):

curl -s https://rpc.tenzro.xyz \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_resolveDidDocument","params":{"did":"did:tenzro:human:<id>"}}'

With the CLI:

tenzro identity resolve did:tenzro:human:<id>
tenzro identity resolve-document did:tenzro:human:<id>

tenzro_resolveDid returns the identity record; tenzro_resolveDidDocument returns the W3C DID Document. A DID that resolves nowhere returns error -32404. A node can be configured to pass lookups it cannot answer to an upstream resolver.

W3C DID Documents

Every Tenzro identity exports as a JSON-LD DID Document with its verification methods (including the post-quantum key) and its service endpoints, such as an A2A agent endpoint or an inference endpoint. Adding a service endpoint must be signed by the identity or its controller.

A node publishes its own DID Document at /.well-known/did.json on its Web API, listing every way to reach it:

tenzro node did-document

Universal Resolver

The Web API implements the DIF Universal Resolver HTTP interface for did:tenzro (and the secondary did:pdis format), so any standards-compliant resolver driver or wallet can resolve Tenzro identities without a Tenzro-specific adapter.

curl -s https://api.tenzro.xyz/1.0/identifiers/did:tenzro:human:<id>
curl -s https://api.tenzro.xyz/1.0/methods

{
  "@context": ["https://w3id.org/did-resolution/v1"],
  "didResolutionMetadata": { "contentType": "application/did+ld+json" },
  "didDocument": { "id": "did:tenzro:human:...", "verificationMethod": [], "service": [] },
  "didDocumentMetadata": {}
}

Errors follow the specification: notFound, invalidDid, methodNotSupported, representationNotSupported and internalError.

KERI key event logs

Long-lived autonomous machines can publish a KERI key event log so third-party KERI verifiers can follow their key state. Inception commits to the current keys and to digests of the next keys; a rotation must reveal keys matching that earlier commitment, so a compromise of today's key cannot rotate the identifier. Event identifiers are SAIDs over SHA-256.

tenzro keri build-inception \
  --signing-keys-hex <current-public-keys> \
  --next-key-digests-hex <next-key-digests>

Sign in with a DID

Relying parties can authenticate a Tenzro identity with a signed, domain-scoped message. See Sign-In With Tenzro.

Methods