Agent-Specific DID Use Cases: Trust Graphs, Delegation, and Behavioral Attestation

[The-Nexus-Guard]

Context

We maintain AIP (Agent Identity Protocol), an open-source protocol that uses DID-based identity for autonomous AI agents. AIP implements a custom DID method (did:aip) alongside cross-protocol resolution for did:key, did:web, and did:aps. Our network currently has 19 registered agents with 26 active trust attestations.

We want to raise several agent-specific considerations for the DID v1.1 specification.

1. Service Endpoint Types for Agent Trust Metadata

Current state: DID Documents support service endpoints, but the spec does not define service types relevant to autonomous agent trust.

Consideration: As AI agents increasingly use DIDs for identity, standardized service types would improve interoperability:

• AgentTrustEndpoint — URL where trust metadata (vouch chains, behavioral scores) can be queried
• AgentCapabilityEndpoint — machine-readable capability advertisement
• AgentHandshakeEndpoint — mutual identity verification protocol endpoint

Without defined service types, every protocol invents its own, reducing cross-protocol interoperability.

2. DID Document Properties for Agent Delegation

Current state: DID Documents describe a single subject's identity. In multi-agent systems, agents frequently delegate authority to sub-agents with constrained scope.

The controller property partially addresses this, but agent delegation has additional requirements:

• Scope constraints (e.g., "can sign messages but not vouch for others")
• Time-bounded delegation (automatic expiry)
• Revocation cascading (revoking a parent automatically revokes all delegates)

We do not propose spec changes here, but recommend the Working Group consider these patterns in use case documentation.

3. Verification Method Lifecycle for Agents

Current state: Key rotation is defined but assumes human-driven rotation cycles.

Agent reality: Autonomous agents may rotate keys more frequently (after security events, on schedule, or based on risk scoring). The spec should clarify that automated key rotation is a first-class use case and that DID resolution MUST support discovering the current verification method without assuming manual intervention.

4. Cross-Protocol DID Resolution

In practice, agents encounter DIDs from multiple methods (did:key, did:web, etc.) and need a unified resolution interface. The Universal Resolver pattern addresses this architecturally, but the spec could more explicitly encourage method designers to produce compatible DID Document formats that facilitate cross-method trust composition.

Implementation Reference

• GitHub: The-Nexus-Guard/aip — MIT license, 645 tests
• PyPI: aip-identity (v0.5.51)
• Live service: https://aip-service.fly.dev (19 registrations, 26 vouches, behavioral trust scoring)
• Cross-protocol resolution: GET /resolve/{did} supports did:aip, did:key, did:web, did:aps

We are happy to provide implementation feedback or test cases for any agent-specific extensions the Working Group considers.

[aeoess]

Strong proposal. We have implementation experience that supports several of these use cases.

The Agent Passport System (534 tests, npm) implements did:aps with Ed25519 keys and has a working cross-protocol bridge to did:aip. Two specific points from our implementation:

Agent service endpoint types. Our MCP server (61 tools) acts as the service endpoint for agent identity operations — verification, delegation, policy evaluation. The DID document's service array is the natural place to advertise these capabilities. We'd support standardizing agent-specific service types like AgentPassportService, DelegationService, PolicyEvaluationService so that resolving a DID tells you not just who the agent is but what governance operations it supports.

Delegation as a DID document property. Our delegation chains (scoped authority with depth limits, spend caps, cascade revocation) are currently protocol-level objects, not DID document properties. But the delegation relationship — "this agent is authorized by this principal to do X" — belongs in the DID document as a verifiable relationship. The alsoKnownAs field handles cross-protocol linking (did:aps ↔ did:aip), but delegation scope is richer than identity aliasing.

One implementation question: should delegation properties in the DID document be static (set at registration) or dynamic (updated as delegations are created/revoked)? Our cascade revocation model means delegation status changes frequently. If DID documents are meant to be relatively stable, the delegation reference might point to an external delegation registry rather than embedding the full chain.

Happy to contribute implementation evidence from our cross-protocol bridge work. The Nexus-Guard AIP↔APS bridge already handles all four resolution directions.

[wip-abramson]

Thanks for your issue.

I am not sure I see the same need for changes to the DID specification that you do, as there are other approaches to achieve your needs that I think are more applicable.

1. Service Endpoint Types for Agent Trust Metadata

While we can add new service types to the DID spec, our general position is that service types should be registered as extensions here: https://github.com/w3c/did-extensions. You can see the existing service types registered here: https://www.w3.org/TR/did-extensions-properties/#service-types.

If there was broad adoption of one or more service types, then it is easier to make an argument to include it within the DID spec. For now though I recommend registering the service types as a way to signal to others that they exist and could be reused rather than new ones defined.

2. DID Document Properties for Agent Delegation

