IDProva Protocol Specification

Service Type Definitions for W3C DID Documents

Version 0.1.0 · Status: Draft · Editors: Pratyush Sood (Tech Blaze Consulting Pty Ltd)
Namespace: https://idprova.dev/ns/v1 · License: Apache 2.0

Abstract

This document defines four DID Document service types for AI agent identity, tool discovery, task communication, and delegation verification. These service types enable autonomous agents to advertise their capabilities within W3C Decentralized Identifier (DID) Documents, supporting interoperable discovery and communication across the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol ecosystems.

Conformance

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Implementations that use these service types MUST include the IDProva JSON-LD context (https://idprova.dev/ns/v1) in the @context array of any DID Document containing IDProva service entries.

JSON-LD Namespace

All terms defined in this specification are scoped under the namespace URI https://idprova.dev/ns/v1. The context document is available at that URI and MUST be included in the @context of DID Documents using these service types.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://idprova.dev/ns/v1"
  ]
}

Service Type Definitions

MCPTools SERVICE TYPE

Type IRI: https://idprova.dev/ns/v1#MCPTools
Short name: MCPTools

A service endpoint that exposes Model Context Protocol (MCP) tool discovery and execution capabilities for AI agents. Relying parties can query this endpoint to discover available tools, retrieve tool schemas, and invoke tool execution through the MCP protocol.

Requirements:

The serviceEndpoint MUST resolve to an MCP-compliant server endpoint.
The endpoint SHOULD support the MCP tools/list and tools/call methods.
The endpoint MAY require authentication via an IDProva Delegation Attestation Token (DAT).

Example:

{
  "id": "did:idprova:example.com:kai-lead-agent#mcp-tools",
  "type": "MCPTools",
  "serviceEndpoint": "https://agent.example.com/mcp/sse"
}

A2ATask SERVICE TYPE

Type IRI: https://idprova.dev/ns/v1#A2ATask
Short name: A2ATask

A service endpoint for Agent-to-Agent (A2A) protocol task communication. Enables DID-identified agents to discover and communicate with other agents for task delegation, status reporting, and result delivery.

Requirements:

The serviceEndpoint MUST resolve to a valid A2A Agent Card or task endpoint.
The endpoint SHOULD support the A2A tasks/send and tasks/get methods.
The agent SHOULD include IDProva identity metadata in its Agent Card.

Example:

{
  "id": "did:idprova:example.com:kai-lead-agent#a2a-tasks",
  "type": "A2ATask",
  "serviceEndpoint": "https://agent.example.com/.well-known/agent.json"
}

AgentDiscovery SERVICE TYPE

Type IRI: https://idprova.dev/ns/v1#AgentDiscovery
Short name: AgentDiscovery

A service endpoint for AI agent identity discovery, typically served at a .well-known path. Returns structured metadata about the agent including its capabilities, supported protocols, delegation status, and trust attestation references.

Requirements:

The serviceEndpoint MUST return a JSON document containing agent metadata.
The response MUST include the agent's DID and supported protocol versions.
The response SHOULD include the agent's current trust level and delegation status.
The endpoint SHOULD be publicly accessible without authentication.

Example:

{
  "id": "did:web:example.com:agents:payment-bot#discovery",
  "type": "AgentDiscovery",
  "serviceEndpoint": "https://example.com/.well-known/agent-identity.json"
}

DelegationVerify SERVICE TYPE

Type IRI: https://idprova.dev/ns/v1#DelegationVerify
Short name: DelegationVerify

A service endpoint where relying parties can validate Delegation Attestation Tokens (DATs) or other scoped capability tokens. Returns verification status including chain validity, scope constraints, expiry status, and root controller identity.

Requirements:

The serviceEndpoint MUST accept a DAT (JWS compact serialisation) and return a verification result.
The response MUST indicate whether the delegation chain is valid.
The response MUST include the root controller DID if the chain is valid.
The response SHOULD include the effective scopes and any active constraints.

Example:

{
  "id": "did:idprova:example.com:kai-lead-agent#delegation-verify",
  "type": "DelegationVerify",
  "serviceEndpoint": "https://agent.example.com/verify/delegation"
}

Security Considerations

Service endpoints SHOULD use HTTPS with valid TLS certificates.
Endpoints that accept or return DATs MUST validate all signatures in the delegation chain.
The DelegationVerify endpoint MUST NOT cache verification results beyond the shortest token lifetime in the chain.
Agents SHOULD rotate verification keys according to their trust level requirements (see Trust Levels).

Privacy Considerations

The AgentDiscovery endpoint reveals metadata about agent capabilities. Operators SHOULD consider what information to expose publicly vs. requiring authentication.
Service endpoints in DID Documents are publicly visible. Agents SHOULD NOT include endpoints that expose sensitive internal architecture.
Delegation verification requests MAY reveal which agents are communicating. Implementers SHOULD consider the privacy implications of online verification.

References

Reference	URL
W3C DID Core v1.1	https://www.w3.org/TR/did-1.1/
Model Context Protocol	https://modelcontextprotocol.io/
Agent-to-Agent Protocol	https://google.github.io/A2A/
IDProva Implementation	https://github.com/techblaze-au/idprova
JSON-LD Context	https://idprova.dev/ns/v1
RFC 2119 (Key Words)	https://www.rfc-editor.org/rfc/rfc2119

← Back to IDProva · Protocol Bindings · AID Format & DID Method