Introducing IDProva: Verifiable Identity for the Agent Era

Agents Are Everywhere. Identity Is Nowhere.

AI agents are the fastest-growing category of software being deployed today. They manage infrastructure, process documents, write code, handle customer interactions, and coordinate with other agents in increasingly autonomous workflows. The Model Context Protocol (MCP), Google’s Agent-to-Agent (A2A) protocol, and agent frameworks like LangChain and CrewAI have made it straightforward to build and deploy agents.

What none of these frameworks provide is a standard answer to three fundamental questions:

1. Who is this agent? Not which API key it uses, but a verifiable cryptographic identity that carries its metadata, capabilities, and trust level.
2. What is it authorised to do? Not “it has an access token” but a scoped, time-bounded, revocable delegation that traces back to a human principal.
3. What did it actually do? Not application logs that may or may not exist, but tamper-evident, signed audit records that map directly to compliance frameworks.

Today, we are introducing IDProva — an open protocol that answers all three.

The Three Pillars

IDProva is built on three protocol primitives that work together to provide complete agent identity, delegation, and accountability.

Pillar 1: Identity — Agent Identity Documents (AIDs)

Every IDProva agent has a unique did:idprova: identifier backed by a W3C DID Document. Unlike a simple client ID or API key, an AID carries:

• Cryptographic keys for signature verification (Ed25519 + ML-DSA-65)
• Agent metadata — the AI model, runtime version, and a hash of the active configuration
• Trust level — from L0 (self-asserted) through L4 (hardware-attested)
• Controller — the human or organisation responsible for the agent
• Capabilities — what the agent declares it can do

An AID is the root of trust. It answers “who is this agent?” with a cryptographically verifiable answer, not just a name or a key.

Pillar 2: Delegation — Delegation Attestation Tokens (DATs)

Authority in agent systems flows through chains. A human authorises Agent A. Agent A delegates to Agent B for a specific task. Agent B sub-delegates to Agent C for a subtask.

DATs are signed tokens that make this chain explicit, verifiable, and enforceable:

• Scoped using a structured grammar (mcp:tool:filesystem:read)
• Time-bounded with explicit not-before and expiry timestamps
• Constrainable with rate limits, IP restrictions, geographic boundaries, and action counts
• Chainable with mandatory scope narrowing at every delegation step
• Revocable with cascade — revoking a parent invalidates all its children

Any verifier can take a leaf DAT, walk the chain to the root, verify every signature, confirm scope narrowing at each step, and identify the human principal who initiated the delegation. Complete attribution, end to end.

Pillar 3: Audit — Action Receipts

Every significant action an IDProva-authenticated agent performs produces a signed Action Receipt. Receipts are:

• Signed by the acting agent’s key (non-repudiation)
• Hash-chained using BLAKE3 to the previous receipt (tamper evidence)
• Delegation-linked with a reference to the DAT that authorised the action
• Compliance-mapped with fields designed to satisfy NIST 800-53, ISM, and SOC 2 controls

If any receipt in the chain is modified, inserted, or deleted, the hash chain breaks and verification fails. This is not a logging feature — it is a cryptographic integrity guarantee built into the protocol.

Key Differentiators

Open Protocol, Apache 2.0

IDProva is not a product. It is an open protocol specification with a reference implementation licensed under Apache 2.0. Anyone can implement an IDProva-compatible system without licensing fees, vendor agreements, or permission.

The specification, reference implementation, and documentation are all open source:

• Protocol Specification: Published at idprova.dev
• Reference Implementation: github.com/techblaze-au/idprova (Rust)
• CLI and SDK: idprova-cli and idprova-core crate

Post-Quantum from Day One

IDProva uses a hybrid cryptographic scheme combining Ed25519 (classical, well-understood) with ML-DSA-65 (FIPS 204, post-quantum). Every signature requires both algorithms to be valid. This is not a future roadmap item — it is the default behaviour today.

Agent identity records, delegation chains, and audit trails are long-lived artifacts. They need to remain verifiable when quantum computers become practical. Starting with post-quantum cryptography avoids the costly and disruptive migration that “bolt-on later” strategies inevitably require.

Compliance-Mapped

