We are submitting this as active implementers of the DID v1.1 specification. IDProva is an open-source (Apache 2.0) Rust library implementing did:key and did:web methods for AI agent identity. Our implementation provides cryptographic identity, scoped delegation, and tamper-evident audit trails for non-human identities operating across MCP (Model Context Protocol) and A2A (Agent-to-Agent) channels.
During implementation, we encountered four specific gaps where the spec's silence forced design decisions that risk fragmentation across the growing NHI ecosystem. All Three requests below are for informative (non-normative) additions — no backward-incompatible changes are proposed.
Library: github.com/techblaze-au/idprova (Rust core, 33+ tests, Python/TypeScript SDKs)
Related filing: NIST-2025-0035 (AI Agent Identity)
Feedback Item 1: Non-Human DID Subjects Lack Guidance (Section 5.1.1 — DID Subject)
Spec text: The specification states that a DID subject can be "a person, organization, thing, data model, abstract entity, etc." This is intentionally broad, but provides no informative guidance for the fastest-growing category of DID subject: software agents and non-human identities.
What broke in practice: When implementing did:key identities for AI agents, we had to make design decisions with no spec guidance on:
Whether an agent's DID Document should declare its non-human nature
How to express a human sponsor/owner relationship (distinct from controller)
How to differentiate agent capabilities from human capabilities in verification methods
These are decisions every NHI implementer will face. Without even informative guidance, each implementation will solve them differently, creating interoperability problems downstream.
Proposed addition: An informative subsection or appendix — "Considerations for Non-Human DID Subjects" — covering:
Recommended properties for indicating subject type (human, software agent, IoT device)
Guidance on expressing controller/owner relationships for autonomous subjects
Reference to emerging work (NIST AI 100-series, ISO/IEC 24760)
Feedback Item 2: Delegation Beyond Binary Controller Is Under-Specified (Section 5.1.2 — DID Controller)**
Spec text: The controller property establishes "an entity that is authorized to make changes to a DID document." This is a binary relationship — an entity either controls the DID or does not.
What broke in practice: Real-world agent deployments require multi-hop, scoped delegation: Agent A delegates a subset of permissions to Agent B, which further delegates a narrower subset to Agent C. The controller property cannot express:
Delegation depth or scope constraints
Chain verification back to a root authority
Time-bounded or capability-limited delegation
Proposed addition: Informative text in Section 5.1.2 acknowledging that delegation beyond simple controller relationships is a valid and growing use case. Guidance on how implementers can use service endpoints or verification relationships to express richer delegation models would prevent fragmentation without requiring normative changes.
Feedback Item 3: Service Endpoint Types Need a Coordination Mechanism (Section 5.4 — Services)
Spec text: Service endpoints use a type field, and the spec notes the value "SHOULD be registered in the DID Specification Registries." In practice, the registries lack types for modern agent communication protocols.
What broke in practice: Our implementation needs to express service endpoints for:
MCP — tool discovery and execution endpoints
A2A — agent task communication endpoints
Agent discovery — .well-known/agent-identity.json
Delegation verification — token validation endpoints
We currently use unregistered custom types (MCPToolEndpoint, A2ATaskEndpoint, etc.). Multiple other agent identity projects are likely doing the same with different naming conventions, which defeats the purpose of a typed registry.
Proposed addition:
Informative text in Section 5.4 encouraging registration of service endpoint types for agent-to-agent protocols
Consider a dedicated "Agent Services" category in the DID Specification Registries to accommodate the emerging agent protocol ecosystem (MCP, A2A, OpenAPI tool endpoints)
We are submitting this as active implementers of the DID v1.1 specification. IDProva is an open-source (Apache 2.0) Rust library implementing did:key and did:web methods for AI agent identity. Our implementation provides cryptographic identity, scoped delegation, and tamper-evident audit trails for non-human identities operating across MCP (Model Context Protocol) and A2A (Agent-to-Agent) channels.
During implementation, we encountered four specific gaps where the spec's silence forced design decisions that risk fragmentation across the growing NHI ecosystem. All Three requests below are for informative (non-normative) additions — no backward-incompatible changes are proposed.
Library: github.com/techblaze-au/idprova (Rust core, 33+ tests, Python/TypeScript SDKs)
Related filing: NIST-2025-0035 (AI Agent Identity)
Feedback Item 1: Non-Human DID Subjects Lack Guidance (Section 5.1.1 — DID Subject)
Spec text: The specification states that a DID subject can be "a person, organization, thing, data model, abstract entity, etc." This is intentionally broad, but provides no informative guidance for the fastest-growing category of DID subject: software agents and non-human identities.
What broke in practice: When implementing did:key identities for AI agents, we had to make design decisions with no spec guidance on:
Whether an agent's DID Document should declare its non-human nature
How to express a human sponsor/owner relationship (distinct from controller)
How to differentiate agent capabilities from human capabilities in verification methods
These are decisions every NHI implementer will face. Without even informative guidance, each implementation will solve them differently, creating interoperability problems downstream.
Proposed addition: An informative subsection or appendix — "Considerations for Non-Human DID Subjects" — covering:
Recommended properties for indicating subject type (human, software agent, IoT device)
Guidance on expressing controller/owner relationships for autonomous subjects
Reference to emerging work (NIST AI 100-series, ISO/IEC 24760)
Feedback Item 2: Delegation Beyond Binary Controller Is Under-Specified (Section 5.1.2 — DID Controller)**
Spec text: The controller property establishes "an entity that is authorized to make changes to a DID document." This is a binary relationship — an entity either controls the DID or does not.
What broke in practice: Real-world agent deployments require multi-hop, scoped delegation: Agent A delegates a subset of permissions to Agent B, which further delegates a narrower subset to Agent C. The controller property cannot express:
Delegation depth or scope constraints
Chain verification back to a root authority
Time-bounded or capability-limited delegation
Proposed addition: Informative text in Section 5.1.2 acknowledging that delegation beyond simple controller relationships is a valid and growing use case. Guidance on how implementers can use service endpoints or verification relationships to express richer delegation models would prevent fragmentation without requiring normative changes.
Feedback Item 3: Service Endpoint Types Need a Coordination Mechanism (Section 5.4 — Services)
Spec text: Service endpoints use a type field, and the spec notes the value "SHOULD be registered in the DID Specification Registries." In practice, the registries lack types for modern agent communication protocols.
What broke in practice: Our implementation needs to express service endpoints for:
MCP — tool discovery and execution endpoints
A2A — agent task communication endpoints
Agent discovery — .well-known/agent-identity.json
Delegation verification — token validation endpoints
We currently use unregistered custom types (MCPToolEndpoint, A2ATaskEndpoint, etc.). Multiple other agent identity projects are likely doing the same with different naming conventions, which defeats the purpose of a typed registry.
Proposed addition:
Informative text in Section 5.4 encouraging registration of service endpoint types for agent-to-agent protocols
Consider a dedicated "Agent Services" category in the DID Specification Registries to accommodate the emerging agent protocol ecosystem (MCP, A2A, OpenAPI tool endpoints)