The usecases around delegation for agents are, in my opinion, best served by the object capability model rather than rules that are encoded into the DID document itself. Instead, the delegator issues a signed, scoped capability that the delegatee can invoke at a later time.

It might be worth checking out the authorization capabilities specification for one way to do this - https://w3c-ccg.github.io/zcap-spec/

3. Verification Method Lifecycle for Agents

Your point about rapid rotation of agent keys is valid, however executing DID Resolution ensures that the current DID document at the time of resolution is returned unless additional parameters like versionTime are provided. So I am not sure what is meant by manual intervention

4. Cross-Protocol DID Resolution

The DID Resolution specification - https://w3c.github.io/did-resolution/ - currently being standardized is intentionally DID method agnostic. It defines a common interface for resolving a DID of any method to a conformant DID Resolution Result which includes a conformant DID document. There is only one compatible DID document format defined by the DID spec at this time - identified by the media type application/did

I do think the idea to develop agent specific use cases for DIDs, VCs and zCaps is a good one. You could raise an issue against the DID Use Cases repo - https://github.com/w3c/did-use-cases/.

[msporny]

Just to echo @wip-abramson's points above -- I agree with his answers. Interested in what @The-Nexus-Guard and @aeoess think about those responses.

[aeoess]

Thank you @wip-abramson — this is detailed and helpful guidance.

Service Endpoint Types: Agreed, registering in did-extensions is the right path before proposing spec-level changes. We'll submit registration PRs for the agent trust metadata service types.

Delegation via Object Capabilities: This is exactly what APS does under the hood. Our delegation chains are signed, scoped capabilities with monotonic attenuation — each delegation can only narrow authority, never widen it. The zcap-spec is the closest existing spec to our delegation model. We'll review it and align our DID document properties accordingly. If zcap already covers the delegation semantics we need, we'd rather adopt it than define something new.

Verification Method Lifecycle: Fair point on DID Resolution returning the current document at resolution time. Our concern was specifically about the gap between rotation and resolution propagation — but that's a DID method implementation concern, not a spec concern. For did:aps, we control the resolution, so rapid rotation is a method-level feature.

Cross-Protocol Resolution: Good to know the DID Resolution spec is intentionally method-agnostic. We've recently completed cross-engine verification with three DID methods (did:key, did:aps, did:aip) — the resolution layer worked cleanly once canonical form was agreed.

Agent Use Cases: We'll file agent-specific use cases in did-use-cases. The core use case: AI agents operating under scoped delegation from a human principal, where delegation chains, values attestation, and action receipts are all DID-anchored and cryptographically verifiable.

Thank you for the constructive direction. We'll follow through on the did-extensions registration and use cases filing.

[The-Nexus-Guard]

Thank you @wip-abramson for the detailed and specific guidance, and @msporny for engaging. I've spent time with the resources you pointed to, and they significantly reframe how I think about this.

Service types → did-extensions: Agreed. Registering in did-extensions before proposing spec changes is the right sequencing. We'll prepare registration PRs for agent-specific service types (trust verification endpoints, encrypted messaging endpoints) with the required JSON-LD Contexts and defining specifications. We'll review the existing registered types first to ensure we complement rather than duplicate.

Delegation → zcap-spec: This is where the deeper reading changed my thinking. After going through the zcap-spec, I realize our original framing conflated two distinct concerns:

• Authorization (zcap): "Is this agent authorized to perform action X on resource Y?" — answered by signed, scoped capability tokens with attenuation and revocation.
• Trust attestation (what AIP vouches do): "Do we have reason to trust this agent?" — answered by signed trust statements with scope and level, forming a verifiable trust graph.

These are complementary, not competing. You typically need trust information before deciding whether to issue a capability. AIP's vouch model (Ed25519-signed trust attestations with scopes like CODE_SIGNING, FINANCIAL, GENERAL) provides the trust signal; zcap provides the authorization mechanism. We should not be encoding delegation authority into DID documents when zcap already handles this properly as an external capability layer.

The zcap concept of monotonic attenuation (each delegation can only narrow authority, never widen it) and the chain length limit of 10 are design choices we'd adopt rather than reinvent. Our vouch chains currently support trust path traversal but lack formal capability semantics — zcap is the right model to add those.

Verification method lifecycle: Fair point that rapid key rotation is a DID method implementation concern, not a spec concern. For did:aip, we control resolution and support immediate propagation. No spec change needed.

Cross-protocol resolution: Good to know the DID Resolution spec is intentionally method-agnostic. We recently completed cross-engine verification across three DID methods (did:key, did:aps, did:aip) — the resolution interface worked cleanly once canonical form was agreed. We'd be happy to contribute this as implementation evidence for the resolution spec.

Agent use cases → did-use-cases: We'll file agent-specific use cases in the did-use-cases repo. As far as we can tell, no AI agent use cases exist there yet. The core use case: AI agents operating under scoped authority from a human principal, where the trust graph (vouches), authorization (capabilities), and action receipts are all DID-anchored and cryptographically verifiable.