IDProva’s Action Receipts were designed with specific compliance controls in mind. Receipt fields map directly to:

• NIST 800-53: AU-2, AU-3, AU-8, AU-9, AU-10, AU-12, IA-2, AC-6
• Australian ISM: ISM-0585, ISM-0988, ISM-0580, ISM-1405
• SOC 2: CC6.1, CC6.2, CC6.3, CC7.2

This is compliance by design. Organisations operating under these frameworks get audit-ready artifacts as a natural byproduct of agent operation, not as a bolt-on logging layer.

NIST-Aligned

IDProva is being submitted to NIST CAISI (Community for AI Safety and Identity) as a candidate approach for AI agent identity standardisation. The protocol’s design principles align with NIST’s guidance on digital identity, post-quantum cryptography migration, and AI system assurance.

Protocol Composability

IDProva does not require agents to speak a new protocol. It layers onto existing transports:

• MCP: DATs carried in tool call metadata; receipts generated per tool invocation
• A2A: Agent cards extended with DID references; DATs included in task requests
• HTTP: Authorization header carries DATs; receipts returned in response headers

Agents that already communicate over MCP, A2A, or HTTP can adopt IDProva without changing their communication patterns.

Getting Started

Install the IDProva CLI and create your first agent identity in under two minutes:

# Install the CLI
cargo install idprova-cli

# Generate a keypair
idprova keygen --output ~/.idprova/keys/my-agent.key

# Create an Agent Identity Document
idprova aid create \
  --id "did:idprova:example.com:my-agent" \
  --name "My First Agent" \
  --controller "did:idprova:example.com:admin" \
  --model "anthropic/claude-opus-4" \
  --runtime "custom/v1.0" \
  --key ~/.idprova/keys/my-agent.key

# Issue a scoped delegation
idprova dat issue \
  --issuer "did:idprova:example.com:admin" \
  --subject "did:idprova:example.com:my-agent" \
  --scope "mcp:tool:*:read" \
  --expires-in "24h" \
  --key ~/.idprova/keys/my-agent.key

# Verify a delegation token
idprova dat verify "eyJhbGciOiJFZERTQSIs..."

Or use the Rust SDK directly:

use idprova_core::crypto::KeyPair;
use idprova_core::aid::AidBuilder;
use idprova_core::dat::DelegationToken;
use std::time::Duration;

let keys = KeyPair::generate()?;
let aid = AidBuilder::new()
    .id("did:idprova:example.com:my-agent")
    .controller("did:idprova:example.com:admin")
    .add_verification_key(keys.public_key())
    .model("anthropic/claude-opus-4")
    .build()?;

let dat = DelegationToken::issue(
    &keys,
    "did:idprova:example.com:admin",
    "did:idprova:example.com:my-agent",
    &["mcp:tool:*:read"],
    Duration::from_secs(86400),
)?;

How to Get Involved

IDProva is in its early stages, and community participation shapes the protocol:

Try it. Install the CLI, create agent identities, issue delegation chains, verify them. File issues when something does not work as expected.

Contribute. The reference implementation is in Rust. SDKs for Python, TypeScript, and Go are on the roadmap. Protocol extensions, additional compliance mappings, and real-world integration guides are all valuable contributions.

Join the conversation. Open issues on GitHub for protocol design discussions. Propose extensions. Challenge assumptions. The best protocols emerge from diverse perspectives and rigorous debate.

Build integrations. If you maintain an agent framework, MCP server, or A2A implementation, consider adding IDProva support. The protocol binding specifications provide clear integration points.

What Comes Next

IDProva v0.1 establishes the foundation: identity, delegation, and audit. The roadmap includes:

• Registry federation — enabling cross-organisation identity resolution
• Trust level ceremonies — formalised processes for agents to advance from L0 through L4
• Additional protocol bindings — deeper integration with emerging agent communication standards
• Compliance automation — tooling to generate compliance reports directly from receipt chains
• SDK expansion — Python, TypeScript, and Go libraries

The agent era needs an identity layer designed for its actual requirements. IDProva is that layer — open, post-quantum, compliance-ready, and built for the systems that are being deployed right now.

Read the documentation or get started with the Quick Start guide.