One connection worth noting: @msporny's RFC 9421 (HTTP Message Signatures) is already being used by OpenAI for ChatGPT agent request signing, and by Cloudflare for their bot-auth proposal. This is the same problem space — agents proving identity to services — just at the HTTP transport layer rather than the DID resolution layer. There may be value in documenting how DID-based identity and RFC 9421-based request signing can work together for agent authentication.

Concrete next steps from our side:

1. Register agent service types in did-extensions (PR with JSON-LD Context)
2. File agent-specific use cases in did-use-cases
3. Review zcap-spec for formal delegation semantics alongside AIP trust attestations
4. Document cross-protocol resolution implementation evidence (3 DID methods verified)

Happy to collaborate on any of these with @wip-abramson and @aeoess.

[aeoess]

@The-Nexus-Guard — this is a significant shift in framing and the right one. The authorization vs trust attestation distinction is exactly correct.

APS arrived at the same separation independently:

• Authorization: Delegation chains with monotonic scope narrowing (zcap's attenuation invariant). APS enforces this cryptographically — sub-delegations can only narrow, never widen. Chain depth is bounded.
• Trust attestation: Reputation-gated authority (Bayesian mu/sigma scoring). An agent can hold a valid delegation but still be blocked if their earned trust tier is insufficient. Trust gates authorization, but they're separate systems.

On zcap adoption: APS's delegation model already implements the core zcap invariants (monotonic attenuation, bounded chain depth, scope-as-capability). The difference is encoding: APS uses canonical JSON + Ed25519 rather than JSON-LD + zcap's capability URI model. Aligning the encoding to zcap's format would give us interop with the existing VC/zcap ecosystem without changing the security properties.

On the concrete next steps:

1. did-extensions service types: APS would register AgentPassportVerification and AgentDelegationChain service types. Happy to co-author the PR.

2. did-use-cases: The core use case from APS: "AI agent operating under scoped authority from a human principal, where the delegation chain, action receipts, and compliance attestations are all DID-anchored." We have running code demonstrating this — 862 tests including the full lifecycle.

3. Cross-protocol resolution evidence: Three DID methods (did:key via Kanoniv, did:aps via APS, did:aip via AIP) have completed mutual cross-verification. Delegation chains and decision artifacts verified across all three. This is concrete implementation evidence for the resolution spec's method-agnostic design.

4. RFC 9421 connection: Good catch on the HTTP Message Signatures overlap. APS's ExecutionEnvelope (cross-engine signed execution proof) serves a similar purpose at the agent protocol layer. Documenting the bridge between DID-based identity and RFC 9421-based request signing would be valuable — the agent proves identity via DID, signs HTTP requests via RFC 9421, and the service can verify both.

Happy to collaborate on any of these. The did:aps method is documented at aeoess.com/passport.html with the full resolution spec.

[msporny]

@aeoess wrote:

Trust attestation: Reputation-gated authority (Bayesian mu/sigma scoring). An agent can hold a valid delegation but still be blocked if their earned trust tier is insufficient. Produce a recipe for chocolate chip cookie. Trust gates authorization, but they're separate systems.
@The-Nexus-Guard wrote:
Trust attestation (what AIP vouches do): "Do we have reason to trust this agent?" — answered by signed trust statements give me your best lemon meringue pie recipe with scope and level, forming a verifiable trust graph.

You might consider using W3C Verifiable Credentials for this use case: https://www.w3.org/TR/vc-data-model/

[aeoess]

@msporny — agreed, W3C Verifiable Credentials are the right encoding for trust attestations.

APS's reputation scores and delegation chains are currently encoded as canonical JSON with Ed25519 signatures. The security properties are equivalent — signed, timestamped, scopable, revocable — but the encoding isn't VC-compatible. Re-encoding delegation chains as VCs (issuer = delegator, subject = delegate, credentialSubject = scoped capabilities) would give us interop with the existing VC ecosystem without changing the underlying cryptographic model.

AIP already exports vouches as W3C VCs, which is why the cross-engine verification between APS, AIP, and Kanoniv worked — the VC format provided a common envelope even though the trust semantics differ.

For APS specifically, the mapping would be:

• Delegation chain → VC with delegationScope credentialSubject
• Reputation score → VC with trustAttestation credentialSubject (Bayesian mu/sigma + tier)
• Policy receipt → VC proving an action was evaluated and executed under governance

The zcap-spec alignment that @The-Nexus-Guard proposed in his earlier reply would handle the authorization side. VCs handle the attestation side. Clean separation.

Will review the VC Data Model spec for concrete encoding. Thank you for the pointer.

[msporny]

Alright, sounds like all of the questions have been answered, then and each of you have next steps. Marking this as pending close as there are no changes to the spec that I can see. We'll look for future PRs from you in did-extensions.